Your automation tool is quietly hoarding personal data

Delete a record from your CRM. Now go check your automation tool.

Here is a test I run with new clients. Pick someone you removed months ago, a churned customer, a rejected applicant, anyone who asked to be forgotten. Then open your automation platform and scroll through the execution history. Nine times out of ten, they are still there. Full name, email, attachments, the whole payload, sitting in a run log nobody has opened since the day it fired.

Most teams treat Make, n8n or Zapier as plumbing. Data comes in one side and leaves the other. But plumbing that keeps a copy of everything that passes through it is not plumbing. It is a filing cabinet, and nobody has been told to empty it.

Every run is a copy you forgot about

This is not a bug, it is the default. Automation platforms log the full input and output of each run so you can debug when something breaks. That part is genuinely useful. When an order fails at 3am, you want to open the run the next morning and see exactly what came in and where it choked.

The catch is that those logs hold the real data, not a summary. You set a retention period on your CRM, your ATS, your accounting tool. Nobody set one on the automation layer. It slips through because no one pictures it as a place where data lives. It is the bridge between two systems, and everyone forgets the bridge is taking notes.

"How long does it actually keep my data?"

Since this comes up in every project: longer than you would like, and it depends on the platform and plan.

Make keeps execution logs somewhere between 30 and 90 days depending on your tier, and you can set it per scenario. Zapier holds task history for months. n8n, which plenty of people self-host, keeps whatever you tell it to, and that is the real trap. Leave it on default and the database just grows, until one day someone finds two years of personal data in a table that should have been cleared long ago.

So the honest answer is: long enough to be a problem, unless you go in and change it.

You are pre-building a breach

It is tempting to file this under paperwork. It is not. Two reasons.

First, subject access requests. When someone asks what data you hold on them, you have to answer completely. Miss the automation platform and your answer is wrong, and a wrong answer to a regulator is a very different conversation than a slow one.

Second, the target. An automation account holding eight months of applications, invoices or health records is worth stealing, and access often runs through one API key or a shared login with no second factor. Break that and the attacker does not just get today's traffic. They get the archive. You have quietly assembled a breach and put a single lock on it.

Three things I check before anything goes live

None of these take long.

Set retention on purpose. For every workflow that touches personal data, pick a window that matches the source system. If the application gets deleted after six months, the run history should not outlive it. On Make and Zapier that is a setting. On n8n it is a startup parameter plus a cleanup job.

Pass less. Does the workflow really need the full CV as an attachment, or would a reference ID and a name do? What never flows through the automation cannot be stored by it. Data minimization is not a slogan here. It removes half the problem before it starts.

Mask the sensitive fields. Good platforms let you redact specific values in the logs: passwords, payment details, health information. Ten minutes of setup turns a worst-case leak into a shrug.

The line worth writing down

If you take one thing from this: your automation tool is a place where personal data lives. Not a wire, not a pipe. A store. Treat it like every other system under GDPR, with a retention window, an owner, and an entry in your records of processing.

The HR team from the top of this? They set a 30-day window and cleared the backlog. Ten minutes of work. The hard part was noticing the problem was there at all.