When Your Automation Vendor Is Breached: Who Notifies Who

An automation platform is not a tool beside your data. It is a place your data lives. Every Zap, scenario, workflow or flow you have run left a copy of what passed through it in someone else's account, behind someone else's access controls and on-call rotation. So the question is not whether your vendor has a security page, but what happens to you on the day the vendor is the one breached.

That clause is in a contract you have already signed, and reading it for the first time on the morning it matters is too late. This is the sequence: what four platforms commit to in writing, what you owe your customers and how fast, and what to do in the first hour.

The vendor's breach is your breach

Here is what buyers get backwards. You decided to collect the customer records, invoices, support tickets, employee files. The platform processes them only because you told it to. Notification duties under US state law and under the GDPR follow that decision, not the server the data sat on when it leaked. Your customers hear from you. They do not hear from Zapier.

Florida writes this out mechanically. Under Fla. Stat. s. 501.171, a vendor breach creates a duty running uphill to you: "In the event of a breach of security of a system maintained by a third-party agent, such third-party agent shall notify the covered entity of the breach of security as expeditiously as practicable, but no later than 10 days following the determination of the breach of security or reason to believe the breach occurred." The statute then hands the problem straight back: "Upon receiving notice from a third-party agent, a covered entity shall provide notices required under subsections (3) and (4)."

Delegate the notifying itself and the exposure stays put: "An agent may provide notice as required under subsections (3) and (4) on behalf of the covered entity; however, an agent's failure to provide proper notice shall be deemed a violation of this section against the covered entity."

What each platform commits to, in its own words

We read the current data processing documents for four platforms and pulled the window each commits to. The spread is wide, and one is a blank.

Zapier's Data Processing Addendum is the tightest of the four. Section 5 reads: "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, and (b) make reasonable efforts to identify the cause of the Security Incident, mitigate the effects, and remediate the cause to the extent within Zapier's reasonable control." It also adds a line worth reading before forwarding a vendor email to a regulator: "You acknowledge that Zapier providing notification of a Security Incident is not an acknowledgment of fault or liability."

Make commits to no timeframe at all, and that is the finding. The Celonis Data Processing Agreement for Make, clause 9.3: "In the event of a Personal Data Breach by Us, We shall notify You without undue delay after becoming aware of the breach." No hour count, no day count. "Without undue delay" is a real standard, but one argued about afterwards rather than a deadline you can build a calendar around.

n8n's sample Data Processing Agreement puts a number on it: clause 6.2 says "n8n will notify the Customer without undue delay and, where feasible, no later than 72 hours after becoming aware of" accidental, unauthorised or unlawful processing or a Personal Data Breach. Two neighboring clauses matter as much. Clause 6.5 says "n8n will not inform any third party of any Personal Data Breach without first obtaining the Customer's prior written consent, except when required to do so by law." Clause 6.6 gives the customer "the sole right to determine" whether to notify data subjects, supervisory authorities, regulators or law enforcement, and whether to offer any remedy. The vendor will not be telling your customers. You will.

Microsoft was the gap when this article was first published, on the grounds that its Products and Services Data Protection Addendum is distributed as a Word document. That was not good enough. The document opens, the edition read for this update is stamped "Last updated May 22, 2026", and it does commit to a figure. What it does not do is put the figure in the section named after breach notification. Under "Security Incident Notification", Microsoft undertakes to act "promptly and without undue delay" — notify the customer, investigate, take reasonable steps to mitigate — and no number appears anywhere in that clause. The number sits in Appendix A, Security Measures, under Information Security Incident Management, in a sentence that points back at the section which does not contain it: "For each security breach that is a Security Incident, notification by Microsoft ... will be made without undue delay and, in any event, within 72 hours."

Two things follow, and the second matters more. A buyer who reads the section with the right words in its heading comes away believing Microsoft promised no window at all, which is the opposite of the truth. And the 72-hour clause does not say what starts the 72 hours. The only trigger anywhere in the document is the notification section's "If Microsoft becomes aware", while the public breach-notification page for Azure, Dynamics 365 and Power Platform — the family that includes Power Automate — describes notices "in no more than 72 hours from the time it declared a breach". Awareness and declaration are not the same moment, and the distance between them is yours. Separately, the addendum is blunt about who owns the rest: "Customer is solely responsible for complying with its obligations under incident notification laws applicable to Customer and fulfilling any third-party notification obligations related to any Security Incident." Microsoft promises "reasonable efforts to assist" the customer in notifying the supervisory authority and the data subjects. That is help, not a handover.

Two things decide what these promises are worth, and neither is a digit. The first is what starts the clock: discovery, awareness, or a declaration — never the moment the intruder got in. That gap is exposure no contract shortens. The second is what counts as an incident at all. Zapier's addendum defines a Security Incident as "A confirmed breach of security of the Service or Zapier's systems used to process Personal Information" leading to loss of or unauthorized access to that information. Confirmed is doing work there; a suspected issue still under investigation is not yet the thing the 48 hours attaches to.

What you owe your customers, and how fast

