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

An automation is a processing operation.

Automation work looks like plumbing: an API key, a webhook, a retry policy, a mapping between two field names. Each of those can move personal data.

Moving a customer record from a form into a CRM, then into an email platform, then into a spreadsheet somebody reports from, is a chain of processing operations. Each one has a purpose. If the business never wrote down what those purposes are, it cannot say what each copy is for.

Each of them is harder to write once the automation is running.

This question has to be answered before the build, because Article 35 requires the assessment before the processing starts.

Two items on the Data Protection Commission's list can apply to 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 significantly 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 takes a customer list collected to fulfil orders and copies it into a marketing platform can fall under item 1. Unless the person consented or a law requires it, Article 6(4) also requires you to test whether the new use is compatible with the original one before you may do it at all. That test is a separate question from whether an assessment is needed.

The screening can find that no assessment is required.

Five places an automation can leak personal data.

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 puts personal data into whichever service holds the logs, and that service may not be in your register or have an agreement with you.

The shared service account. When an integration runs under a real person's account, the audit trail says a human did it. Its access also does not end when that person leaves.

The connector that reads everything. A connection set up with the widest access available keeps that access until somebody narrows it.

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. Crossing it can bring in a rule that has applied 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 word that decides it is solely. A human in the loop only takes you outside Article 22 if that person has real authority and exercises it. Somebody clicking approve on a queue of scores is not a decision-maker, and the hiring case shows it.

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

If you run automations that process a client's personal data on its behalf, you are its processor. The purpose, the lawful basis and the retention decision above stay with the client as controller. Two of the duties that fall on you as the processor:

Article 28(3) requires the processing to be governed by a contract that sets out the subject matter and duration, the nature and purpose, the type of personal data and categories of data subject, and the obligations and rights of the controller, and that binds the processor to the terms listed in its points (a) to (h). Terms of business without those clauses do not meet it.

Article 33(2) requires the processor to notify the controller of a personal data breach without undue delay after becoming aware of it. There is no 72 hour figure for a processor. The European Data Protection Board's breach guidelines say that, in principle, the client becomes aware once you have told it, so its 72 hours start then. The guidelines recommend telling it promptly so it can still meet that deadline. The clocks are set out here.

The Data Protection Commission's inquiry into a small Irish credit union shows the processor paperwork being examined after a breach. Alongside the security finding, it found no due diligence on the processor and no agreement that met Article 28(3).

The whole of the above fits on one page per automation, written at build time.

Name, purpose, the systems it touches, whose personal data it moves and which data, where the data goes, including any transfer outside the EEA, the lawful basis, the retention, the security measures, the processors involved, whether it makes a decision about anybody, and who owns it. That page covers the Article 30 entry, and it is the starting point for a subject access request, a breach assessment and the handover.

It also makes the automation easier to maintain, because whoever maintains it needs every one of those fields anyway.

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