GDPR Article 82 — Data Breach Liability and Compensation: How Much Are SaaS Developers Exposed?

Post #870 in the sota.io EU Cyber Compliance Series

Most SaaS developers know that a data breach can result in a regulatory fine under Article 83 GDPR. Far fewer understand that the same breach can simultaneously expose them to civil liability claims from every affected individual under Article 82 GDPR — with no cap and no supervisory authority gatekeeping the process.

Article 82 creates a direct right of action. Any natural person who suffers material or non-material damage as a result of a GDPR infringement can bring a claim in the civil courts of any EU member state where the defendant has an establishment, or where the data subject habitually resides. The enforcement action from a DPA and the civil claim from an individual are entirely independent. They can run simultaneously. They can result in liability even if the DPA decides not to fine.

For SaaS developers — particularly those operating as processors under Article 28 agreements — Article 82 has specific mechanics that are frequently misunderstood. This guide explains how liability is allocated, when you as a processor can be held liable directly, what exemptions exist, and how your technical and contractual posture affects your exposure.

The Article 82 Framework

Article 82(1) states:

"Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or the processor."

Three elements must be satisfied for a claim:

1. An infringement of the GDPR — a breach of any provision, not just a security failure
2. Damage — material (financial loss) or non-material (distress, loss of control over personal data, reputational harm)
3. Causal link — the damage must result from the infringement

The inclusion of non-material damage is significant. It means a data subject does not need to demonstrate that their credit card was used fraudulently or that they lost income. The anxiety caused by having their medical records exposed, the distress of a compromised email address, the loss of control over their personal information — these are compensable under Article 82. In practice, this is what drives mass litigation after large breaches.

Controller vs Processor Liability Under Article 82

The Default Rule

Article 82(2) establishes the starting point:

"Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors, or where it has acted outside or contrary to the lawful instructions of the controller."

This creates an asymmetry:

For SaaS developers acting as processors: Your exposure is narrower — but it is real. The processor-specific obligations under the GDPR include:

• Article 28(3): processing only on documented instructions
• Article 29: confidentiality obligations on authorized persons
• Article 30(2): maintaining records of processing categories
• Article 32: implementing appropriate security measures
• Article 33(2): notifying the controller of a breach without undue delay
• Article 37: appointing a DPO when required
• Articles 44–49: restrictions on international transfers

A breach of any of these exposes the processor to direct Article 82 liability.

The "Outside Instructions" Trap

The second limb of processor liability — acting outside or contrary to lawful instructions — is broader than it appears. It includes:

• Sub-processing without controller authorization: If your DPA requires prior written consent from the controller before engaging sub-processors, and you add a new cloud service without that consent, you have processed outside the controller's instructions. Any breach involving that sub-processor creates direct liability for you.
• Unauthorized international transfers: If the controller's instructions restrict processing to the EU, and you route data through a US-based logging service, you have violated the instruction scope.
• Retaining data beyond the controller's retention schedule: If the DPA specifies deletion within 30 days of contract termination and you retain data longer, any subsequent exposure of that data is processing contrary to instructions.

Joint and Several Liability

Article 82(4) introduces joint and several liability where multiple parties are involved:

"Where more than one controller or processor, or both a controller and a processor, are involved in the same processing and where they are, under paragraphs 2 and 3, responsible for any damage caused by processing, each controller or processor shall be held liable for the entire damage in order to ensure effective compensation of the data subject."

This means a data subject can sue any one party for the full amount of compensation — including you as the processor, even if the primary fault lies with the controller. The party that pays then has a right of contribution from the others under Article 82(5).

In practice, this creates significant litigation risk for SaaS processors:

1. A controller suffers a breach due to their own misconfiguration
2. A data subject sues both the controller and you (the processor) under Article 82(4)
3. You must defend the claim and prove your Article 82(3) exemption applies
4. Even if you win on the merits, you have incurred legal costs

The Exemptions

Article 82(3) provides an exemption from liability:

"A controller or processor shall be exempt from liability under paragraph 2 if it proves that it is not in any way responsible for the event giving rise to the damage."

This is a complete exemption, but the burden of proof rests on the defendant. You must prove non-responsibility — the data subject does not need to prove your fault.

The Court of Justice of the European Union (CJEU) has developed case law on how this exemption operates:

C-340/21 (VB v Natsionalna agentsia za prihodite, 2023): Unauthorized disclosure risk as non-material damage

The CJEU confirmed that the mere fear that personal data may be misused after unauthorized disclosure — even without proof that the data has actually been misused — can constitute non-material damage compensable under Article 82. This dramatically lowers the threshold for claims following a breach.

The Court also clarified that the security measures implemented by the controller are not decisive in themselves. Even if you had "appropriate" security measures under Article 32, this does not automatically exempt you under Article 82(3) if a breach nonetheless occurred. You must demonstrate that you are "not in any way responsible" for the event — not merely that you followed a reasonable security standard.

C-590/22 (AT v PS GmbH, 2024): Processor exemption scope

The CJEU ruled that a processor that processes only on documented instructions from the controller, implements the security measures required by Article 32, and notifies the controller of the breach without undue delay is entitled to the Article 82(3) exemption — even if a breach occurs at the infrastructure level. The key is demonstrating compliance with each processor obligation and the absence of fault in the causal chain.

Calculating Exposure: Non-Material Damage Awards

Article 82 provides no cap on compensation and no fixed tariff. National courts apply their own standards within the GDPR framework.

