How to handle GDPR when an automation moves client data.
Most agency automation work is data protection work, and it usually gets treated as though it is not. Controllers, processors and where the data actually goes.
An automation that moves leads from a form into a CRM is moving personal data. So is one that reads invoices, routes support messages or sends a follow-up. Most agency automation work is data protection work, and it usually gets treated as though it is not.
This is practical guidance on the parts that affect how you build and contract, not legal advice. Anything with real exposure deserves a lawyer who knows the client’s jurisdiction.
Work out who is the controller and who is the processor.
This determines almost everything else, and it is usually simpler than it sounds.
The controller decides why the data is processed and what happens to it. For agency work this is nearly always the client, because it is their leads, their customers and their business purpose.
The processor acts on the controller’s instructions. That is your agency when you build and operate a workflow that handles their data.
A sub-processor is anyone you bring in who also touches it. That includes an implementation partner, but it also includes every vendor in the chain: the automation platform, the hosting provider, the enrichment service, the model API.
Two consequences follow. You need a data processing agreement with the client that names what you do with the data. And you need the client’s permission to use sub-processors, which usually means listing them.
List every place the data actually goes.
Most agencies underestimate this list because they think about the two systems at the ends and forget the middle.
Walk one record through the workflow and write down every service that sees it. A typical lead pipeline touches the form provider, the automation platform, an enrichment provider, a model API if there is a classification step, a notification channel, the CRM, and the error alerting that receives the payload when something fails.
That last one catches people out. Error notifications frequently include the full record, which means personal data is now sitting in a chat channel with a different retention policy and a wider audience than the CRM it was headed for.
Move less data.
The most effective control is also the cheapest: do not move fields you do not need.
If routing only requires the email domain, send the domain rather than the full record. If a model only needs the message text to classify it, do not send the name and phone number alongside. If a notification only needs to say a lead arrived and who owns it, it does not need the free-text message.
This reduces exposure everywhere at once, and it is much easier to do while designing the workflow than to retrofit afterwards.
The parts that need specific attention.
| Area | The question to answer |
|---|---|
| Location | Which region does each service process in, and is a transfer mechanism needed |
| Model APIs | Is the data used for training, and what is the provider’s retention period |
| Run history | How long does the platform keep execution data containing personal records |
| Logs and alerts | Do they contain personal data, and who can read them |
| Credentials | Who has access to systems holding personal data, and when is it revoked |
| Deletion | When the client deletes a record, does it disappear from the copies you created |
Model providers
Sending personal data to a model API is a transfer to another processor. Check whether the provider trains on submitted data by default, whether that can be disabled, what the retention window is and where inference happens. Enterprise and API tiers frequently differ from consumer products on exactly these points, so read the terms for the tier the client is actually on.
Where the classification does not need identifying details, strip them before the call. A model deciding whether a message is a support request or a sales enquiry does not need the sender’s name.
Run history
Automation platforms keep execution data so you can debug, and that data is a copy of the records that passed through. Find the retention setting, set it deliberately, and write down what it is. A ninety day execution history is a ninety day copy of every lead.
Deletion is the obligation automations break most often.
An automation’s job is to copy data between systems. A deletion request requires it to be gone from all of them, and nobody thinks about the copies at build time.
When you design the workflow, write down where records come to rest: the CRM, the spreadsheet somebody asked for, the notification channel, the run history, any intermediate store you added for deduplication. Then agree with the client how deletion reaches each one. Sometimes the answer is a documented manual process rather than an automated one, and that is acceptable as long as it is written down and someone owns it.
The deduplication store deserves specific thought, because it exists precisely to remember records after processing. Storing a one-way hash of the identifier rather than the identifier itself gives you the deduplication without keeping the personal data.
What this means when you subcontract.
If you bring in an implementation partner, you are adding a sub-processor to your client’s chain, and the client generally has to be informed.
The practical version is short. Get the partner under a written agreement covering confidentiality and data protection before you send them anything. Give them their own credentials with the narrowest access that lets them build, and revoke on a date agreed at the start. Prefer anonymised or synthetic data for development, and use real records only where testing genuinely requires it. Make sure your own agreement with the client permits sub-processors at all, because some do not.
A short pre-handover check.
Before the system goes live, confirm you can answer these:
- Who is the controller, and is there a DPA in place with them?
- Can you list every service that sees the data, including alerting?
- Is any field being moved that nothing downstream uses?
- What is the retention period on run history, logs and alerts?
- Where does a deletion request have to reach, and who does it?
- Is anything leaving the EEA, and on what basis?
If you cannot answer one of them, that is the thing to fix before launch rather than after.
If you are scoping an automation that moves client data and want the data path mapped properly before it is built, send us the requirement and the systems involved. Send us the details and we will walk the record through it with you.
Related notes
How to price ongoing automation maintenance.
Maintenance is a separate commercial product from the build, because you are selling availability rather than output. Price it against response, not hours.
How to test an automation before you hand it to a client.
Every automation passes its demo. Production is a thousand submissions from strangers against data nobody chose, and that is where client trust is lost.
How to integrate a system that has no API.
There is no API, or it costs more than the project. Five workable approaches, and how to choose the one that matches what the client can tolerate breaking.