US state breach-notification law is a patchwork and nobody should carry fifty versions of it. What is worth knowing in advance is that states come in two shapes, and which one applies depends on where the affected people live, not where your company sits.

States with a hard outer deadline. Florida is one: notice to affected individuals must come "no later than 30 days after the determination of a breach or reason to believe a breach occurred," and where 500 or more Floridians are affected, notice also goes to the state's Department of Legal Affairs on the same 30-day limit, with up to 15 more days for good cause in writing. New York has one now too. General Business Law s. 899-aa: "The disclosure shall be made in the most expedient time possible and without unreasonable delay, provided that such notification shall be made within thirty days after the breach has been discovered, except for the legitimate needs of law enforcement, as provided in subdivision four of this section."

States with a standard and no number. Virginia is the clean example. Va. Code s. 18.2-186.6(B) requires disclosure "to the Office of the Attorney General and any affected resident of the Commonwealth without unreasonable delay," and no number of days appears in the section. Nevada's NRS 603A.220 reads the same way, with no day count either. No deadline is not the same as no pressure: it means the reasonableness of your timeline gets judged afterwards, by someone asking how long you took and why.

If the GDPR applies to your organisation, a second regime runs in parallel, and it is the one that puts a number on your side of the line. Article 33(1) of the GDPR requires the controller — you — to notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach "is unlikely to result in a risk to the rights and freedoms of natural persons". Missing the window is not a bar to notifying: "Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay."

Article 33(2) is the clause that explains the table at the top of this article. The processor — the platform — "shall notify the controller without undue delay after becoming aware of a personal data breach", and that is the whole of Article 33(2). No hours. Every figure those four vendors publish is a contract filling a silence the Regulation left, which is why they differ, and why the Regulation itself gives a processor no number to miss. Telling the affected people is a third duty, with a higher trigger and no number attached: under Article 34(1), where the breach "is likely to result in a high risk to the rights and freedoms of natural persons", the controller communicates it to them "without undue delay" — subject to the exemptions in Article 34(3), which are worth reading before assuming either that you must or that you need not.

The part you cannot fix afterwards

This is where companies meet the real size of the problem. The interesting data on a platform is not the account list. It is the run history: every execution, with the payloads that moved through each step. Those payloads usually contain the record itself, not a pointer to it. The invoice total, the address, the ticket body, the new hire's date of birth — the platform held the values in order to pass them along.

So retention settings chosen casually two years ago define the blast radius now. Zapier's data retention page lists Zap Runs as kept "7 days in logs. 29-69 days in your Zapier account." Its help documentation adds that "Zap history retention can be customized to 7-30 days long" — a control its plan table marks for the Enterprise tier. Make's documentation says run history retention depends on your pricing plan rather than naming one period. Either way, the default was a decision somebody made, and it may not have been you.

If you never limited retention deliberately, assume the scope of an incident is every run you ever made. It is also the overlap with portability: the history that makes a breach expensive is the history you need to leave cleanly, covered in what each platform lets you take with you.

Hour one, in order

1. Revoke the connection, not the password. In each connected app — CRM, email, accounting — revoke the token or OAuth grant the platform holds, from the app's side rather than only the platform's, so it survives whatever is happening inside the vendor. Switching workflows off comes second: killing the grant is what stops data moving.

2. Rotate every credential the platform held. API keys, webhook secrets, service account passwords, signing keys, anything pasted into a step two years ago and forgotten. Assume whatever the platform could read has been read. Keep a written list as you go: it is your record of what you did and when.

3. Pull the run history while you still can. Export the execution logs and payloads before retention trims them, before an account gets locked, and before anyone's instinct to tidy up takes over. It is the only record of which data actually moved. Delete nothing.

4. Work out which records crossed the window. From the exported history, list the individuals whose data passed through during the exposure period the vendor gives you — and until they give you one, the whole retention window. Group them by state and country: that is how the duties divide.

5. Start the notification clock with counsel, not before. With the vendor's notice, the exported history and the state-by-state list in hand, a lawyer can say which statutes apply, which thresholds are crossed, whether regulators or credit bureaus also need notice, and what the letters must say. Order matters: notices sent before you know the scope get corrected in public.

Before it happens, which is where the money is

Shorten retention on purpose. Decide the shortest history window your team can actually work with, set it, and write down who decided. Every day you cut is a day of payloads that cannot be taken from the vendor or demanded from you later.

Inventory which platform touches which data. One page per platform: systems connected, categories of personal data passing through, who owns the account, where the DPA lives. On a bad morning it is the difference between an afternoon of reconstruction and a phone call, and the same inventory that makes the SOC 2 question answerable and the one liability rests on when a workflow does something wrong.

Read the notification clause before signing. It takes four minutes. Search the DPA for "breach" and read what follows: is there a number of hours, what starts the clock, does the vendor need your consent before talking to anyone else, and who decides whether your customers are told. A clause with no timeframe is not a dealbreaker by itself — it is a question for procurement while you still have leverage.

Nothing here says any vendor meets a legal standard; compliance belongs to your organization, not to a tool in your stack. A DPA tells you how much warning you have bought. The law tells you how much warning you owe. The second number has your name on it. See also customer data and US law.