Data Breach Liability Clauses in UK Contracts

A data breach can turn a supplier agreement, SaaS contract or outsourcing deal into a high stakes negotiation. Customers want protection if their personal data is exposed. Suppliers want to avoid accepting unlimited liability for every cyber incident, especially where the customer controls the data, systems or instructions.

The common mistakes are easy to make: using a standard liability cap without checking UK GDPR risk, agreeing to an unlimited data protection indemnity without knowing what it covers, or assuming a processor contract liability clause can override statutory duties. The right position depends on your role, the data involved, your security controls, your insurance and the commercial value of the deal.

A well drafted data breach limitation of liability clause helps both sides decide what losses are capped, what losses are uncapped, who deals with the regulator, and how quickly each party must act when something goes wrong.

Data Breach Liability Checklist for UK Contracts

A good data breach liability position starts with the facts of the deal, not with a copied clause from another contract. The same cap that makes sense for a low value marketing tool may be far too risky for a payroll platform, healthcare booking system or outsourced customer support provider.

Before agreeing to a cap or indemnity, map the practical risk in the contract. That means looking at what personal data is being handled, who decides how it is used, who has access to it, and what would happen if it was lost, stolen, encrypted, disclosed or changed without authorisation.

Use the following checklist when negotiating a GDPR liability clause in a UK contract:

• Identify the parties' roles: Decide whether each party is a controller, processor, joint controller or independent controller for the relevant processing.
• List the data involved: Customer names and emails are different from health data, payment information, identity documents, employee records or children's data.
• Check the breach scenarios: Consider phishing, unauthorised access, accidental email disclosure, ransomware, lost devices, API errors, insider misuse and subcontractor failures.
• Separate legal duties from contract risk: UK GDPR duties may apply directly to a controller or processor regardless of what the contract says.
• Review mandatory processor terms: If one party processes personal data for the other, the contract needs the required UK GDPR processor clauses.
• Set a realistic liability cap: The cap should reflect the deal value, the nature of the data, available insurance and likely losses.
• Decide what is uncapped: Fraud is usually uncapped. Data breaches, confidentiality breaches, indemnities and regulatory fines need careful drafting rather than assumptions.
• Define the indemnity: A data protection indemnity clause should say what claims, losses, costs and regulatory action it covers.
• Align with cyber insurance: Check whether your insurance responds to contractual indemnities, regulatory investigations, incident response costs and third party claims.
• Agree incident processes: Set notification, investigation, evidence preservation, public statements and remediation responsibilities.

For example, a small eCommerce business hiring an email marketing platform may want the platform to accept liability for a breach caused by its systems or sub processors. The platform may accept a higher cap for data breach losses, but it may reject unlimited liability for all GDPR issues, especially if the customer uploads unlawful data or gives poor instructions.

That type of compromise is often more workable than either side insisting that all data protection liability is fully uncapped or fully limited to standard fees.

What UK GDPR Does and Does Not Let You Limit

A contract can allocate financial risk between businesses, but it cannot make statutory data protection obligations disappear. UK GDPR and the Data Protection Act 2018 impose duties that sit outside your commercial bargaining position.

The Information Commission, which replaced the Information Commissioner's Office on 30 September 2026, can investigate and take enforcement action where data protection law has been breached. The Data (Use and Access) Act 2025 transferred the Information Commissioner's functions to the Information Commission. Many businesses still recognise the regulator by its former ICO branding, but contracts being entered into now should refer to the Information Commission or the regulator. A customer contract does not bind the regulator, and a limitation of liability clause does not stop individuals from bringing claims where they have a legal basis to do so. Contract wording mainly affects how the business parties allocate responsibility between themselves after an incident.

The first point is role allocation. A controller decides the purposes and means of processing personal data. A processor processes personal data on behalf of a controller and on the controller's documented instructions. Some deals involve independent controllers, where each party uses personal data for its own purposes. Some involve joint controllers, where parties jointly decide purposes and means.

