Article 33(2) Processor notification to the controller

What Article 33(2) asks processors to do, and why the 72 hours depend on it

Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach. The processor's job at this stage is speed and content, not judgment. It does not decide whether the breach is likely to result in a risk to individuals, and it does not decide whether the supervisory authority must be told. Under the EDPB's Guidelines 9/2022, the controller is in principle considered aware once the processor has informed it, so the controller's 72-hour clock under Article 33(1) effectively starts when the processor's notice arrives. If your platform hosts a customer's personal data and a breach is confirmed in your environment, the question you must answer quickly is not "is this notifiable?" but "has the customer been told, with enough facts to act?"

This is harder in practice than the rule suggests. Processors often detect incidents later than the controller would expect, because monitoring sits in the processor's infrastructure and alerts may be triaged as operational faults before anyone links them to personal data. Awareness is also uneven: a suspicious log pattern may take hours to confirm as a breach, and teams disagree about when that point was reached. Multi-tenant platforms add a further problem. One incident may touch several controllers' data, and each controller needs its own notice, so the processor must be able to identify affected tenants quickly from its logs and asset inventory.

Confirm three things with your customers and in your processor contracts before an incident. First, the notice period the contract sets, expressed in hours rather than "without undue delay" alone, since the EDPB recommends that contracts can require early notification to support the 72-hour deadline. Second, the minimum initial content, such as the nature of the incident, the categories of data and tenants likely affected, and a named contact. Third, the phased follow-up you will provide as facts emerge. Article 28(3)(f) also requires processors to assist controllers with Articles 32 to 36, so the contract should state that assistance explicitly. Use the Commission's standard contractual clauses for controllers and processors as a checklist when reviewing your own terms.

Which systems, teams and contracts fall under the processor duty

Whether the Article 33(2) duty applies to a given system depends on the organization's role, where customer personal data sits, and who else touches it. The cards below cover the decisions that change the work, from role determination to multi-tenant platforms where one incident reaches several customers at once.

Role for each service

The duty applies only where the organization acts as a processor for a specific service. The same company can be a controller for its own marketing data and a processor for a customer's hosted application. Map each service to a role before writing the notice procedure, because a processor that decides purposes or means of processing may be treated as a controller. Ask legal to confirm the role per service in writing, and record it in the processing register.

Hosted and managed systems holding customer data

Inventory every hosted, managed or self-hosted platform that stores or processes customer personal data, including backups, logs, support exports and staging copies. Each one can be the point where a breach occurs and starts the clock for the controller. Check which systems ingest customer data automatically, such as monitoring or error tracking, because those often escape the original scope review. Confirm how each system is detected and triaged so the organization knows when it becomes aware.

Subprocessors in the chain

When the organization engages a subprocessor, the subprocessor must notify the organization, and the organization must then notify its controllers. Each link in the chain adds time, so notice periods must be shorter downstream than the controller's own deadline allows. List every subprocessor that touches customer data, its hosting location and its contract notice terms. Check that flow-down terms are in place for each one, since a missing clause at one link breaks the whole chain.

Contract notice terms

Processor contracts must require assistance with breach-related duties, and the controller-processor clauses in the Commission's standard set address breach notification directly. Review each customer contract for the notice period, the named contact, the content expected in early notice and the update cadence. Where a contract is silent or vague, the processor will have to infer its obligations under pressure. Align contract notice times with the controller's 72-hour window.

Multi-controller platforms

A shared platform serving several customers creates one incident affecting several controllers. The processor must report to each affected controller, not only the largest one or the first to ask. Map tenants to the data they hold, so the organization can identify which controllers are affected without a lengthy investigation. Decide in advance who sends each notice and whether any controller has authorised the processor to notify the supervisory authority on its behalf.

Shared responsibility with internal teams

Engineering, platform operations, support and sales each hold a piece of the processor duty. Support staff may receive the first report from a customer, while platform engineers detect the anomaly and legal reviews the contract. Name the owner for each step and define how each team escalates to the incident lead. Confirm that the on-call and escalation paths cover weekends and time zones, since the notice clock runs regardless of staffing.

