Your most sensitive data is sitting in the logs, and nobody has a plan to delete it

The riskiest copy of your data isn't where you think

Here's a question I ask early in most projects: "Where, exactly, does this one person's data live?" The answer is almost always "the CRM" or "the database." It's almost always wrong.

A workflow doesn't just move data. It leaves a trail. And that trail tends to sit in places nobody put on the map.

A client of ours got a deletion request a few months back. A former applicant wanted everything gone. Easy, the team figured: delete the record in the recruiting tool, clean up the CRM, search the old inbox. Done.

Then we looked at the automations. The application had come in through a form, hit a webhook, run through a Make scenario that parsed the CV, posted to a Slack channel, and created a record in Notion. Every one of those steps kept a copy. Full name, address, date of birth, the entire CV in plain text, sitting in the scenario's execution logs. Retention: 90 days, because that was the default nobody had ever touched.

Logs don't feel like data, and that's the trap

When a workflow runs, the platform records what passed through each step. Make keeps the bundles for every operation. n8n stores the input and output of every node. Zapier has the task history. These records are complete. If an email address or an account number flows through your workflow, it's in the log afterward, as content, not as a reference.

And it rarely stops at the platform. The nastier copies usually show up next door. Your error tracker captures the full payload on every crash, including the data that caused it. The Slack channel where a workflow posts status updates quietly accumulates every record it has ever processed. Your logging service stores the same messages a second time. A retry queue holds failed records for days so they can be reprocessed later.

By the end, a single person's data doesn't exist once. It exists four or five times. The database is the copy everyone pictures. The other four, nobody does.

Why this is a real problem, not a theoretical one

Article 17 of the GDPR, the right to erasure, doesn't stop at the database. If you keep personal data in logs and someone asks to be deleted, you have to remove it from the logs too, unless a legal retention obligation says otherwise. A 90-day retention setting nobody chose on purpose isn't a legal basis. It's just a default you inherited.

There's a second issue: every service that stores your logs is processing personal data on your behalf. Make, n8n Cloud, Sentry, Datadog, Slack. Each one needs a data processing agreement, and you should know where the data physically lives. A US provider without a workable legal basis becomes a problem in the exact place you weren't watching: the log of some side process.

What we actually do about it

Good news first: this is fixable, and it doesn't take much if you catch it early. Four steps.

First, map what flows through. You can't fix what you can't see, so we go through every active scenario and flag whether names, contact details, financial data, or special categories like health or applicant data pass through. For most clients it's fewer workflows than they expect, but it's never zero.

Second, log only what you need. The common mistake is recording everything because it's convenient. But you rarely need the full record to debug. An order ID is enough to trace a case. The customer's name doesn't have to be in the Slack channel. We cut what lands in logs and notifications down to what operations genuinely needs: identifiers, not contents.

Third, mask what has to stay. Sometimes you do need the content, say, to see which field an import chokes on. Then you mask the sensitive parts. An email becomes `m***@company.com`, an account number shows only the last four digits. Make and n8n both let you do this with one extra step that runs the data through a small function before logging. Ten minutes to build, and it saves an awkward conversation with your DPO later.

Fourth, set retention on purpose. Every default retention value should be touched once and decided deliberately. How long does operations actually need these logs to find a bug? For most workflows that's seven to fourteen days, not ninety. Turn it down and a big chunk of the problem dissolves on its own, because the data isn't around long enough to become a liability.

"Can't we just turn the logs off?"

This is the reaction I hear most once the problem is on the table. It's the wrong move. Kill the logs entirely and you've traded a privacy problem for an operations problem. Without logs you can't see why an automation failed, and the moment a workflow stalls at 2am is exactly when you'll wish you still had the detail to fix it.

The goal isn't to fly blind. It's to see enough to operate without storing more than you need. A log that holds an order ID and an error message but no real name does both jobs. You can find the bug, and you have no personal data to explain when someone comes asking.

What stuck with me

The applicant case didn't blow up. We searched the logs, deleted the affected entries, dropped retention from 90 days to 14, and stripped names out of two Slack notifications. An hour of work, in hindsight.

What stayed with me is this: privacy in automation rarely lives where you look first. The database is visible, so it gets protected. The logs are invisible, so they get forgotten. That's precisely why they're the bigger risk. A copy of someone's data that nobody knows about is a copy nobody can delete.

If you're not sure what personal data is sitting in your logs, error trackers, and notification channels right now, our free Automations Check is a good place to start. We'll walk your active workflows with you and flag the spots where data ends up that nobody thought about.