This matters because the UK GDPR places different duties on each role. Controllers generally carry responsibility for lawful basis, transparency, data subject rights and breach notification decisions. Processors have direct statutory obligations too, including duties around security, sub processors, records, assistance to controllers and following instructions.

A processor contract liability clause should not suggest that the processor has no responsibility at all. It can limit commercial liability, but it should still reflect the processor's legal duties and the mandatory contract terms required under Article 28 of the UK GDPR.

Under UK GDPR, a personal data breach is a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It is broader than a hack. A misdirected email, lost laptop, over permissioned folder or faulty export tool can all create breach risk.

Controllers must notify the Information Commission where a personal data breach is likely to result in a risk to individuals' rights and freedoms. That notification must usually happen within the statutory timeframe after the controller becomes aware of the breach. If the risk to individuals is high, affected individuals may also need to be told without undue delay. Processors must notify the controller without undue delay after becoming aware of a personal data breach, with clear data breach notification steps.

The contract should support those legal duties. A supplier cannot wait ten business days to tell a customer about a breach if that delay prevents the customer from making a required notification. At the same time, a supplier may want wording that avoids premature public blame before the facts are known.

UK GDPR also includes compensation rights for individuals who suffer material or non material damage because of an infringement. The legislation has rules about responsibility and contribution between controllers and processors. Your contract can help allocate that contribution risk between the parties, but it should not be drafted as though individuals or regulators are bound by your private cap.

In practice, a limitation clause answers a narrower but commercially vital question: after a data incident, how much can one contracting party recover from the other under the contract, and for what types of loss?

How to Draft Caps and Exclusions for Breach Losses

A useful liability cap tells the parties what financial exposure they are accepting if a data breach happens. Vague wording creates arguments at the exact moment the business needs certainty.

Most commercial contracts start with a general cap, such as a fixed amount or a multiple of fees paid or payable under the contract. That may be suitable for ordinary breach of contract claims, but data breach risk often needs its own treatment. The potential loss may include forensic investigation, customer notifications, regulator correspondence, credit monitoring, PR support, remediation work, business interruption, third party claims and contract termination risk.

There are several common structures for limiting liability for data breaches:

• A single general cap: All contract claims, including data breaches, are subject to one overall limit.
• A higher data breach cap: Data protection and confidentiality claims are capped at a higher amount than ordinary claims.
• A separate super cap: Certain categories, such as data breach, cyber security or confidentiality, have their own ring fenced cap.
• Uncapped liability for selected breaches: Some losses, such as fraud or intentional misuse of data, sit outside the cap.
• Indemnity subject to a cap: The indemnity applies, but recovery is limited to a negotiated amount.
• Indemnity outside the cap: The indemnity is uncapped or has a separate cap, which can create very high exposure for the indemnifying party.

The best structure depends on bargaining power and risk. A startup providing a low cost software tool may not be able to accept unlimited liability for all personal data incidents. A larger customer may still expect a meaningful cap if the tool processes large volumes of customer records. The compromise might be a data breach cap set at a higher multiple of annual fees, backed by minimum security obligations and insurance.

Be precise about what sits inside the cap. A clause that says neither party is liable for indirect or consequential loss may not protect you from all data breach costs. Many losses that feel remote in practice may still be claimed as direct losses depending on the facts and drafting. Incident response costs, replacement supplier costs and regulatory investigation costs should be addressed directly if they matter.

Businesses should also decide whether the cap applies to:

• claims by the customer against the supplier only, or claims by both parties
• all data protection law breaches, or only personal data breaches
• breaches caused by the party's own acts and omissions, or also by its staff, contractors and sub processors
• regulatory fines and penalties, where recoverability and public policy concerns need careful treatment
• compensation claims brought by individuals
• costs of notifying regulators, customers, employees or users
• cyber forensic experts, legal support, call centres, credit monitoring and PR costs
• loss of profit, loss of revenue, loss of goodwill and reputational harm

Regulatory fines need particular care. A customer may ask a supplier to indemnify it for fines imposed because of the supplier's breach. A supplier may push back because fines are imposed by a regulator, may reflect the customer's own compliance failings, and may raise enforceability and public policy issues. A more balanced position may cover reasonable costs and third party claims caused by the supplier's breach, while treating fines separately and only to the extent recoverable by law.

