What to settle about data protection before you automate a process with personal data

The question that comes up most often before automating a process that touches personal data is whether it is allowed at all. It almost always is. Routing job applications to the right manager, pre sorting patient enquiries, keeping customer records aligned between two systems: none of that is forbidden when it is set up properly. The expensive part sits somewhere else. It sits in the fact that nobody decided, before the project started, where the data ends up after processing and who owns that question.

Companies that settle these points before signing get a firm price. Companies that settle them afterwards get a change request.

An automation is one more place where data lives

Every automation platform stores what passed through a run. That is deliberate, not sloppy. Without an execution history nobody can explain why an order failed at three in the morning. The price is that each individual run holds a full copy of the data it processed, including attachments, free text, and whatever a sender happened to write into a message.

So a second storage location appears next to the system of record. Retention in the applicant tracking system, the patient administration system, or the accounting package is usually defined. The layer above it often has no owner at all, because it never made it into the record of processing activities. Suppose a company deletes rejected applications after six months while the automation platform keeps its history for a year. The deadline is met on paper and missed in substance.

That is not an argument against automating. It is an argument for putting the retention period of the automation layer in writing, exactly as you did for the system of record.

Access requests and deletion apply to every copy

A subject access request does not ask about the leading system. It asks about all data an organisation processes about a person. Deletion works the same way. Anyone who only looks in the specialist system answers incompletely without noticing.

In practice this means three things have to be fixed for every automated process before it is built: which personal fields it touches at all, how long the execution history is kept, and who searches that history when someone asks. Those three answers fit on half a page. Writing them takes minutes while the process is fresh, and hours two years later.

What you need to know about the chain behind the platform

As soon as an automation runs on an external service, a processor enters the picture. If a language model is used on top of it to read an email or turn free text into structured fields, a second one enters. Your organisation remains the controller.

Four questions therefore belong on the table before you sign. Which providers are involved in the processing? Where are their servers located? Is there a data processing agreement with each of them? And is your data used for training, or is that contractually excluded? A provider who cannot answer those four within a day is telling you something about how they work.

Hospitals, practices and medical care centres have professional confidentiality on top of that. There the question is not only whether an agreement exists, but whether processing outside the building is permissible in the first place. That decision comes early, because it determines the entire construction. A process that runs fully on your own infrastructure costs more, and in sensitive areas it is often the only workable option.

Collecting less is cheaper than protecting more

The most effective measure is unglamorous. A process should touch only the fields it genuinely needs.

An acknowledgement of receipt needs the sender address. The attached CV does not have to travel through the same automation. Scheduling an appointment needs a name and a way to reach the person, not the reason for the visit. Deciding this scope before anything is built saves twice over. Fewer fields mean less work on safeguards, shorter reviews, and a far smaller problem if something does go wrong.

The second measure concerns error messages. When a process fails, many platforms send the affected record in plain text to a shared mailbox. Personal data then sits in an inbox that was never meant for it, and nobody ever cleans it out. A message containing the reference number and the failing step is entirely sufficient to fix the fault.

What belongs in the quote

A quote for a process involving personal data should name three things explicitly: which data is processed, how long it remains on the automation layer, and which providers the process runs through. Without them the price is not comparable, because it stays unclear whether the safeguards were costed in.

Expect a process with personal data to cost more than the same process without it. The difference does not sit in the business logic. It sits in logging, access rights, retention, and what happens when a run breaks off. That is the last part to economise on, and the first part missing from a suspiciously cheap offer.

Sophera Consulting looks at which fields a process actually needs before anything is built, records retention, providers and responsibilities in writing, and then builds the process for a fixed price, with no subscription and with documentation at handover. The entry point is the free Automation Check.

The recommendation

Treat the automation layer as another system that stores data, because that is what it is. Before you request the first quote, settle three things: which personal fields the process needs, how long the execution history is kept, and who inside the company owns that layer.

Those three decisions cost you an hour. They make quotes comparable, they prevent the most common change request in this kind of project, and they are the answer you need ready when a supervisory authority or a data subject asks.