Article 82: Right to compensation and liability

To operationalize the article 82: right to compensation and liability requirement, you need a documented, repeatable way to (1) identify GDPR infringements that could cause material or non-material damage, (2) assign controller/processor liability, and (3) respond to compensation claims with preserved evidence and a clear decision trail. Article 82 creates direct civil exposure for both controllers and processors. (Regulation (EU) 2016/679, Article 82)

Key takeaways:

• Treat compensation as an operational workflow (intake, investigation, decision, payment/denial, records), not a legal memo.
• Make controller vs. processor role decisions explicit per processing activity, or you will not be able to allocate liability quickly.
• Build an “evidence packet” standard so you can defend decisions to claimants, customers, or courts without scrambling.

Article 82 is where GDPR compliance turns into money risk. It gives individuals a right to compensation for “material or non-material damage” caused by a GDPR infringement, and it points that claim at the controller or processor. (Regulation (EU) 2016/679, Article 82) That means your incident response, privacy program, and third-party management processes need a clean handoff into a claims-ready posture: what happened, did it infringe the GDPR, who was responsible in that processing context, what harm is alleged, and what is your decision with supporting evidence.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to implement a single requirement-level operating procedure that ties together: your role-and-scope register (controller vs. processor per activity), your breach/issue intake and investigation process, your contracting stance with third parties, and your record retention. You are not trying to predict every claim. You are trying to guarantee that each claim is handled consistently, on documented criteria, with approvals, and with an evidence package that stands up to scrutiny.

This page gives you an implementation blueprint focused on speed, defensibility, and day-to-day execution.

Regulatory text

Excerpt (provided): “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 processor for the damage suffered.” (Regulation (EU) 2016/679, Article 82)

Operator interpretation (what you must be able to do)

You must be able to:

1. Recognize a potential GDPR infringement tied to a specific processing activity (not just “an incident happened”).
2. Connect the infringement to alleged damage (material or non-material) claimed by a person.
3. Identify who is on the hook in that context (controller, processor, or both) and respond accordingly.
4. Process the claim with documented rationale and retain records to defend your handling and any allocation of responsibility.

This is not a “pay everyone” obligation. It is a requirement to be ready for compensation claims when an infringement causes damage, and to manage the liability that follows from your role (controller or processor) in that processing chain. (Regulation (EU) 2016/679, Article 82)

Plain-English interpretation of the requirement

If your organization breaks the GDPR and a person is harmed, that person can seek compensation from you if you were the controller or the processor involved in the infringement. “Harm” is broader than direct financial loss; it can include non-material damage. Your program must therefore produce two outcomes on demand: (a) a defensible determination of whether an infringement occurred, and (b) a defensible record of what you did about the claim. (Regulation (EU) 2016/679, Article 82)

Who it applies to (entity and operational context)

Entities

• Controllers: organizations deciding purposes/means of processing personal data.
• Processors: organizations processing personal data on behalf of a controller. Both are explicitly referenced as potential payers of compensation. (Regulation (EU) 2016/679, Article 82)

Operational contexts where Article 82 becomes “real”

• Security incidents and suspected data breaches (whether or not they become notifiable).
• DSAR failures (late, incomplete, or improper responses) when a person alleges harm.
• Unlawful disclosure or sharing (internal access misuse, misdirected communications, third-party onward sharing).
• Retention and deletion failures (data kept too long; deletion not executed) connected to alleged harm.
• Third-party processing problems where you are controller using a processor, or where you are the processor and the controller points to you.

What you actually need to do (step-by-step)

Step 1: Build and maintain a role-and-scope register (controller vs. processor)

Goal: You cannot allocate liability or respond coherently if you cannot state your role per processing activity.

Create a register that maps, for each processing activity:

• Your role: controller, processor, or joint roles across different activities
• Data categories and data subjects impacted
• Systems and subprocessors involved (if any)
• Responsible business owner and privacy/security point of contact

Execution tip: Tie this to your records of processing activities if you have them; keep it operational by linking to systems and third parties, not just narratives. (Regulation (EU) 2016/679)

Step 2: Define a requirement-specific compensation & liability operating procedure