Exclusions should also be drafted carefully. Some contracts exclude liability for loss of data, loss of business or loss of goodwill. If those exclusions apply without carve outs, they may remove much of the practical protection the data breach clause was meant to provide. If a customer is relying on a supplier to protect customer records, it may need carve outs stating that the exclusion does not apply to breach notification costs, restoration costs or claims from affected individuals.

The Unfair Contract Terms Act 1977 can also be relevant to clauses that restrict liability in business contracts, particularly where standard terms are used. Certain exclusions and limitations must satisfy reasonableness requirements. A one sided cap hidden in standard terms may be more vulnerable than a negotiated clause that reflects the deal, insurance and data risk.

A practical drafting approach is to create a liability schedule or clause that separates ordinary contract claims, payment obligations, confidentiality, data protection, IP infringement, fraud and deliberate wrongdoing. That way, no one has to guess whether a data protection indemnity is swallowed by a general cap or survives as uncapped exposure.

Indemnities, Processor Clauses and Negotiation Points

A data protection indemnity shifts specific losses from one party to another, but it should not become an open ended promise to pay for every privacy problem connected to the relationship. The wording needs to match the responsibilities each party actually controls.

An indemnity is often more powerful than an ordinary damages claim because it can change how loss is recovered. Depending on drafting, it may cover certain third party claims, regulatory costs or expenses without the same arguments about foreseeability and mitigation. That is why suppliers often resist broad wording, and why customers ask for it where they are trusting the supplier with valuable or sensitive data.

A balanced data protection indemnity clause usually answers these questions:

• Trigger: Does it apply to any breach of data protection law, any personal data breach, a breach of the contract's data processing terms, a specific data processing schedule, or only a breach caused by negligence, wilful misconduct or failure to follow instructions?
• Covered losses: Does it cover third party claims, data subject compensation, regulator investigation costs, fines where legally recoverable, notification costs, remediation costs and professional fees?
• Fault and control: Does the indemnity apply only to losses caused by the indemnifying party, including its staff and sub processors?
• Cap: Is the indemnity uncapped, included in the general cap, or subject to a separate data protection cap?
• Claims control: Who manages regulatory correspondence, settlement discussions and communications with affected individuals?
• Mitigation: What must each party do to reduce harm and avoid unnecessary costs?

For processors, the contract must also contain the required processing terms. These terms are not just legal housekeeping. They can affect liability in a real incident because they define instructions, security requirements, audit rights and assistance obligations.

A processor contract should usually address:

• the subject matter and duration of processing
• the nature and purpose of processing
• the types of personal data and categories of data subjects
• the controller's documented instructions
• confidentiality obligations for people authorised to process the data
• appropriate technical and organisational security measures
• rules for appointing and changing sub processors
• assistance with data subject rights, breach notifications and data protection impact assessments
• return or deletion of personal data at the end of the services
• audit, information and compliance support

These obligations should connect to the liability clause. For example, if the supplier must notify the customer of a breach without undue delay, the contract can also say that avoidable losses caused by late notification are covered by the data breach cap or indemnity. If the customer must approve sub processors, the contract can say whether unauthorised sub processing is subject to a higher cap or uncapped if it results in a breach.

Negotiation often becomes easier when each side separates controllable risks from shared risks. A supplier can reasonably accept responsibility for its own platform security, staff access controls, approved sub processors and failure to follow documented instructions. It may resist liability for data the customer uploads unlawfully, weak passwords used by the customer's own employees, an inaccurate privacy policy, or the customer's failure to respond to data subject requests.

Customers should be cautious about clauses that make the supplier's obligations too narrow. If the supplier is hosting or managing personal data, wording that limits its responsibility to deliberate acts only may leave the customer exposed for negligent security failures. A middle ground position may require the supplier to maintain appropriate security measures, comply with agreed policies, meet breach notification obligations and accept liability for failure to do so.