How an assessor tests processor breach notification

This table compares the five areas an assessor typically tests for processor notice to the controller, with the approach, the evidence requested and the gaps that come up most often. Read each row as a question the assessor will ask the processor, then check whether the answer is backed by a document or a log rather than a verbal assurance. The main takeaway is that the contract, the incident procedure and the timestamped logs must agree with each other before the test begins.

Test area	Test approach and evidence requested	Common findings
Processor contract terms	Read the controller-processor agreement for a defined notice window after awareness, required content of the notice, and an obligation to assist with the controller's duties under Articles 32 to 36. Confirm the terms match the standard contractual clauses if those are used.	Notice is tied to vague wording such as 'promptly' with no defined window, or the contract omits content requirements and phased updates.
Incident procedure and on-call route	Request the written incident response procedure and the escalation path to the controller's named contacts. Ask for evidence that the route works, such as a recent tabletop exercise record or a dated test notification.	Procedure names a security mailbox that nobody monitors out of hours, or contact details for controllers are out of date.
Awareness and notice logs	Sample past incidents and compare the time the processor detected the breach, the time it was recorded as aware, and the time the controller was informed. Confirm the timestamps come from system logs or ticket records, not reconstructed notes.	Detection and escalation times are missing or inconsistent, or the awareness timestamp is set later than the first alert without a reason.
Subprocessor flow-down	Review contracts with each subprocessor to confirm they must notify the processor early enough for the processor to meet its own duty to the controller. Ask for the register of subprocessors and the clauses that apply to them.	Subprocessor terms allow notice after a fixed delay that would leave the processor unable to inform the controller in time.
Multi-controller incidents	Where one incident affects several controllers, ask how the processor identifies the affected customers, whether it sends each controller a notice, and who decides on any notification made on a controller's behalf. Review the authorisations on file.	A single generic notice is sent to all customers, or authority notifications are made without written authorisation from each controller.

How contracts set notice times and content so the controller can meet 72 hours

The processor agreement is where Article 33(2) becomes something a controller can operate. The regulation requires the processor to notify the controller without undue delay after becoming aware of a breach, but it does not fix an hour value, and the controller's own 72-hour clock depends on how quickly that notice arrives. The contract should therefore define a notice window measured from awareness, state what counts as awareness for the processor's staff and monitoring systems, and name the single channel and the named contacts who receive the notice, including out-of-hours escalation. Confirm the exact window with counsel and with your own risk position, since the right value depends on your notification process, your staffing and how much time your team needs to make the decision under Article 33(1). No fixed hour value is supplied for this section, so treat any number in a draft as a negotiating position to be tested, not a standard.

Contract terms should also set what the first notice must contain and what follows it. EDPB Guidelines 9/2022 say the processor does not need to assess the likelihood of risk before notifying, so the first notice can be short: what happened, when it was detected, which systems and data categories appear affected, and what containment has started. The contract should commit the processor to phased follow-up updates on a stated cadence until the incident is closed, and to a final report covering root cause and remedial action. Article 28(3)(f) requires processor contracts to oblige the processor to assist the controller with Articles 32 to 36, so the agreement should name the logs, forensic records and timelines the processor will hand over to support the controller's notification and documentation duties.

Clause 9 of the Commission's controller-processor standard contractual clauses (Decision (EU) 2021/915) sets out personal data breach notification duties, and many organizations use it as the baseline for their own addendum. Read it alongside your existing data processing agreement and check that the notice window, content and phasing are consistent across both documents. Where a processor serves several controllers, confirm how it will report one incident to each affected controller and who authorises it to notify a supervisory authority on a controller's behalf, while legal responsibility stays with the controller. Ask counsel to review the agreed wording against the GDPR text on EUR-Lex before signature.

Implementing processor notification step by step