Write a short SOP that answers:

• Trigger events: inbound legal demand, customer escalation, regulator inquiry, DSAR complaint, incident post-mortem that identifies a GDPR infringement
• Named owners: privacy lead, security lead, legal counsel, finance/payments approver, customer support liaison
• Decision points: infringement determination, role determination, causation/harm review, settlement/denial approval
• Time-bound handling: use your internal service-level targets; keep them consistent across regions and business lines

Keep the SOP auditable: include required inputs, required approvals, and required outputs for each step. (Regulation (EU) 2016/679, Article 82)

Step 3: Stand up a single intake path for “compensation-related” claims

You need a controlled entry point so claims are not handled ad hoc in email threads.

Minimum requirements:

• Centralized intake channel (ticketing queue, legal intake, privacy inbox) with restricted access
• Triage tags: “Article 82 compensation,” “incident-related,” “DSAR-related,” “third-party implicated”
• Conflict check: identify if the claimant is also a customer contact, employee, or data subject in another context

Operational outcome: one system of record for claim handling and decisions.

Step 4: Standardize investigation and decision records

For each claim, create a structured decision record that includes:

• What personal data processing is involved (link to role-and-scope register entry)
• What GDPR requirement is alleged to be infringed (keep it factual; don’t speculate)
• What evidence you reviewed (logs, tickets, communications, DPIA/TRA if relevant)
• Your finding: infringement yes/no/uncertain; next steps; remediation plan
• Controller/processor allocation rationale and any third-party involvement
• Final decision: compensate / deny / request more info, with approver sign-off

This is the difference between “we think we’re right” and “we can prove we acted reasonably and consistently.” (Regulation (EU) 2016/679, Article 82)

Step 5: Align third-party contracting and operational escalation

Article 82 names processors as well as controllers. If you rely on third parties, your operational posture must include:

• Contractual clarity on roles (controller vs. processor) per service
• Incident and claims escalation paths with third parties
• Required cooperation and evidence sharing (logs, timelines, root cause evidence)
• Indemnity and limitation clauses reviewed by counsel for your risk model

You are aiming for fast fact-finding and clean allocation, not finger-pointing during an incident.

Step 6: Define the evidence packet you will retain (and where)

Create an “Article 82 evidence packet” template and store it in a controlled repository.

Include:

• Intake record and triage outcome
• Processing activity role-and-scope reference
• Incident/issue timeline and investigation notes
• Evidence list (what you reviewed; where it is stored)
• Decision record with approvals
• Customer/claimant communications
• Remediation actions and closure verification

Step 7: Run tabletop exercises that include compensation scenarios

Your incident response tabletop should include at least one inject: “data subject claims non-material damage and requests compensation.” The goal is to test your handoffs: security to privacy to legal to finance, and your evidence packet completeness. (Regulation (EU) 2016/679, Article 82)

Required evidence and artifacts to retain

Use this as your audit-ready checklist:

• Role-and-scope register covering controller/processor role, data categories, systems, third parties
• Article 82 SOP with owners, triggers, approvals, and recordkeeping requirements
• Claims intake log with triage and routing
• Per-claim evidence packet (decision record, evidence list, communications, remediation)
• Third-party contracts and addenda that define roles and cooperation expectations
• Training records for teams who might receive claims (support, privacy, security)

Daydream fit: teams commonly store these artifacts across GRC tools, ticketing systems, and contract repositories. Daydream can act as the requirement-level hub that points each Article 82 control to the exact evidence packet and owner, so you can produce a defensible file quickly without rebuilding context.

Common exam/audit questions and hangups

Expect these questions from customers, auditors, or regulators assessing your readiness:

• “Show me how you determine whether you are controller or processor for this service.”
• “Walk me through a recent incident and show the decision trail for whether a GDPR infringement occurred.”
• “Where do you track compensation-related complaints, and who approves decisions?”
• “How do you coordinate with subprocessors or other third parties when claims arise?”
• “What records do you retain to demonstrate consistent handling?”

Hangups that slow teams down:

• Role ambiguity (“we’re kind of a processor”) across product lines.
• Evidence scattered across Slack, email, and shared drives.
• Support team making commitments to claimants without legal/privacy review.

