Indemnity Clauses in New Zealand Cybersecurity Contracts

If you are signing a cybersecurity contract in New Zealand, the indemnity clause can shift a lot more risk than most founders expect. This is often where a managed security provider, penetration tester, software vendor, or enterprise customer tries to push liability for breaches, third party claims, regulatory issues, and data loss onto the other side. Common mistakes include accepting a broad indemnity without a dollar cap, treating an indemnity as the same thing as ordinary damages, and relying on sales discussions instead of the written terms.

That matters because one badly drafted clause can leave a cybersecurity company paying for claims that are only partly within its control. It can also leave a customer exposed where the provider has caused the problem but limited its own liability too aggressively. This guide explains what an indemnity clause for cybersecurity company arrangements usually covers in New Zealand, the legal issues to check before you sign, and the drafting traps that tend to cause trouble later.

Overview

An indemnity is a contractual promise that one party will compensate the other for certain losses or claims. In cybersecurity contracts, that promise often applies to data breaches, privacy complaints, intellectual property claims, regulatory investigations, system outages, or third party losses caused by a security failure.

• Exactly what events trigger the indemnity, such as a breach, negligence, privacy incident, or third party claim
• Whether the indemnity is one way or mutual
• What losses are covered, including legal costs, remediation costs, notification expenses, and settlement amounts
• Whether there is a financial cap, and whether the cap matches the rest of the liability clause
• Which losses are excluded, such as indirect loss, loss of profit, or customer consequential loss
• Who controls the defence of a claim and who decides whether to settle
• Whether the indemnity applies only where fault is proven, or even if the trigger is partly outside your control
• How the indemnity fits with privacy, confidentiality, service levels, and insurance obligations

What Indemnity Clause for Cybersecurity Company Means For New Zealand Businesses

An indemnity clause for cybersecurity company contracts decides who carries the cost when something goes wrong. In practice, it can matter more than the pricing page, because it determines whether one incident turns into a manageable contract issue or a major financial hit.

Cybersecurity contracts often sit in a higher-risk category than standard software or support agreements. The provider may have access to networks, endpoints, cloud systems, logs, credentials, and sensitive personal information. If there is an incident, the financial fallout can spread quickly across forensic work, customer communications, business interruption, regulator engagement, and third party complaints.

Why indemnities are treated differently from ordinary liability clauses

A general liability clause usually says when a party is liable for breach of contract and what limits apply. An indemnity is more targeted. It says one party must cover the other for specified losses, often on a more direct basis and sometimes without the same hurdles that apply to a normal damages claim.

This is where founders often get caught. A contract may contain a neat looking liability cap in one section, but the indemnity section may carve out certain losses from that cap. That means the largest risks, such as privacy breach costs or third party intellectual property claims, might be uncapped.

Common cybersecurity scenarios where indemnities appear

In New Zealand cybersecurity deals, indemnities commonly appear in clauses dealing with:

• unauthorised access to customer systems or data
• breach of confidentiality obligations
• Privacy Act 2020 issues, including notifiable privacy breaches and related complaints
• malware infection, ransomware events, or service disruption linked to the provider's acts or omissions
• intellectual property infringement, such as a claim that the provider's software or tools infringe another party's rights
• regulatory non-compliance where the provider has promised to meet a security standard or policy
• third party claims arising from subcontractors engaged by the provider

How this affects providers and customers differently

If you are a cybersecurity provider, the main risk is taking responsibility for events that depend partly on the customer's systems, decisions, or internal controls. For example, you may agree to monitor a network but not control patching, user access settings, or staff conduct. A broad indemnity can still make you responsible for the whole incident if the drafting is careless.

If you are the customer, the main risk is the opposite. The provider may promise security outcomes in sales discussions but then narrow the contract so heavily that you have very little practical recourse if the service fails. You might receive only a small service credit while bearing the real cost of remediation and third party complaints yourself.

New Zealand context that matters

New Zealand businesses should read these clauses against the wider legal backdrop, especially the Privacy Act 2020, contractual obligations around confidentiality and data handling, and ordinary principles of contract law. The exact legal position depends on the contract wording and the facts, but privacy incidents can create immediate business costs even before any formal dispute starts.

Marketing statements matter too. If a cybersecurity company says its service will prevent breaches, guarantee compliance, or provide complete protection, those promises can create additional exposure. Overstated claims may raise issues under the Fair Trading Act 1986 if representations are misleading.

For some business customers, service quality rights under the Contract and Commercial Law Act 2017 and general contractual remedies may also be relevant. If the arrangement is with a consumer or a small business in a consumer-style context, the Consumer Guarantees Act 1993 may also need to be considered, although many cybersecurity arrangements are strictly business to business and may seek to contract out where permitted.

