Controller vs Processor: Who Reports a Data Breach?

GDPR breach notification is one of the easiest places for teams to stumble—especially when vendors and sub-processors are involved. In most cases, the controller is the party that reports a qualifying personal data breach to the supervisory authority (and sometimes to affected individuals), while the processor must notify the controller without undue delay and help the controller investigate and report.

TL;DR - Controllers report qualifying personal data breaches to regulators (and sometimes affected people). - Processors generally do not report to regulators; they must notify the controller without undue delay. - Most failures happen in the handoff: vague DPAs, unclear contacts, and slow evidence sharing.

Detailed explanation

For incident response, the operational question maps to the legal one:

• Controller: decides the purposes and means of processing.
• Processor: processes personal data on behalf of the controller.

Reporting responsibility generally follows decision authority: the controller makes the decision and files the notification; the processor escalates quickly and supplies facts.

What this means in practice for your team

If you’re the controller (you decide how and why data is processed), you own the external notification decision and execution:

• Notify the regulator when the breach is likely to result in a risk to individuals’ rights and freedoms.
• Notify individuals when the breach is likely to result in a high risk.
• Document the breach even if no notification is required.

If you’re the processor (you process under the controller’s instructions), your priorities are speed and evidence preservation:

• Notify the controller without undue delay once you are “aware” of a personal data breach.
• Provide what the controller needs to assess scope/severity and meet deadlines (categories of data, approximate number of records/individuals, likely consequences, and mitigations).

Where teams get burned

1. 72-hour clock management (controller). The controller’s regulator notification deadline is commonly described as 72 hours from “awareness.” If a processor delays escalation, the controller can miss the window or be forced into a low-confidence filing.
2. Multi-party chains. Sub-processors notify processors who notify controllers. Each hop adds latency unless contracts enforce rapid escalation.
3. “Security incident” vs “personal data breach” mismatch. Vendor updates that don’t clearly state whether personal data was impacted prevent controllers from making a timely notification decision.

What to do next (actionable steps)

If you are a controller

• Treat vendors/processors as part of your breach notification pipeline. Require in the DPA:
• A concrete notification SLA (e.g., within X hours of awareness/confirmation).
• Minimum content fields (systems affected, data categories, approximate counts, time window).
• Log retention, forensic cooperation, and secure evidence transfer procedures.
• Maintain a regulator-ready breach record template (detection time, awareness time, containment actions, and decision rationale).

For baseline security terminology you can reference in your DPA and internal playbooks, see Multi-Factor Authentication (MFA): what is multi factor authentication.

If you are a processor

• Build a “controller notification kit” you can send fast:
• What happened, when, how detected, affected systems/tenants, and current understanding of personal data impact.
• Containment actions taken and recommended customer mitigations.
• Evidence package summary (log sources, retention periods, and secure export method).
• Ensure escalation is operational, not just legal:
• Named contacts, 24/7 notification method, and backup channels.
• A pre-approved secure channel for sharing sensitive forensic artifacts.

If a breach involves session tokens or identity artifacts, ensure your kit can explain the risk clearly and quickly. Related reading on a common pitfall: what is jwt confused deputy.

Technical notes (for Security/IR teams)

Even if Legal submits the filing, Security needs defensible timestamps and a credible early scope estimate. A lightweight approach is to standardize incident artifacts and generate an “awareness timeline” from case notes and logs.

# Example: create an evidence bundle with key timestamps (adjust to your environment)
mkdir -p breach_bundle/{logs,notes}
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee breach_bundle/notes/bundle_created_utc.txt

# Pull authentication and admin activity around suspected compromise window
zgrep -hE "login|mfa|admin|token|export" /var/log/auth.log* \
  | tail -n 2000 > breach_bundle/logs/auth_tail.txt

# Capture running version/config snapshot (helps explain exposure and mitigations)
uname -a > breach_bundle/notes/system_uname.txt
ss -lntp > breach_bundle/notes/listeners.txt

# Record the “awareness” decision time in writing (who/when declared it a personal data breach)
printf "Awareness declared by: ______\nUTC time: ______\nBasis: ______\n" \
  > breach_bundle/notes/awareness_record.txt

Common misconceptions

“The processor reports to the regulator because they had the incident.”

Usually wrong. Under GDPR’s controller/processor model, the controller is typically the notifier to the supervisory authority. The processor’s legal duty is to inform the controller quickly and provide the facts needed for assessment and reporting.

“If we outsource everything to a SaaS vendor, they become the controller.”

Not automatically. Many SaaS providers are processors for customer content but may be controllers for their own account/admin data, telemetry, billing, or marketing. For breach reporting, you must be clear about which data was affected and in what capacity each party acted.

“We have 72 hours to investigate before telling anyone.”

No. The controller generally must notify within 72 hours of awareness. An initial notification can be filed with limited details, followed by updates as facts are confirmed.

“Encryption means we never have to notify individuals.”

Not guaranteed. Strong encryption can reduce risk and may change whether individual notification is required, but you still need to assess whether keys were exposed and whether residual risk remains.

“Our DPA says the vendor will notify regulators, so we’re covered.”

Be careful. Contracts can allocate tasks, but regulators typically look to the controller for compliance. If you delegate external notification steps, you still need governance: confirmation of what was filed, when, and on what basis—plus alignment on what is communicated to affected individuals.

Tools that can help (only if they fit your workflow)

If part of your breach risk is credential reuse, password spraying, or poor secrets hygiene across teams, a password manager can reduce the chance that an incident becomes a reportable personal data breach (or limits its scope). If you’re evaluating options, consider 1Password here: Try 1Password →.

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.