Frequent implementation mistakes (and how to avoid them)

1. Treating Article 82 as “legal will handle it.”
   Fix: write an SOP with operational owners and a ticket-based intake, then require evidence packets.

2. No role decision per processing activity.
   Fix: maintain a role-and-scope register that is tied to systems and third parties, not just policy language.

3. Inconsistent claim handling.
   Fix: use a decision record template and approval matrix so similar claims are treated similarly.

4. Over-focusing on breaches only.
   Fix: include DSAR failures, unlawful sharing, retention failures, and third-party failures in your trigger events. (Regulation (EU) 2016/679, Article 82)

5. Poor third-party escalation.
   Fix: pre-negotiate cooperation requirements and evidence access; test the path during tabletop exercises.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance does not cite specific regulator actions. Practically, Article 82 elevates your exposure in three ways: it increases the cost of control failures (compensation), it increases dispute frequency after incidents (claims intake), and it raises contract pressure between controllers and processors (allocation and indemnity). The operational answer is the same: role clarity, a repeatable workflow, and defensible records. (Regulation (EU) 2016/679, Article 82)

A practical 30/60/90-day execution plan

The plan below uses phases rather than dated promises so you can align with your internal change calendar.

Days 0–30: Establish the minimum viable workflow

• Assign owners for Article 82 claim handling (privacy, legal, security, finance).
• Stand up a single intake queue and triage tags for compensation-related matters.
• Publish the first version of the SOP and decision record template.
• Start the role-and-scope register with your highest-risk products and most-used third parties. (Regulation (EU) 2016/679, Article 82)

Days 31–60: Make it testable and auditable

• Expand the role-and-scope register to cover remaining processing activities and systems.
• Define the evidence packet standard and storage location; require it for new claims and major incidents.
• Update third-party contract playbooks to require cooperation and evidence sharing for incidents/claims.
• Run a tabletop exercise that includes a compensation claim inject; record gaps and remediation actions. (Regulation (EU) 2016/679)

Days 61–90: Operationalize across the business

• Train support, security, and privacy teams on triggers, routing, and “no ad hoc commitments” rules.
• Build reporting: open claims, time-to-triage, evidence packet completion, third-party dependency blockers.
• Add QA checks: periodic review of closed claims for consistency and completeness.
• In Daydream, map Article 82 to owners, systems, and the evidence packet checklist so audits pull from one place. (Regulation (EU) 2016/679, Article 82)

Frequently Asked Questions

Does Article 82 apply to processors, or only controllers?

It applies to both; the text states compensation may be received “from the controller or processor.” (Regulation (EU) 2016/679, Article 82) Your operational workflow should assume you may be directly named in a claim even if you process data for a customer.

What counts as “non-material damage” for claim triage?

Article 82 includes non-material damage, but the excerpt does not define categories. (Regulation (EU) 2016/679, Article 82) Operationally, treat it as a trigger for investigation and evidence preservation, then route to legal/privacy for determination under your adjudication criteria.

Do we need a separate process from incident response?

You need a defined handoff from incident response into a claims-ready workflow. Article 82 is about compensation tied to an infringement and damage, so your incident process must produce a decision record and evidence packet that can support a claim response. (Regulation (EU) 2016/679, Article 82)

How should we handle compensation claims involving a third party?

Start with role clarity and evidence access. Use your role-and-scope register to identify controller/processor roles, then trigger contractual escalation for logs, timelines, and root-cause evidence so you can allocate responsibility based on facts. (Regulation (EU) 2016/679)

What evidence do auditors or customers usually ask for?

They typically ask for proof of role determination, the operating procedure, and example decision trails showing consistent handling. Keep an evidence packet per claim with intake, investigation, approvals, communications, and remediation. (Regulation (EU) 2016/679, Article 82)

We haven’t received claims. Do we still need to do anything?

Yes. Article 82 creates the right to compensation where infringement causes damage, so readiness matters even before the first claim arrives. (Regulation (EU) 2016/679, Article 82) Build the intake path, decision record template, and role register so you are not building a process during a crisis.