The controller retains the core notification duty to the competent supervisory authority, while the processor must inform the controller and support the response. Contracts should spell out how Article 33(2) requirements are met, including escalation timing, information sharing, and responsibilities for notifying authorities and affected individuals when notification is required.
Who holds the notification duty in a processor breach
The legal ownership of the core breach notification duty sits with the controller, because the controller is the party responsible for deciding the purposes and means of processing and for notifying the supervisory authority where required. The processor’s role is narrower but still operationally critical: it must detect, inform, and support the controller fast enough for the controller to meet statutory deadlines.
That split matters because a processor incident can still create controller-facing notification obligations. If the processor delays escalation, omits key facts, or assumes the controller will discover the issue independently, the controller can miss the statutory window or understate the breach’s scope. The obligation is therefore owned by the controller, but it is executed through processor-to-controller notification discipline.
How Article 33(2) changes processor obligations
Article 33(2) does not make the processor the primary notifier to the authority, but it does require the processor to notify the controller without undue delay after becoming aware of a personal data breach. That means breach handling for processors is not just a contractual courtesy. It is a time-sensitive control point that should define what gets reported, how quickly, and in what minimum detail.
In practice, the processor should be prepared to pass enough information for the controller to assess likely risk, determine whether the breach is notifiable, and decide whether data subjects must also be informed. Helpful facts include the nature of the incident, the categories and approximate volume of data involved, likely consequences, containment actions, and any known exposure path. If those details are missing, the controller’s legal assessment becomes guesswork.
Contracting, escalation, and practitioner ownership
The cleanest operating model is to treat breach notification as a shared workflow with a single legal owner. The controller owns the statutory filing decision, but the processor contract should make escalation timing, investigation support, evidence sharing, and contact points explicit so there is no ambiguity during an incident. This is especially important where multiple subprocessors, cross-border processing, or rapid containment decisions can compress the response window.
Practitioners should also be clear about who drafts authority-facing language, who validates facts, and who owns communications to affected individuals when notification is required. If the controller and processor have different incident teams, notification responsibility fails most often at the handoff layer, not at the legal interpretation layer. The control objective is to make the handoff measurable, rehearsed, and contractually enforceable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 — Legal and Regulatory Requirements | Breach notification ownership must align with regulatory duties and contractual obligations. |
| RS.CO-02 — Incident Reporting | Processor-to-controller escalation is an incident reporting workflow that must happen quickly. | |
| RC.CO-03 — Public Relations and Reputation | Notification decisions affect downstream communications to affected individuals and regulators. | |
| Recommendation — Map breach notification duties to the accountable party and verify incident workflows meet legal deadlines. Define who reports what, to whom, and by when during a data breach. Coordinate breach communications so external notifications stay factually consistent and timely. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity assurance and account compromise considerations can inform breach assessment and notification evidence. |
| Recommendation — Use identity evidence from the incident to support impact assessment and response decisions. | ||
Practitioner Guidance
What to verify: Confirm that processor agreements define “without undue delay” in operational terms, identify named escalation contacts, and require the processor to provide enough incident facts for a controller risk assessment. If a processor cannot produce a timely, structured breach notice, the controller is not actually in control of the statutory timeline.
What good looks like: A breach playbook that distinguishes legal ownership from operational dependency, with tested escalation paths, evidence-sharing obligations, and pre-agreed decision points for authority and data-subject notification.
Practitioner takeaway: The controller owns the notification duty, but the processor must make that duty executable by getting accurate breach facts to the controller fast enough to preserve the legal deadline.
Related resources from NHI Mgmt Group
- Who should own response when a telecom breach affects both customer data and sensitive government communications systems?
- Who should own remediation when a vendor breach affects shared systems and data flows?
- Why is it important to integrate identity and data governance?
- Who is accountable when a SaaS processor mishandles personal data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