This sequence turns the Article 33(2) duty into a working route: the processor recognises a breach, tells each affected controller without undue delay, and leaves an evidence trail that lets the controller meet its own 72-hour deadline.

Define awareness and the notice trigger
Agree in writing what counts as the processor becoming aware of a personal data breach, and which events start the notice clock for the controller. Name the people who can declare awareness, and state that the processor does not assess likelihood of risk before notifying, since that judgment belongs to the controller. The output is a short trigger definition, approved by the service owner and legal or privacy lead, that every engineer and on-call responder can apply without interpretation.
Set up detection and on-call escalation
Configure log sources and alerting so that suspected personal data exposure reaches a responder quickly, then map a named escalation path from the first alert to the person who can declare awareness. Tools such as Wazuh or OpenSearch Security Analytics can generate alerts from hosts, network devices and cloud services, but the team must confirm coverage of the systems that hold controller data. The check that closes this step is a documented on-call rota and a test alert that reaches the right person.
Build the first-notice template
Create a standard notice that the processor sends to each controller at the earliest stage, with fields for the time of awareness, the systems and data categories believed affected, the nature of the incident, the contact point, and the known and unknown facts. Keep the template short so it can go out before the investigation is complete. The output is an approved template stored with the incident response plan, with a named sender and a fallback channel if the usual email or portal is unavailable.
Establish phased follow-up
Plan the follow-up updates that the processor will send as facts are confirmed, such as scope, root cause, containment and remediation. Agree with each controller how often updates arrive and who receives them. Use the case record in an incident platform such as DFIR-IRIS to keep the timeline current so each update draws on the same facts. The output is a follow-up schedule per controller and a rule that the processor does not hold back early notice while details are still being established.
Align subprocessor and multi-controller flows
Where the processor uses subprocessors, require them to notify the processor without undue delay so that the controller clock is not lost in a supply chain. Where one incident affects several controllers, prepare a separate notice for each one. Confirm in each contract whether the processor may notify the supervisory authority on a controller's behalf, and remember that legal responsibility to notify stays with the controller. The check is a map of notice paths for every controller and subprocessor, reviewed against current contracts.
Test the route with a tabletop exercise
Run a tabletop or simulated incident that starts with a detection and follows the route through awareness, escalation, the first notice to each controller and one follow-up update. Record elapsed time at each step, the decisions taken and the gaps found. Testing with a realistic-looking but illustrative scenario shows where people hesitate or where contact details are out of date. The output is a written exercise report with assigned remediation owners and a retest date.
Record each notice in the incident register
Log every notice sent to a controller in the internal breach register, with the time of awareness, the recipients, the template version, each follow-up and any reply. Keep the record whether or not the controller later decides the breach is notifiable. Confirm with counsel how long these records are retained. The closing check is that a reviewer can trace each notice from awareness to controller response using the register alone.

Evidence that passes a processor notification test

A processor notification is only as credible as the paper and records behind it. The cards below cover the documents, logs and tests that show a processor told its controller in time and with usable content. Each one should be checked against the controller's own 72-hour timeline under Article 33.

Signed processor agreements with notice clauses

The processor contract is the first thing a regulator or controller reads. Article 28(3)(f) requires processors to assist with Articles 32 to 36, so the agreement should set a notice period measured from awareness, a minimum content list and a named contact. Check that the clause is in the signed version actually in force, not only in a template. Clause 9 of the Commission's standard contractual clauses (Decision (EU) 2021/915) is a useful benchmark for the wording.

Incident response runbook section for processor notice

The runbook turns the contract into steps staff can follow at 2 a.m. It should name who declares an incident, who decides whether the controller is told, which channel is used, and what happens if the controller cannot be reached. Confirm that the section is version-controlled, dated, approved by someone with authority, and linked from the on-call process.

Notice logs with awareness and contact timestamps

The processor's notice log records when it became aware, when it classified the event, and when each controller was contacted and by what means. These timestamps let the controller show that the processor acted without undue delay. Ask whether the log is write-protected, whether times are synchronized to a reliable source, and whether entries can be edited after the fact.