German courts (OLG München, OLG Frankfurt, LG München) have awarded:

Dutch courts have applied similar ranges. Irish courts have seen awards at the lower end as case law develops.

For a SaaS platform with 50,000 users, a breach exposing email addresses and usage data could generate:

• 50,000 × €300 average claim = €15,000,000 in aggregate civil liability
• Plus legal costs of defending each claim or a class action

This is before any Article 83 regulatory fine. The two are independent.

Class Actions and Collective Redress

Article 80 GDPR allows data protection NGOs and representative bodies to bring claims on behalf of data subjects without an individual mandate in member states that permit this. Germany, Austria, and the Netherlands have enacted legislation enabling such collective actions.

The practical risk:

• A consumer rights organization files a collective claim covering all affected users
• The claim combines Article 82 compensation with injunctive relief
• Your legal exposure becomes a single massive proceeding rather than thousands of small ones
• Settlement pressure is disproportionate to individual claim values

noyb (None Of Your Business), the Max Schrems-founded NGO, has filed hundreds of complaints under this framework. Similar organizations have begun strategic litigation using Article 80 collective action as a lever.

Processor Risk Reduction: Practical Steps

1. Structure Your DPA to Create Clear Instruction Scope

Your Article 28 DPA should define the precise scope of processing instructions. Ambiguity works against you in Article 82(3) exemption claims — if the instruction scope is unclear, a court may find you acted "outside" instructions even when you intended to comply.

Include:

• Enumerated list of processing operations (not just "processing necessary to provide the service")
• Explicit authorization for every sub-processor by name or category
• Geographic restriction clauses specifying permitted processing locations
• Data retention schedule tied to specific deletion triggers

2. Document Your Article 32 Controls Formally

The Article 82(3) exemption requires you to show you are "not in any way responsible" for the breach. This means demonstrating:

• The security measures implemented (encryption, access controls, patching cadence)
• That the breach arose from a cause outside your control or attributable solely to the controller
• That you notified the controller without undue delay under Article 33(2)

Create and maintain:

• A security controls inventory mapped to Article 32's four factors (nature, scope, context, purposes; likelihood and severity of risk)
• Incident response logs documenting the timeline from detection to controller notification
• Penetration testing records and remediation logs

3. Contractual Allocation of Liability

Your Article 28 DPA can include indemnification clauses that allocate Article 82 claims between controller and processor. While these clauses do not affect data subjects' rights (they can still sue either party), they govern the contribution rights under Article 82(5).

Common structures:

• Mutual indemnification based on fault allocation: the party whose non-compliance caused the breach indemnifies the other for Article 82 damages
• Liability caps tied to annual contract value for processor-caused incidents (enforceable between commercial parties, not against data subjects)
• Insurance requirements: requiring both parties to maintain cyber liability insurance covering Article 82 exposure

4. Sub-Processor Chain Management

Every sub-processor in your chain creates potential Article 82 exposure. If your sub-processor suffers a breach due to their own security failure, you may still be liable to the controller under Article 28(4) and exposed to data subject claims under Article 82(4).

Mitigate by:

• Flowing down Article 28(3) obligations to all sub-processors contractually
• Conducting security due diligence before onboarding sub-processors
• Including breach notification obligations that match your upstream notification SLA
• Auditing sub-processor compliance annually (Article 28(3)(h))

5. Use EU Infrastructure to Reduce Transfer-Related Exposure

Article 82 liability extends to GDPR infringements — including unauthorized international data transfers. Using US-based cloud infrastructure without adequate transfer mechanisms (post-Schrems II SCCs, TIA, BCRs) creates both Article 83 fine exposure and Article 82 claim exposure.

SaaS platforms running on EU-based infrastructure — with no parent-company access rights creating CLOUD Act exposure — eliminate the transfer liability vector entirely. This is not a marketing point: it is a legal risk reduction that directly affects your Article 82 exposure profile.

Article 82 in the Context of Article 83 Enforcement

Articles 82 and 83 are independent tracks but often arise from the same incident.

A key implication: a DPA decision to close an investigation or issue only a warning does not bar Article 82 claims. Data subjects can still bring civil actions even if the supervisory authority determines not to impose a fine.

Incident Response: The Article 82 Lens

When a breach occurs, your incident response workflow must operate on two tracks simultaneously:

Track 1 — Regulatory (Articles 33–34):

• 72-hour notification to supervisory authority
• Individual notification where high risk exists
• Documentation for DPA investigation

Track 2 — Civil liability (Article 82):

• Evidence preservation (logs, access records, security controls documentation)
• Legal privilege consideration for investigation communications
• Assessment of damage scope for potential class action exposure
• Notification to cyber liability insurer
• DPA review and potential update

The evidence preserved in Track 2 is also your primary material for the Article 82(3) exemption defense. Failure to preserve it during incident response is itself a risk.

Summary: Article 82 Exposure Checklist

Article 82 is not a theoretical risk. As GDPR enforcement matures, class action litigation under Article 80 and collective redress mechanisms will increase. SaaS developers who structure their DPAs carefully, document their security controls formally, and choose their infrastructure to minimize transfer violations are significantly better positioned than those who treat Article 82 as a controller problem.

This post is part of the sota.io EU Cyber Compliance Series. Related posts: GDPR Articles 33 & 34: The 72-Hour Breach Notification Rule, GDPR Enforcement 2024–2026: Top Fines and Lessons for SaaS Developers, GDPR Article 28: Data Processing Agreements.