Your worst data breach won't come from a hacker. It'll come from your own workflow.

300 invoices, 300 wrong recipients

A bookkeeper called us one Tuesday morning, voice tight. The monthly invoice run had gone out overnight, automatically, like it had for a year and a half. Except this time someone had shifted a column in the source spreadsheet. The workflow happily paired the address from row one with the invoice from row two, kept going, and sent roughly 300 invoices to the wrong people. Customer A got Customer B's numbers: revenue, balance, everything.

No attacker. No leak. No security hole in the usual sense. A misplaced field in a Google Sheet, executed by a workflow doing exactly what it was told.

That's a personal data breach under GDPR. And from the moment the bookkeeper noticed, a 72-hour clock was running.

The worst breaches are homemade

When people picture a data incident, they picture hackers, ransomware, some big vendor getting popped. The incidents we actually run into look nothing like that. A wrong distribution list on a mail merge. A test automation that quietly pointed at production data. A CRM field linked to the wrong contact, putting the wrong name into every confirmation email.

Automation amplifies exactly this kind of mistake. A human stuffing envelopes notices by the third one that something's off. A workflow notices nothing. It doesn't make the mistake three times, it makes it three hundred times, in under a minute, then sends a success notification.

The tricky part is that these don't feel like data protection incidents. It's "just" a sending error. Which is precisely why they get buried, downplayed internally, or only reported once a recipient complains. By then the 72 hours are usually long gone.

When an automation mishap has to be reported

Here's the concrete answer, because people get this wrong constantly. Under Article 33 of the GDPR, a personal data breach has to be reported to the supervisory authority within 72 hours of becoming aware of it, unless it's unlikely to result in a risk to the people affected. If the risk is high, say financial or health data, Article 34 says you also have to tell the affected individuals directly.

Sending 300 invoices with revenue figures to the wrong recipients isn't a borderline case. It's reportable, and the people involved need to be told. The question is never whether you have to report. It's whether, within 72 hours, you can even say what happened.

That's where the real trouble starts.

Why automations make reporting hard

An Article 33 report needs specifics: which categories of data, roughly how many people, what consequences, what you did about it. In a manual process, someone can reconstruct what they did. With an automation, you have to ask the logs, and the logs are often not where you need them.

With the invoice case, we got lucky. The workflow ran on Make, and the execution history showed, run by run, which recipient address had been paired with which invoice. We built an exact list in two hours: who got what, 300 rows, clean. That list was the basis for the report and for notifying the people affected.

Here's the catch. That list only existed because the execution history was switched on and kept long enough. At another client, we couldn't have reconstructed the same incident, because their logs were wiped after 24 hours and the error only surfaced after the weekend. Without logs, all you can put in a report is the honest, weak version: "Affected are presumably everyone in the run, exact attribution isn't possible." That's not a sentence you want to send a regulator.

What has to exist beforehand

You don't prevent a breach with good intentions. You survive one with three things that have to exist before it happens.

A kill switch on every workflow that talks to the outside world. If the bad run starts at 3am, you want to stop it at 3:05, without opening a support ticket with the vendor. A switch that disables the workflow is basic equipment for anything that sends.

An execution history that lives long enough to reconstruct a Friday incident on Monday. A few days is fine for debugging, but for breach evidence you want closer to two to four weeks. This is the one place where keeping logs longer helps data protection instead of hurting it, as long as the logs themselves are secured.

A clear owner who starts the clock. The 72 hours run from awareness, not from the moment the team reaches consensus. It has to be settled in advance who calls the data protection officer and who decides whether to report. Sorting that out before an incident takes ten minutes. Not having sorted it out costs you half a day of panic.

Small shops get hit the same way

A quick aside, because plenty of people feel safe here: this isn't only about big senders. A physiotherapy practice with six staff had a simple automation sending appointment reminders by text. After an update at the SMS provider, the phone numbers slid over by one position, and "Your physio appointment is Thursday" went to the wrong person each time. Health context, small numbers, still reportable and still sensitive.

Company size doesn't change the deadline. It only changes whether someone's around who knows what to do next.

Reporting is uncomfortable. Hiding it is more expensive.

The temptation to sweep a small breach under the rug is strong. Maybe nobody complains. Maybe it goes unnoticed. From experience: it gets noticed, often weeks later, when a recipient mails the wrong invoice back to the wrong sender and suddenly two customers know about each other.

Regulators treat a late or missing report far more harshly than the original mistake. An on-time, honest report with a clean list of who was affected and a line saying "we stopped the workflow and took these steps" is a manageable event. The same breach, surfacing three months later through a complaint with no reconstructable data, is the kind of thing that gets expensive.

So we push clients toward the uncomfortable option: when in doubt, report, document properly, tell the people affected. Not because it's pleasant, but because the alternative ages badly.

What we took away from it

Most data protection debates about automation circle the same question: are we allowed to put this data into that tool? The more useful question is what happens when the tool does exactly what you configured, and the configuration was wrong.

Automation removes the human who would have flinched. That removes the last check before something goes out the door. Build workflows that send, and you've built a machine that executes mistakes faster and more completely than any person could. That's the whole point of it, and it's also the risk.

The best time to figure out how you'd stop and reconstruct a breach is the day you build the workflow. The worst is the Tuesday morning the bookkeeper calls and the clock is already running.