Follow-up phase records

EDPB Guidelines 9/2022 recommend that processors notify promptly and then supply further information in phases. Keep a record of each follow-up: what was known, what was added, and when. Dated updates show the controller had what it needed to meet its own deadline and make phased notification to the authority possible.

Subprocessor flow-down terms

When a processor relies on its own subprocessors, the notice obligation must flow down to them, or the controller's clock may start late. Check that each subprocessor agreement requires notice to the processor within a stated time, and that the processor's register of subprocessors matches the contracts actually signed. Gaps here often surface only during an incident.

Tabletop test records and detection evidence

Tabletop exercises show whether the notice clause works under time pressure. Record the scenario, the times each step took, the gaps found, and the fixes assigned. Detection evidence supports the awareness timestamp: DFIR-IRIS (LGPL-3.0-or-later) keeps a case record with an audit trail and consolidated timeline, while OpenSearch Security Analytics (Apache-2.0) and Wazuh (GPL-2.0-only) generate findings and alerts that show when detection occurred. Confirm each tool's fit with your own environment and licensing review.

What meeting Article 33(2) costs in money and effort

This table lists the cost components of meeting the processor notice duty, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No fee or duration is supplied for this requirement, so use the right-hand column to decide what to request in a quote. The main takeaway is that most of the cost sits in contract work and staff time, not in the open-source tooling itself.

Cost component	One-time or recurring	What drives it and how to keep it down
Contract review and renegotiation	One-time, then on change	Number of processor contracts and how far their notice terms differ. Use one standard notice clause with stated hours and content so each contract is not negotiated from scratch.
Detection and alerting tooling	Recurring (hosting and staff)	The named open-source tools carry no license fee to the organization, but hosting, storage and staff time still apply. Log volume and the number of monitored systems drive sizing. Confirm the license terms with each vendor before deployment.
Runbook and notification template writing	One-time, then periodic review	Number of services and controllers served. A single template for the processor notice (time, scope, data categories, contact point) reduces rework per incident.
Tabletop exercises	Recurring (annual or after change)	Staff hours for participants, facilitation and any external facilitator. Keep exercises short and tie them to the notice clock so gaps surface early.
Subprocessor contract updates	Recurring, on each new subprocessor	Frequency of subprocessor changes and the number of downstream notice chains. Keep a register that shows which contracts carry the notice duty.
Evidence upkeep	Recurring	Retention of notice logs, timestamps and contract versions. Automate timestamp capture where the tooling allows, and confirm retention periods with your own counsel.
External review	Periodic, when used	Scope and depth of an outside review of contracts or runbooks. Ask for a fixed scope and written deliverables. An independent auditor issues any report, not the implementation partner.

Who owns processor notice, who prepares the evidence and who tests it

As a processor, your organization owns the duty to tell each affected controller without undue delay after becoming aware of a breach. That duty sits with the people who run the contract, the detection stack and the customer relationship, not with an outside party. Owning it means the notice route works on a weekend, the people on it know the contract terms, and someone can decide that an incident has reached the threshold for notice without waiting for a full risk assessment.

Contract owner: Keeps the notice clause, the notice window and the named contact for each controller current, and tracks sub-processors that may also hold the data.
Security operations: Triages alerts, records the time of awareness and opens the case that starts the notice clock.
Legal: Confirms which controllers are affected and reviews wording, but does not hold up the first notice while facts are still emerging.
Customer success: Confirms contact details for each controller and runs the follow-up communication once phased updates begin.

Check that each named role has a deputy, that the awareness time is recorded consistently, and that the contract notice window matches what the team can actually meet.

Questions buyers and practitioners ask about processor notice

How much effort does processor breach notice work take?

The effort is mostly in writing and testing the notice process, not in the notice itself. A processor needs a detection path that reaches the people who can judge an incident, a named contact for each controller, a template for the first notice and a way to send follow-up information in phases. The size of the effort depends on how many controllers a processor serves, how many systems hold personal data, and whether logs already reach a central place. Ask any firm for the work broken into these components before accepting a figure, and confirm which ones are one-time and which recur each year when staff rehearse the process.

