How to Tell Whether an Automation Proposal Takes Data Protection Seriously

In most proposals for process automation, data protection appears as a single sentence: processing is of course carried out in line with the General Data Protection Regulation. That sentence names no retention period, no storage location and no responsibility. It is worthless, and it hides the one property of automations that causes trouble later.

An automation does not simply move data. It keeps a record.

Every automation writes a log, and that is where the problem starts

Every serious platform stores what has passed through a process. Without those records nobody could work out why a process failed last night. What gets stored is usually not just the fact that something ran, but the content: the incoming message, the intermediate result after each step, the answer from the target system.

For order intake that means customer name, contact person, delivery address and occasionally payment details. For a recruiting process it means complete applications. In hospital administration it can include categories of data that receive special protection under Article 9.

Platform defaults are built for troubleshooting, not for data minimisation. When in doubt they keep records longer than a deletion policy would allow. In a self-hosted setup, automatic clean-up is often a setting somebody has to switch on deliberately. If nobody knows about it, after a year of operation every single run of that year sits complete in the database. Exact periods differ by provider and plan and keep changing. The reliable answer is in your own account settings, not in a blog post.

The copies sit in more places than a proposal describes

The obvious place is the execution history. Less obvious is the queue of failed runs: when a target system does not answer, the transaction sits there with the full data set until somebody clears it out, and rarely does anybody.

Then come the copies outside the platform. Many processes write a line into a spreadsheet at the end, as improvised monitoring. Those tables grow for years and often hold more personal data than the actual processing. The same goes for error notifications. If every failure posts the complete record into a chat channel or a mailbox so the team can see immediately what went wrong, that record now lives there too. Finally there are the small key value stores a platform offers so a process can remember something between runs. They get set up and forgotten.

Suppose a process handles orders and reports every failure with the full record into a chat channel. The same personal data then sits in the platform log, in the failure queue and in the chat history. When somebody deletes later, only the first of those three usually comes to mind.

The responsibility is yours, not the platform's

A common assumption is that storage is the provider's business. It is not. You are the controller, the platform is your processor under Article 28. It processes on your behalf and on your instructions. If a default keeps data for months and nobody changes it, that is your retention, not theirs. A processing agreement does not move responsibility, it only governs how the provider handles what you entrust to it.

Three practical consequences follow. Article 5 requires storage limitation, meaning data is kept only as long as the purpose requires. Article 17 requires deletion of all copies on request, and a copy in an execution log is a copy. Article 15 requires complete disclosure, and only someone who knows what their processes stored can disclose completely. On top of that, automations belong in the record of processing activities under Article 30, where they are usually missing.

Statutory retention is not a blanket excuse

At this point somebody always objects that invoices have to be kept for ten years anyway. True, and that is a genuine legal basis. But that duty justifies retention in the accounting archive it belongs to, audit-proof and with access control. It does not justify an incidental side copy in the history of a process that passed the invoice along once two years ago. Mixing the two means keeping everything and being able to justify nothing.

What a proposal should actually say about data protection

Four points, all of which you can check without technical knowledge.

First, which categories of data run through which process. One line per process is enough, and that same line belongs in your Article 30 record afterwards.

Second, how long logs are retained, who sets that period and where the setting lives. For troubleshooting, a few days to a few weeks is usually plenty. Anything beyond that needs a reason.

Third, where processing happens and whether a processing agreement is in place. With a self-hosted setup the location question is quickly answered, which makes the retention question all the more important, because nothing disappears there without clean-up.

Fourth, how a deletion request reaches the automation. For a small estate a documented manual step is fine. What matters is that the processes appear in the deletion routine at all. In most companies that routine stops at the main systems.

Data minimisation is also the cheaper build

The strongest lever sits ahead of every setting: do not push everything through in the first place. If a process only needs an order number and a status to trigger a notification, the complete customer record has no business being in it.

That is not only the more privacy-friendly option, it is the cheaper one. Every field that travels through a process has to be mapped, validated and adjusted whenever the source system changes. Fewer fields mean less coordination during the project, fewer sources of error in operation and smaller logs. Here, for once, data protection is a discount rather than a surcharge.

What to settle before the first proposal

Write down two things: which personal data the planned process genuinely needs, and how long that data may sit anywhere afterwards. With those two answers, a boilerplate sentence in a proposal turns into a checkable commitment, and you can tell immediately whether a provider knows the subject or is merely quoting it. A provider who raises these questions unprompted is pricing carefully. One who points at the platform's processing agreement and considers the matter closed has missed the point.

Sophera Consulting records both answers before implementation, puts retention and deletion path in writing for each process, and only then quotes a fixed price, with no subscription and with handover including documentation. The entry point is free in the automation check.