When a vendor processing personal data on your behalf suffers a breach, the notification duties fall largely on you. Your processor's obligation under the General Data Protection Regulation (GDPR) is to tell you without undue delay. Yours is to decide, within 72 hours of becoming aware, whether the supervisory authority must be notified, and separately whether the affected individuals must be told.
That asymmetry is the practical problem. You carry a deadline measured in hours, while the party who finds out first carries a deadline measured in a phrase. This article covers what Articles 33 and 34 actually require, what "aware" means, and the one contract clause that determines how much of your 72 hours you get to keep.
The short answer
- Your processor must notify you without undue delay after becoming aware of a personal data breach. Article 33(2) sets no fixed number of hours.
- You must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people's rights and freedoms.
- You must notify the affected individuals only where the breach is likely to result in a high risk to their rights and freedoms.
- You must document every breach internally, including the ones you decide not to report.
- The 72 hours are yours, not your processor's. If the contract lets a vendor take four days to tell you, you have not lost the deadline, but you will be explaining the detection gap rather than the breach.
What counts as a personal data breach
Article 4(12) defines it as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.
Three things follow that catch teams out.
It is not limited to data theft. The definition covers three failure types: loss of confidentiality (unauthorised disclosure or access), loss of integrity (unauthorised alteration), and loss of availability (accidental or unlawful destruction or loss). A ransomware incident that encrypts your vendor's systems is an availability breach even if nothing was exfiltrated, and a backup that turns out to be unrecoverable is a breach with no attacker involved at all.
Internal access counts. An employee of your processor viewing records they had no business reason to see is unauthorised access.
A security incident is not automatically a breach. An incident becomes a breach when personal data is compromised. A blocked intrusion attempt is an incident to log, not a breach to notify.
Who notifies whom, and how fast
Your processor notifies you
Article 33(2) says the processor shall notify the controller without undue delay after becoming aware of a personal data breach. There is no 72-hour figure here, and no other number either. The EDPB Guidelines 9/2022 on personal data breach notification address this directly and recommend the processor notify promptly, with further detail supplied in phases as the investigation develops.
The guidelines also treat you as having become aware once your processor has informed you. This is the mechanism that makes the processor's clause decisive: the length of your own window depends on when that notification arrives.
You notify the supervisory authority
Article 33(1) requires notification without undue delay and, where feasible, not later than 72 hours after having become aware, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where you exceed 72 hours, the notification must be accompanied by reasons for the delay.
Note the threshold direction. Notification is the default, and the exemption applies only where risk is unlikely. This is a low bar to clear in favour of notifying, which is why the honest answer for most vendor breaches involving identifiable customer data is that the authority gets told.
Article 33(3) sets the content: the nature of the breach including, where possible, the categories and approximate number of data subjects and of records concerned; the contact details of your data protection officer or other contact point; the likely consequences; and the measures taken or proposed, including any mitigation. Article 33(4) permits phased provision where you cannot supply everything at once, which is the provision to rely on rather than missing the deadline while waiting for certainty.
You may have to notify the individuals
Article 34(1) requires communication to the affected data subjects, without undue delay, where the breach is likely to result in a high risk to their rights and freedoms. That is a higher threshold than the authority notification, and confusing the two in either direction is a common error.
Article 34(3) sets out three exceptions. Communication is not required where you had applied appropriate technical and organisational protection measures that render the data unintelligible to anyone unauthorised, typically strong encryption with the keys unaffected; where you have taken subsequent measures making the high risk no longer likely to materialise; or where it would involve disproportionate effort, in which case a public communication or equally effective alternative is required instead.
What "aware" means
Awareness is not the moment an alert fires. The EDPB position is that a controller becomes aware when it has a reasonable degree of certainty that a security incident has occurred which has led to personal data being compromised. A short investigation period to establish whether a breach happened at all is legitimate and expected, and that period is not counted as delay.
What is not legitimate is using investigation as a holding pattern. Once you have reasonable certainty, the clock has started even if the scope is still unclear, and Article 33(4) exists precisely so that uncertainty about scope does not become a reason to miss the deadline.
The clause that decides whether 72 hours is enough
Because "without undue delay" is undefined for processors, the number has to come from your Data Processing Agreement. This is the highest-value clause in a DPA for incident response, and it is routinely left as the Regulation's own wording.
What to require:
- A fixed maximum notification window, expressed in hours rather than as a standard. Twenty-four hours from the processor's awareness is common and achievable for a serious vendor.
- Notification content matching Article 33(3), so what arrives is usable rather than a one-line alert that starts a second round of questions.
- A named channel and escalation path, not a generic support queue. A breach notice that lands in a ticketing system behind a business-hours SLA has been sent and not received.
- An assistance obligation. Article 28(3)(f) already obliges the processor to assist you with your Articles 32 to 36 duties, but spelling out what assistance means — logs, scope determination, affected-record counts — turns it into something you can invoke under pressure.
- Onward notification through the chain, so a breach at a subprocessor reaches you rather than stopping at your direct vendor. Under Article 28(4) your processor remains fully liable for its subprocessors, which is the leverage for asking.
- No unilateral communication to your data subjects. Deciding whether Article 34 applies is your call as controller, and a vendor emailing your customers first removes that decision from you.
What belongs in the Article 28 contract more broadly is covered in what data processing agreements must cover.
What you must document even when you do not notify
Article 33(5) requires the controller to document any personal data breach, including its facts, effects, and the remedial action taken, and to make that documentation available to the supervisory authority.
This applies to every breach, including the ones you assessed as unlikely to result in a risk and therefore did not report. In practice the internal register is what an authority asks for when it wants to test your judgement, and a register with no low-risk entries reads as though the assessment was never carried out. Record the reasoning for the negative decisions, not just the positive ones.
Common mistakes
- Reading the 72 hours as the processor's deadline. Article 33(2) gives the processor "without undue delay" and no hour count; the 72 hours are the controller's.
- Copying the Regulation's wording into the DPA. "Without undue delay" in a contract adds nothing to what the law already says, and leaves you without a number to enforce.
- Confusing the two thresholds. The authority is notified unless risk is unlikely. Individuals are notified where high risk is likely. They are not the same test.
- Waiting for a complete picture. Article 33(4) exists so that partial information can be filed on time.
- Treating an availability incident as not a breach. Destruction and loss are in the Article 4(12) definition alongside disclosure.
- Keeping no register of unreported breaches. Article 33(5) covers all breaches, and the unreported ones are the evidence that you assessed rather than ignored them.
- Discovering at 2am which activities a vendor touches. Scoping is the slowest step of a vendor breach, and it is entirely doable in advance.
Frequently asked questions
Does the 72-hour clock start when our vendor discovers the breach or when we are told?
Your obligation runs from when you become aware, and the EDPB treats you as aware once your processor has informed you. That does not make a slow vendor harmless: a long gap between their discovery and your notification is a gap you may have to account for, and it consumes response time you would otherwise have used.
Do we have to notify if the breached data was encrypted?
For the individuals, possibly not. Article 34(3)(a) exempts communication where protection measures render the data unintelligible to unauthorised parties, which strong encryption with unaffected keys can achieve. The authority notification is a separate assessment under Article 33(1), and encryption is a factor in judging risk rather than an automatic exemption.
Which supervisory authority do we notify?
The competent authority for your processing, which for cross-border processing is generally your lead authority under the one-stop-shop mechanism in Article 56. Establishing that in advance matters, because identifying the right authority is not a task for hour 70.
Our processor had the breach. Are they the ones who notify the authority?
Not for your data. The processor's duty under Article 33(2) runs to you; the Article 33 notification to the authority and the Article 34 communication to individuals are controller duties. Where the vendor is a controller for some of its own processing, it will have its own separate obligations for that.
Does a subprocessor breach reach us automatically?
Only if the chain is contractually wired for it. Article 28(4) requires your processor to impose equivalent obligations on its subprocessors and keeps your processor fully liable, but the notification path still has to exist in the contracts. This is worth checking against the actual subprocessor list rather than assuming.
Where DPAFlow fits in
DPAFlow is not an incident response tool and does not provide legal advice. Two things it does hold are the ones that make a vendor breach slower to handle when they are missing.
The first is scope. When a vendor notifies you, the immediate questions are which processing activities involve them, what categories of data they hold, whose data it is, and whether the data leaves the European Economic Area. Those are Article 30 fields, and when your RoPA records link recipients to the vendors your workspace monitors, the answer is a lookup rather than an investigation.
The second is the paper trail. DPAFlow monitors vendor subprocessor and legal pages, including DPA pages, on a recurring schedule and keeps dated evidence of what each source said and what changed between captures. That means two things during an incident: you can establish which subprocessors the vendor listed at the relevant time, and a change to a vendor's published breach-notification terms surfaces as a detected change rather than being found the next time someone reads the DPA. How that evidence is captured is covered on the evidence page.