Automating something that touches personal data: what has to be written down

An automation is a processing operation. Once you accept that, everything below is ordinary and none of it is surprising.

The reason it needs saying is that automation work does not look like data work. It looks like plumbing: an API key, a webhook, a retry policy, a mapping between two field names. Plumbing does not normally have a lawful basis, and nobody asks it for one.

But moving a customer record from a form into a CRM, from a CRM into an email platform, and from there into a spreadsheet somebody reports off, is four processing operations with a purpose each. If the business never wrote down what those purposes are, it cannot answer the first question anybody asks it.

None of these takes long. All of them take longer after the fact, and one of them cannot be done after the fact at all.

This is the question that has to be answered before the build rather than during it, because Article 35 requires the assessment prior to the processing.

Two items on the Data Protection Commission's list catch automation work directly. Item 1 is using personal data on a large scale for a purpose other than the one it was initially collected for, under Article 6(4). Item 9 is combining, linking or cross-referencing separate datasets where the linking contributes to or is used for profiling or behavioural analysis of individuals, particularly where the datasets come from different sources, were processed for different purposes, or by different controllers.

An automation that joins a CRM to an analytics property to a payment processor in order to score or segment customers is item 9 in the list's own words. One that copies a customer list collected for fulfilment into a marketing platform is item 1 territory, and Article 6(4) also requires a compatibility test before you may do it at all, which is a separate question from whether an assessment is needed.

The screening takes about ten minutes and the most common honest outcome is that no assessment is mandatory.

From building and running these, the failures repeat, and none of them is exotic.

The intermediate copy nobody deleted. A pipeline stages records in a bucket, a queue or a spreadsheet, the run finishes, and the staging copy stays. It is outside the retention policy because nobody knew it existed.

Logs that contain payloads. Debug logging that dumps a whole record is the fastest way to put personal data into a third-party observability service that is not in your register and has no agreement with you.

The shared service account. An integration running as a real person's account means the audit trail says a human did it, and it means access does not end when they leave.

The connector that reads everything. Most integration platforms request the broadest scope available at setup, because that is the path of least resistance, and the scope is never narrowed afterwards.

The error email. A failed job that mails the payload to whoever is on support has just moved personal data into an inbox nobody assessed.

There is a line between an automation that moves data and one that decides something about a person, and crossing it engages a rule that has been in force since May 2018.

Article 22 gives a data subject the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. It has no deferred start date and does not wait for the AI Act.

The trap is the word solely. A human in the loop only takes you outside Article 22 if that person has real authority and actually exercises it. Somebody clicking approve on a queue of scores is not a decision-maker, and the hiring case is the clearest illustration.

So an automation that routes, prioritises or flags is ordinary. One that refuses, prices or rejects is a different conversation.

If you build automations for other people, most of this lands on you as a processor rather than as a controller, and two duties are yours specifically.

Article 28(3) requires the processing to be governed by a contract setting out the subject matter, duration, nature and purpose, the type of personal data and categories of data subject, and the obligations of both parties. A general terms of business document does not do this.

Article 33(2) requires the processor to notify the controller of a personal data breach without undue delay. There is no 72 hour allowance for a processor: the controller's clock is running from its own awareness, so a supplier who takes two days to pass it on has spent most of the client's window. The clocks are set out here.

The Data Protection Commission has found against a small Irish organisation on exactly this pairing. In its inquiry into a credit union, the security failure was one finding and the absence of processor due diligence and a compliant processor agreement were two more.

The whole of the above fits on one page per automation, and writing that page at build time costs about twenty minutes.

Name, purpose, the systems it touches, the personal data it moves, the lawful basis, the retention, the processors involved, whether it makes a decision about anybody, and who owns it. That page is simultaneously the Article 30 entry, the answer to a subject access request, the input to a breach assessment and the handover document.

It is also the thing that makes the automation maintainable, which is the argument that actually gets it written. Every one of those fields is something the next engineer needs anyway.

Our own retention schedule is the same idea applied to a company rather than to a pipeline: every category of record, how long it is kept, what starts the clock, and the statute behind it.