Legal Issues To Check Before You Sign

Before you sign a cybersecurity contract, make sure the indemnity lines up with the actual service being provided and the risks each side can realistically control. A well-drafted clause should allocate responsibility, not dump every possible loss on the party with the weaker bargaining position.

1. Trigger events

The first question is what actually triggers the indemnity. Broad phrases like "arising out of the services" can be dangerously wide. They may capture events only loosely connected to the provider's work.

Better drafting usually ties the indemnity to specific conduct or failures, such as:

• breach of the agreement
• negligent acts or omissions
• breach of confidentiality
• breach of privacy obligations
• infringement of third party intellectual property rights
• wilful misconduct or fraud

If you are the provider, look carefully for wording that makes you liable for any security incident, whether or not you caused it. If you are the customer, watch for wording so narrow that the indemnity becomes almost meaningless.

2. Fault and causation

The fairest clause usually requires some meaningful connection between the indemnifying party's conduct and the loss. If the contract says you indemnify the other side for losses "in connection with" an incident, that can be much broader than losses "to the extent caused by" your breach.

The phrase "to the extent caused by" is often worth pushing for. It reduces the risk that one party pays for losses partly caused by the other's poor security practices, delayed response, or internal non-compliance.

3. Scope of loss covered

Cyber incidents create unusual categories of loss. A simple reference to "all losses" may be too vague, while an itemised list may be clearer but much broader than expected.

Before you accept the provider's standard terms or the customer's paper, check whether the indemnity covers:

• legal costs and whether they must be reasonable
• forensic investigation and remediation expenses
• customer or regulator notification costs
• credit monitoring or identity protection offered after a breach
• ransom or extortion payments
• loss of revenue, loss of profit, or reputational harm
• settlement amounts and court awards
• internal management time and staff costs

Founders often focus on direct claims and miss the operational spend that follows a privacy or security event. Those follow-on costs can be substantial.

4. Liability caps and carve-outs

The cap is often the most commercially important part of the indemnity structure. If the general liability cap is set at 12 months of fees, but the indemnity for privacy breaches or confidentiality breaches is carved out, the provider may be exposed far beyond the contract value.

There is no single correct position. Some customers will insist that certain risks remain uncapped. But before you sign, make sure you understand:

• which indemnities sit inside the cap
• which indemnities are partly capped, such as at a higher multiple of fees
• which indemnities are fully uncapped
• whether the cap applies per claim or in aggregate
• whether insurance limits realistically support the risk position

5. Third party claims procedure

A good indemnity should not just say who pays. It should also say who controls the claim process. If a privacy complaint, IP dispute, or customer claim lands, delay and poor coordination can increase the overall cost.

The contract should address:

• who must notify the other party and how quickly
• who controls the defence of the claim
• whether the indemnifying party can appoint lawyers
• whether settlement requires the other party's consent
• what cooperation each party must provide
• what happens if one party wants to admit fault publicly

This is especially important where a cybersecurity provider is handling an incident affecting the customer's own clients or staff.

6. Privacy and data handling obligations

Many cybersecurity contracts are really data access contracts in disguise. The provider may process logs, user information, employee data, incident records, and other material that falls within the Privacy Act 2020 framework.

If the contract includes privacy indemnities, check how they interact with practical obligations such as:

• security standards the provider must meet
• instructions on data use and disclosure
• overseas storage or sub-processing arrangements
• incident response timeframes
• audit rights
• return or deletion of data on termination

An indemnity is not a substitute for clear operating obligations. If the operational clauses are vague, the indemnity may become the battleground after an incident.

7. Subcontractors and supply chain risk

Many cybersecurity companies use subcontractors for monitoring, threat intelligence, cloud infrastructure, or specialist testing. Customers often assume the prime contractor is responsible for that chain. Providers sometimes assume the subcontractor's own terms will protect them. Neither assumption is safe.

Before you rely on a verbal promise, make sure the contract states whether the provider remains responsible for subcontractor acts and whether subcontractor-caused losses fall within the indemnity.

8. Insurance alignment

Insurance should support the contract, not contradict it. A founder may agree to an indemnity that looks acceptable commercially, only to find the insurance policy excludes that category of loss or has lower limits.

Check whether you carry, and are required to carry, insurance such as:

• professional indemnity insurance
• cyber liability insurance
• public liability insurance where relevant

You should also check policy exclusions, retroactive dates, notification requirements, and whether contractual liabilities beyond your normal legal exposure are covered. For insurance-specific advice, speak with your broker or insurance adviser.

