Someone asks for all their data. Does your automation know where it is?

Here is a question that will tell you more about your business than any dashboard: if one customer emailed you today and asked for a copy of everything you hold about them, how long would it take you to find it all? Not the CRM record. Everything. The newsletter tool, the support desk, the spreadsheet someone built two years ago, the execution logs of every automation that ever touched their email address.

Most companies answer "a day or two." Most companies are wrong, and they only find out when the email actually arrives.

I want to talk about the data subject access request, the DSAR, because it is the moment automation quietly hands you a bill you did not know you were running up. Every workflow that moves data also copies it. And a request under Article 15 of the GDPR is a test of whether you know where all those copies went.

Automation does not move data, it multiplies it

This is the part people miss. When you picture a workflow, you picture data flowing from one place to another, like water through a pipe. That is not what happens. Data does not leave the first system when the automation runs. It gets duplicated into the second one. Run three automations and one contact now lives in three places, plus the logs of all three runs.

None of that is a mistake. Each copy had a reason. The newsletter tool needs the email to send campaigns. The warehouse needs the order history for reporting. The Slack notification needs the name so sales knows who just signed up. Individually, every one of these is defensible. Added up, they create a trail of a single person scattered across places nobody is tracking as a whole.

And the trail runs deeper than the obvious tools. Execution logs store the full payload of every run, often in plain text, including fields that were later deleted in the destination system. Error notifications carry the record that failed. A backup sheet an automation writes "just in case" has been sitting in a folder for eighteen months. All of it is personal data if a real person is identifiable in it. All of it belongs, in principle, in an access request.

The clock starts the moment the email lands

You have one month. It starts when the request arrives, not when you get around to caring about it. You can extend by two months for genuinely complex cases, but only if you tell the person about the extension, with reasons, inside that first month.

In practice this means the countdown is already running while you are still writing down which systems you own. If you start listing your tools only after the request comes in, half your month is gone before you pull the first record. That is why these requests so often end in a scramble. Not because the systems are hard to search, but because nobody knew how many there were.

So the honest version of the question is not "what is in the CRM." It is "where has our automation left traces of this person over the past two years, including the places we forgot about."

What a real data map looks like

Sit down and trace the path of one contact through your systems, from the first signup to today. Most teams underestimate the result by a factor of three. Here is a fairly typical outcome for a small company:

Seven rows, and I left out backups and the shared inbox. The point is not that seven systems is a lot. The point is that rows five through seven almost never show up in anyone's privacy documentation, even though they are the hardest to search.

Ask around your own company where customer data lives and you will hear the CRM, the invoicing tool, maybe the marketing platform. What you will almost never hear is "the logs." Yet the logs are often the richest source of all, because they keep the complete payload of every run long after the destination record was trimmed down.

Two companies, same blind spot

Take the small shop first. Four people, a solid store, eight Zapier zaps grown over two years. Classic "it always worked, nobody documented it." When the first access request came in, the owner handled it himself, because there was no IT team to hand it to. We spent an afternoon going through all eight zaps and writing down what personal data each one touched and where it wrote it. A single customer's data sat in six places, including the zap history Zapier keeps by default. Six places, in a company of four. The owner was genuinely surprised, not because he had been careless, but because every automation made sense on its own and nobody had ever looked at the sum.

Now the 200-person services firm. Different scale entirely. Own IT, a central warehouse, a team proud of its single source of truth. The expectation was that an access request would be trivial, because everything was central. Reality disagreed. The warehouse was central, but around it hung dozens of automations pulling data from third-party tools and pushing it back out. Marketing had its own tools that were never connected. Sales kept records in a separate CRM that only partly synced. And the sync logs lived in a system the data protection officer could not even access. The single source of truth was a story about the ideal state, not the actual one.

The lesson from both is the same. Size does not protect you and a central system does not protect you. The small shop had few places but no documentation. The large firm had documentation, but it described the wish, not the many side roads automation had built.

The one thing that actually helps

If I had to reduce all of this to a single recommendation, it would be: keep a data map. Not an 80-page document, not a certified register nobody touches again after it is written. A plain, living overview that answers one question. When a person asks for their data, where do we have to look?

Five facts per system are enough. Which system. What categories of personal data it holds. Where the data comes from, meaning which automation or manual step writes it. How long it stays. And who in the building is responsible for searching it when the time comes.

Keep it that simple on purpose. A map that is too detailed will not be maintained and will be wrong within six months. One that answers only the five questions that matter survives contact with real life. The goal is not legal completeness, it is being able to know, within an hour, where to look.

The trick to keeping it alive is to tie it to the moment something changes anyway. Every time a new automation goes live, a row gets added. Every time one is switched off, a row disappears. One client wired this straight into their approval process: an automation only goes live once its row exists in the map. Five minutes per automation, days saved when it counts.

Running the request without the panic

Once the map exists, a fire drill turns into a process. Log the arrival and note the date, because that is when the month starts. Verify identity carefully but without inventing hurdles, an ID scan is rarely proportionate when the person is writing from the email address you already have on file. Then take the map and walk it row by row. That is the entire reason the map exists, so this step is a checklist and not a feat of memory. Pull the data, check it for third-party data that must not be disclosed, and assemble a copy an actual human can read, not a raw database dump with cryptic field names. Deliver it securely, and document what you sent, so you can show later that the answer was complete and on time.

And here is the part that makes the effort pay off twice. An access request rarely comes alone. A deletion request under Article 17 often follows. The same scattered landscape that made the access hard makes deletion hard, and the logs and staging sheets are again the places that get forgotten. Build the map for access and you have built it for deletion too. That is the real reason it is worth the afternoon.

What I took away from it

I did not come out of these projects hostile to automation. I came out seeing it differently. Every workflow that carries data from A to B creates a new place a person shows up. That is not a reason to stop. It is a reason to write it down.

The most expensive mistake is not having too many systems. It is not knowing which ones you have. A small shop with six data locations and a list is in better shape than a large firm with a central warehouse and the comfortable belief that the warehouse settles the matter.

So treat the access request as what it really is: an honest self-test. If you cannot answer "where does this one person's data live" within a day, you do not have a privacy problem that will appear at the next request. You already have it. The request just makes it visible. The fix is unglamorous, which is exactly why it works. Spend one afternoon tracing a single person through your systems, turn it into a list, and tie its upkeep to the moment you build new automations anyway. Then the next request is not a ruined afternoon. It is just a task you handle, calmly and on time.