Your supplier had the breach. The notification is yours to write
The email arrives on a Tuesday and it is four sentences long. Your booking tool, or your payroll provider, or the marketing platform you stopped logging into last year, has had a security incident. They are investigating. They will update you.
Nothing in that email tells you whether your customers are in it. That is the only fact you need, and it is the one you will wait longest for.
There are two clocks here. One of them is written into European law and measured in hours. The other belongs to whoever sent that email, and in most contracts it is not measured at all.
I am not a lawyer and none of this is advice about your obligations, which depend on where you are, where your customers are, and what role you play in handling their data. What follows is what the legislative text says, what twelve vendor contracts say, and what happened in four cases that are on the public record. Your automation connects you to companies whose deadlines you have never read, and that is a design question before it is a legal one.
What the law actually says, with the parts summaries drop
Article 33(1) of the General Data Protection Regulation, quoted whole because every qualifier in it does work:
"In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay."
Regulation (EU) 2016/679, Article 33(1)
Three things in there rarely survive being summarised.
"Where feasible." It sits between the open-ended duty and the number. The primary obligation is "without undue delay"; the 72 hours is the outer bound of a feasibility test.
An exemption, not a deferral. The duty falls away entirely where the breach "is unlikely to result in a risk to the rights and freedoms of natural persons".
The statute prices in lateness. The sentence after the deadline attaches a condition to a late notification, reasons for the delay, and the supervisory authority judges whether those reasons were good enough. The text stops short of making lateness automatic non-compliance, and it stops short of excusing it.
So the popular version, seventy-two hours or else, is blunter than the text. Which makes it stranger that the part everyone repeats is the part that is softened, and the part nobody repeats is the part with no give in it at all.
The clock starts when you find out, and somebody else decides when that is
The trigger is awareness. The European Data Protection Board, the body that issues the regulators' collective reading, puts a definition on it:
"The EDPB considers that a controller should be regarded as having become 'aware' when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised."
Guidelines 9/2022 on personal data breach notification under GDPR, Version 2.0, adopted 28 March 2023, paragraph 31
And when the incident happened inside somebody else's system, the same document says who supplies that certainty:
"The controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as 'aware' once the processor has informed it of the breach."
Guidelines 9/2022, paragraph 44
Your deadline, then, begins on a date your supplier chooses. Which raises the obvious question of what the supplier owes you, and here the Regulation is suddenly brief. Article 33(2), in its entirety:
"The processor shall notify the controller without undue delay after becoming aware of a personal data breach."
Regulation (EU) 2016/679, Article 33(2)
That is the whole provision. No hours, no days. The EDPB says so out loud, and this is the sentence everything else here rests on:
"The GDPR does not provide an explicit time limit within which the processor must alert the controller, except that it must do so 'without undue delay'."
Guidelines 9/2022, paragraph 45
One leg of the chain carries a number. The next leg carries a phrase. Your exposure lives on the leg without the number, and the regulators' own advice for closing it is not to lean on the statute:
"the contract between the controller and processor should specify how the requirements expressed in Article 33(2) should be met"
Guidelines 9/2022, paragraph 46
So the deadline that actually governs your business is in a document you accepted with a checkbox.
So what did you accept? Twelve contracts, read
I read the data processing agreements of thirteen vendors on 8 September 2026, choosing the ones a small business is most likely to have wired into something. Twelve were readable. Six of those twelve name a number. Six name nothing you could hold a stopwatch to.
| Vendor | What the contract commits to | When the clock starts | Document date |
|---|---|---|---|
| Zapier | 48 hours, unconditional | Zapier discovers | 27 August 2026 |
| Stripe | 48 hours, for GDPR and UK GDPR data only | becoming aware | 18 November 2025 |
| HubSpot | 72 hours | becoming aware | 14 April 2026 |
| Microsoft | 72 hours, stated in a security annex | becoming aware | 22 May 2026 |
| Atlassian | 72 hours, "where feasible" | becoming aware | 17 August 2026 |
| Airtable | 72 hours | substantiation | 8 September 2026 |
| Mailchimp | without undue delay, no number | becoming aware | 26 September 2024 |
| Slack, via Salesforce | without undue delay, no number | becoming aware | revision of August 2026 |
| Twilio | without undue delay, no number | discovery of a confirmed incident | 9 April 2026 |
| Google Cloud and Workspace | promptly and without undue delay | becoming aware | no date printed |
| AWS | without undue delay | becoming aware | no date printed |
| Shopify | notice "upon Shopify confirming" | confirmation | 7 July 2026 |
| Notion | contract text could not be read | trust centre says 72 hours | undated |
That table is a claim about thirteen documents belonging to thirteen companies, read on one day. Vendors not on it were not checked, and any of these can be rewritten tomorrow.
Zapier is the strictest; this is what a tight clause looks like:
"If Zapier becomes aware of a Security Incident, Zapier will (a) notify you without undue delay, and not later than 48 hours after Zapier discovers the Security Incident..."
Zapier Data Processing Addendum, section 5, effective 27 August 2026
Stripe's number is real but narrower than it first reads, because it is scoped by whose law covers the data:
"...notify User without undue delay, which for Data Incidents affecting Personal Data subject to the GDPR or UK GDPR will be no later than 48 hours, in each case after becoming aware of the Data Incident."
Stripe Data Processing Agreement, section 3.1(f), last updated 18 November 2025
The trigger word decides more than the number
The middle column of that table matters more than the first. A deadline is a duration attached to a starting gun, and the starting guns differ.
Airtable's seventy-two hours run from a different event than everybody else's:
"Airtable will inform Customer of a substantiated Personal Data Breach without undue delay or within the time period required under Applicable Law, and in any event no later than seventy-two (72) hours following such substantiation."
Airtable Data Processing Addendum, section 6.2, last updated 8 September 2026
Substantiating something has no fixed length. Twilio's contract does the same work through a definition rather than a clause: its notification duty attaches to a Security Incident, and a Security Incident is defined as "a confirmed accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data". The operative word is the first one. Shopify's operative clause has no timescale at all and points back at the law instead:
"As required by Applicable Data Protection Laws, Shopify will provide notice to You upon Shopify confirming any Personal Data Breach."
Shopify Data Processing Addendum, section IV.B.2, last updated 7 July 2026
Two more details from the same pile, both of which change what the table means. Microsoft's seventy-two hours are not in the clause headed "Security Incident Notification"; they appear further down the document, in the incident-management annex. And Salesforce, whose addendum governs Slack, carries an exclusion no other vendor here has:
"The obligations herein shall not apply to incidents that are caused by Customer or Customer's Users."
Salesforce Data Processing Addendum, section 7, revision of August 2026
AWS excludes what it calls unsuccessful security incidents, a category that covers port scans and failed logins. Atlassian has copied the Regulation's own hedge, "where feasible", into its promise to you.
These are ordinary commercial drafting, every one of them published openly. The difficulty is arithmetic: the clauses of a dozen integrations do not add up to an answer about your own seventy-two hours.
Which of your suppliers holds customer data, and what does each one's contract say about telling you? Answering that for one business is a morning's work, and it is the kind of question a process audit exists to answer in writing rather than during an incident.
The common failure is a wrong number, told promptly
A vendor that says nothing is the failure everyone plans for. The public record shows something more common and harder to plan around: a vendor that tells you promptly, and tells you a number that is wrong.
Capita, on the pensions data. The UK Information Commissioner's Office issued a monetary penalty notice against Capita on 15 October 2025, £14m in total, over an intrusion that began on 22 March 2023 and ended in exfiltration of roughly 975GB. Capita processes personal data on behalf of more than six hundred pension-scheme organisations. It notified the regulator about fourteen hours after ransomware was deployed, and its own account is that it "kept its data controller clients informed".
In January 2024 it told the ICO that 2,940,554 people were affected in its processor capacity. On 6 September 2024 it corrected that to 6,024,221, because the earlier figure "had been reached without an analysis of the pensions-related services managed by Capita". Roughly 3.1 million people were missing from the count for at least eight months, and the schemes had no source for the number other than Capita.
The Oncology Institute, on the vendor that had no evidence. On 6 November 2025 the company filed a voluntary disclosure with the US Securities and Exchange Commission about an incident at a software provider, recording that:
"To date, the software provider has not indicated to the Company that there is any evidence that any patient personal information was compromised as a result of this incident, and an investigation remains ongoing."
Form 8-K filed 6 November 2025
On 22 May 2026 the same company filed again, this time as a material event:
"Kroll, who is the third-party administrator for the Vendor, notified the Company that the Vendor had detected unauthorized access by a third party to certain information systems of the Company, including systems affecting data of patients."
Form 8-K filed 22 May 2026
Six and a half months between "our supplier had an incident" and "your patients were in it". The supplier is never named in either filing.
BayFirst, the shortest version. A bank's filing of 30 October 2025 puts the whole shape into two sentences: notified on 14 August 2025 of an incident at a marketing services provider, and told on 28 October 2025 that customer information including social security numbers had been exposed. Seventy-five days, one vendor, unnamed again.
Advanced Computer Software, the case that cuts the other way. It found evidence of compromise in the early hours of 4 August 2022 and, per the ICO's penalty notice, "notified all potentially impacted data controller customer entities on 5 August 2022". Its own remediation list records notifying all customers within 24 hours of discovery whether or not they were affected. One day is achievable, and the regulator wrote it down.
The regulator also stated the structural fact that makes all of this your problem rather than somebody else's:
"The UK GDPR does not impose any obligations on data processors to notify the Commissioner of a personal data breach."
ICO monetary penalty notice, Advanced Computer Software Group, dated 26 March 2025, paragraph 32
There is no direct line between your supplier and the authority. Everything routes through you. In that same notice, the ICO records that it learned of the incident by contacting Advanced "following widespread media reports".
The part your automation is bad at
The legal problem starts at the point where a business cannot answer three ordinary questions quickly.
Which integrations hold customer data at all. Every connector you have ever authorised is a place personal data lives or passes through, including the ones built for a campaign in 2024 and never switched off. This is the same list that answers half a dozen other questions, and keeping a register of what is automated is the cheap version of it.
Which address the vendor will write to. Twilio's clause is unusually candid about this: it will notify "via email to the email address(es) designated by Customer in Customer's account". On the day it matters, the notice goes to whichever address was typed into a settings field during setup, which in a lot of small businesses is a developer who left, an agency, or a shared inbox nobody reads. That is the same fault line as whose accounts your automation runs on, and it fails the same way: quietly, and only when tested.
What the vendor told you last time. A notification you cannot find is a notification you cannot act on, and vendor mail is exactly the kind of record that lives in an inbox rather than a system. The habit of assuming your tools keep a durable copy of things is worth examining generally, which is the subject of how long your automation keeps its history.
That is ordinary hygiene, knowing what you run, and it happens to be the difference between a bad week and an unanswerable question. The failure it protects against is the same one behind automations that fail without telling anybody: the information existed, and it did not reach a human who could use it.
One number that may not stay 72
On 19 November 2025 the European Commission published the Digital Omnibus proposal, COM/2025/837 final, which would replace Article 33(1). The proposed text would make the deadline 96 hours and narrow the trigger to a breach "likely to result in a high risk to the rights and freedoms of natural persons".
It is a proposal. As of 8 September 2026 the GDPR itself has never been amended, and its EUR-Lex page still records the consolidated version of 4 May 2016. Seventy-two hours is the law. But one detail in that proposal says something about which problems get legislative attention: the amendment touches paragraph 1, adds a paragraph 1a, and adds paragraphs 6 and 7. Article 33(2), the sentence that gives your supplier no deadline, is untouched.
Whatever the number becomes, the leg of the chain you cannot control stays as vague as it is today. The answer was never going to come from the statute.
Where this leaves you
The obligation that has a clock on it is yours. The event that starts the clock happens somewhere you cannot see, is discovered by somebody whose contract with you may promise nothing, and reaches you as an email to an address you chose during setup. Between those facts sits every integration you have ever authorised.
Knowing which suppliers touch customer data, which notification address each one holds for you, and what each contract actually commits to is a list, and it is worth having before anyone needs it.
If you would rather have that written down than assemble it during an incident, mapping what your systems connect to and where customer data lands is part of the process audit. $299, three business days, and a written map you keep whether or not you hire us.
Nothing in this article is legal advice, and whether any of it applies to you depends on your jurisdiction and your role in handling the data.
Related: what happens to customer data you paste into an AI tool is the same question asked about a different door.