Common Mistakes With Indemnity Clause for Cybersecurity Company

The most common mistake is treating the indemnity as boilerplate. In cybersecurity contracts, this clause often decides the commercial risk of the whole deal.

Accepting one-way risk allocation without checking control

Providers often accept broad customer-drafted indemnities to win enterprise work. The problem is that the customer may control user access, patching, employee training, device management, and internal approvals. If the indemnity does not reflect that split, the provider may end up carrying responsibility for a mixed-fault event.

A better approach is to tie responsibility to each party's actual role and to use proportionate causation wording where possible.

Missing the gap between warranties and indemnities

A contract may contain ambitious warranties, such as commitments that services will be uninterrupted, fully secure, or compliant with all applicable laws at all times. If those warranties are then backed by an indemnity, the exposure can become much wider than founders realise.

Absolute promises rarely fit cybersecurity services. Security is usually about reasonable measures, defined scope, and response obligations, not guaranteed immunity from incidents.

Letting "consequential loss" exclusions create confusion

Many contracts exclude indirect or consequential loss, but then include a broad indemnity for all losses. If the drafting is messy, the parties may later argue about whether notification costs, business interruption, reputational damage, and third party claims sit inside or outside the exclusion.

Clear drafting is better than legal shorthand. Spell out what is covered and what is excluded.

Ignoring incident response mechanics

Some contracts contain pages of liability language but almost nothing about what happens in the first 24 to 72 hours after an incident. That creates chaos when speed matters most.

Before you sign, make sure the agreement deals with practical points such as:

• who leads the response
• who notifies affected parties or regulators
• who approves public statements
• how evidence will be preserved
• who bears urgent external adviser costs

These mechanics can reduce both loss and later disputes about the indemnity.

Assuming standard templates work for every cybersecurity service

Penetration testing, incident response retainer work, managed detection and response, software licensing, and security consulting all carry different risk profiles. A generic indemnity clause may be too broad for one model and too weak for another.

For example, a pentesting provider may need careful language around authorised access, testing windows, and customer approvals. A managed security provider may need clearer boundaries around customer obligations and inherited vulnerabilities. A software vendor may need stronger intellectual property and service limitation wording.

Relying on pre-contract statements

Founders often remember what was said in the sales process, especially statements about coverage, outcomes, or support during an incident. But once the contract is signed, the written terms usually matter most.

If a point is commercially important, put it in the agreement. That includes security standards, response times, customer responsibilities, exclusions, and any limits on the indemnity.

FAQs

Is an indemnity the same as a liability clause?

No. A liability clause sets the general rules about when a party is liable and what limits apply. An indemnity is a specific promise to cover certain losses or claims, and it may operate alongside or outside the general liability cap.

Should a cybersecurity provider accept an uncapped indemnity?

Not automatically. Some customers will ask for uncapped liability for privacy, confidentiality, or IP issues, but the right position depends on the service scope, deal size, insurance, and who controls the relevant risk. Many providers try to negotiate a cap, a higher sub-cap, or narrower trigger wording.

Can a customer ask for indemnity protection for a data breach?

Yes, that is common. The real issue is how the clause is drafted. A customer will usually want protection where the provider caused or contributed to the breach, while the provider will want to avoid liability for customer system weaknesses, staff errors, or broader environmental risks outside its control.

Do privacy law obligations replace the need for an indemnity?

No. Privacy obligations and contractual indemnities do different jobs. The Privacy Act 2020 may shape how data must be handled and what happens after a breach, but the contract still decides who bears the financial risk between the parties.

What should be negotiated first before you sign?

Focus first on the trigger events, the liability cap, carve-outs from that cap, and claim handling procedure. Those points usually have the biggest commercial effect and are much harder to fix after a dispute starts.

Key Takeaways

• An indemnity clause for cybersecurity company contracts can shift major financial risk, especially for data breaches, confidentiality failures, IP claims, and regulatory issues.
• The key questions are what triggers the indemnity, what losses are covered, whether fault and causation are addressed properly, and whether any cap applies.
• Providers should avoid accepting broad responsibility for incidents outside their control, while customers should make sure the clause gives real protection if the provider causes harm.
• The indemnity needs to match the rest of the agreement, including privacy obligations, confidentiality terms, subcontracting arrangements, service descriptions, and incident response steps.
• Insurance should be checked alongside the contract so the assumed risk position is actually supportable.
• Clear drafting before you sign is usually much cheaper than arguing later about what the clause was meant to cover.

If you want help with contract review, contract drafting, liability caps, privacy risk allocation, or service agreement negotiation, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.