How long does it take to put processor notice arrangements in place?

The duration depends on the scope agreed in writing before work starts, and no fixed timeline applies to every processor. The main variables are how many customer contracts need updated notice terms, whether detection and log collection already cover the systems that hold personal data, and how quickly the internal approvers can sign off on templates. Ask for a schedule that lists the contract updates, the technical changes and the rehearsal dates as separate milestones so you can see where delays would come from.

What does the work need from our own team?

Your team owns the decisions, and an implementation partner can prepare systems and evidence without taking those decisions over. Expect to need a named incident lead, someone from legal or privacy who can agree notice wording, an engineering owner for logging and alert routing, and an account owner who keeps the controller contact list current. Each role should be written into the incident response plan so that notice can go out without waiting for a specific person to be available.

Can we do processor notice work in-house?

Yes, if your team has staff who understand the contract terms, logging and incident handling. Many processors handle the contractual work with legal counsel and build the technical path internally. A partner is useful when the team lacks capacity or when the work spans several self-hosted systems that need consistent logging. Whichever route you choose, the decisions about what to notify, when and to whom stay with your organization, and independent assessors will test what you actually did.

What drives the cost of processor notice up or down?

The main cost drivers are the number of controllers and contracts, the number of systems that hold personal data, how far logging and alerting already reach, and how many notice terms differ between customers. One-time costs include contract changes, detection set-up and writing the templates. Recurring costs include rehearsals, template reviews and keeping the controller contact list accurate. When requesting a quote, ask which items are fixed in the written scope and which would be charged as changes if controllers or systems are added later.

Must a processor assess the risk of a breach before notifying the controller?

No. Under EDPB Guidelines 9/2022, the processor does not need to assess the likelihood of risk before it notifies the controller. That assessment belongs to the controller, which is treated as aware once the processor has informed it. The processor should still notify without undue delay after becoming aware and send further information in phases as facts become clearer. Confirm the exact wording of your notice clause with counsel, because the contract is where the controller's required notice time is set.

Does a certificate prove that our processor notice meets the GDPR?

No. The GDPR does not require an audit, attestation or certificate, and Article 42 certification is voluntary. Even where a certificate exists, it does not reduce the responsibility of the controller or processor for compliance. What proves processor notice works is evidence: the signed contract clauses, the notice procedure, alert records, timestamps showing when the processor became aware and when it notified, and records of rehearsals. Ask any provider which of these artifacts they will hand over and how an assessor would test them.

How DeployOpen prepares processor notification for your platform

DeployOpen helps organizations that run self-hosted open-source platforms build the processor side of breach notification: the contract terms, alerting paths and notice procedures that let a controller meet its 72-hour deadline. We prepare systems and evidence; the controller keeps responsibility for its own notifications.

How we scope

Engagements are fixed-scope, with the written scope naming which platforms, tenants and customer relationships are covered.
The scope lists the incident sources that feed notice decisions, such as SIEM, EDR and cloud logs for each platform.
Ongoing support, upgrades and continuous testing can be added as a retainer after the initial scope is agreed.

How we build

We configure detection and alert routing so suspected personal data incidents reach the people who can trigger customer notice.
We set up case records that log the time of awareness, affected controllers and the information already shared with each.
We test the notice path with tabletop exercises so responders can send early notices with incomplete facts.

How we hand over

You receive written runbooks covering who notifies each controller, through which channel, and within which agreed timeframe.
Notice templates list the phased information to provide first and the follow-up updates to send as facts emerge.
Contract clause mapping shows where your processor terms set notice times and content, for review by your legal team.

How we support

Retainer support can cover runbook updates when platforms, sub-processors or customer contracts change.
We can repeat notice path tests after upgrades so the evidence stays current for customer and auditor reviews.
Final decisions on contract wording and regulatory positions rest with your legal counsel and the controllers involved.