Suppliers should be cautious about accepting responsibility for the customer's entire data protection compliance programme. A clause saying the supplier indemnifies the customer for all losses arising from any breach of data protection law may capture failures the supplier cannot control, such as the customer's lack of lawful basis or misleading privacy notice.

Cyber insurance is another negotiation tool, but it is not a substitute for good drafting. Some policies exclude liability assumed under contract unless the business would have been liable anyway. Some cover incident response but not contractual penalties. Some exclude certain regulatory fines. The contract should not promise cover that the business cannot fund or insure.

Founder moments often make the issue clear. A SaaS founder closing an enterprise customer may feel pressure to accept the customer's standard uncapped GDPR liability clause to get the deal signed. That decision can create exposure far beyond the annual contract value. A better response is to explain the security controls, offer a dedicated data breach cap, accept a targeted indemnity for supplier caused breaches, and exclude losses caused by the customer's instructions or systems.

For a customer appointing a payroll, CRM or support desk provider, the commercial concern is different. If the supplier's error exposes employee bank details or customer records, a cap equal to one month's fees may not cover response costs. The customer may ask for a higher cap, mandatory insurance, audit rights, stronger sub processor controls and a clear indemnity for third party claims caused by the supplier's breach.

Plain English drafting can reduce disputes. Instead of saying data protection liability is capped except where it is not capped under the indemnity, use a structure that says exactly which claims fall into each bucket. Define personal data breach. Define data protection laws to include UK GDPR, the Data Protection Act 2018 and the Privacy and Electronic Communications Regulations where relevant. State whether references to losses include reasonable professional costs and expenses.

Contract documents should also work together. The limitation clause, data processing agreement, confidentiality clause, security schedule, acceptable use policy, service levels and order form should not contradict each other. If the order form says the supplier stores data in the UK only, but the processor schedule allows global sub processing without approval, the liability debate becomes harder after an incident.

FAQs

Can You Limit Liability for a Data Breach Under UK GDPR?

You can limit contractual liability between businesses, but you cannot contract out of statutory duties under UK GDPR or stop the Information Commission from taking action. A cap mainly controls what one contracting party can recover from the other under the contract.

Should Data Breach Liability Be Uncapped?

Not always. Uncapped liability may be appropriate for fraud, intentional misuse of data or unauthorised selling of personal data. For ordinary security failures, many businesses negotiate a higher data protection cap rather than unlimited exposure.

What Is a Data Protection Indemnity Clause?

A data protection indemnity clause is a promise by one party to cover specified losses arising from data protection breaches or personal data breaches. It should define the trigger, covered losses, fault requirement, cap and claims process.

Does a Processor Need Its Own Liability Clause?

Yes, processors should have liability wording that works with their Article 28 processing obligations. The clause should cover supplier caused breaches, sub processors, breach notification delays and assistance duties without making the processor responsible for risks controlled by the customer.

Can a Contract Make the Other Party Pay Regulatory Fines?

Sometimes a contract tries to allocate responsibility for regulatory fines, but this area needs careful drafting. Fines may raise public policy and recoverability issues, and the wording should separate fines from response costs, third party claims and compensation.

Key Takeaways

• A data breach limitation of liability clause should reflect the type of personal data, the parties' UK GDPR roles, the deal value and realistic breach costs.
• Contractual caps do not remove statutory duties under UK GDPR, the Data Protection Act 2018 or the Information Commission's enforcement powers.
• A higher or separate data breach cap is often more balanced than putting all GDPR liability under a low general cap or making every privacy issue uncapped.
• Data protection indemnities should be specific about triggers, covered losses, responsibility, regulator costs, third party claims and whether the indemnity is capped.
• Processor contracts need mandatory UK GDPR terms, including instructions, security, sub processors, breach notification, assistance, deletion and audit rights.
• The liability clause, processor schedule, confidentiality terms, security schedule and insurance position should all point in the same direction.

If you are negotiating liability for a data breach, Sprintlaw UK's legal team can help with your supplier agreement, data processing terms, privacy policy and data protection indemnity wording. Contact us on 08081347754 or team@sprintlaw.co.uk for a free, no obligations chat.