Data protection when digitising processes: in practice

In many companies data protection is an administrative topic: there is a privacy notice on the website, a confidentiality undertaking signed by staff and a folder of paperwork somewhere. As soon as a workflow is digitised, that situation changes fundamentally. A paper case file that sat in a lockable cabinet and was handled by three people becomes, after digitisation, available to everyone with access to the system: searchable, copyable, analysable and forwarded in seconds. This new accessibility is the real reason why the same data has to be assessed differently after digitisation than before.

Legal uncertainty and data protection requirements are regularly named in surveys as obstacles to digitisation projects in mid-size companies (Bitkom, DIHK). That is rarely down to the requirements themselves and mostly down to sequencing. Once a system is live, rights have been granted and the first reports are running, every correction becomes expensive. Answering the data protection questions while the workflow is being recorded gets most of the work done before the first line of configuration exists. In a process analysis the information arises anyway: which data appears at which step, who sees it, where it is transferred and how long it stays.

There is also the question of responsibility. The obligations fall on the company as controller — not on the software vendor, not on the provider building the interface and not on the person carrying out the workflow. Whoever decides on the purposes and means of a processing operation has to be able to demonstrate that it is lawful. That demonstration consists of documents: the record of processing activities, the contracts with providers, the access concept, the deletion schedule and the description of the measures in place. None of these documents needs to be long. They do, however, need to match actual practice, because what gets examined is the lived state of affairs, not the intention.

Processing personal data is only lawful if it can be based on one of the grounds in Article 6(1) GDPR, which names six. In day-to-day operations three of them carry the bulk: performance of a contract or pre-contractual steps, compliance with a legal obligation, and legitimate interest. Consent is often assumed to be the default answer, but it is the worst choice for mandatory workflows because it has to be freely given and can be withdrawn at any time. An order process that could no longer be completed after a withdrawal of consent was built on the wrong basis from the start.

What matters is assigning a basis per processing operation, not per system. An inventory management system holds order data processed for contract performance, invoice data whose retention rests on a legal obligation, and possibly an analysis of purchasing behaviour that needs its own justification. Writing down „inventory system: contract performance“ does not answer the question. The effort of separating these arises once; afterwards any discussion about a planned report takes minutes, because the basis has already been named.

With legitimate interest, the balancing test is the actual piece of work: the company's interest is weighed against the interests and fundamental rights of the people concerned, and the outcome is briefly documented. Half a paragraph is usually enough — it only has to show that the weighing took place and which considerations went into it. For logging access to a document archive, traceability in case of misuse speaks in favour; the fact that logs allow conclusions about working behaviour speaks against. Out of that tension come limits on evaluation, and it is better to set them in advance than to look for them in a dispute.

The most common finding when paper files are digitised is that everyone can see everything. That is rarely deliberate. It happens because a new system is initially set up with broad rights so the launch does not stall on missing permissions, and because nobody narrows them afterwards. The standard is necessity: access goes to whoever needs the data for their task — not to whoever finds it interesting or might conceivably need it one day. Personnel files, sickness notifications, applications, warnings and salary data are the areas where excessive access causes damage fastest.

In practice this works through roles rather than individual permissions. A role describes a task — order processing, accounting, workshop management, management — and carries the rights belonging to that task. People are assigned to roles. The benefit shows at handover: when a colleague moves department, the role is swapped instead of hunting for twenty individually granted checkboxes. The rule for leavers matters just as much. In many companies accounts stay active after somebody leaves, because nobody was formally made responsible for the technical part of the exit process.

An access concept also has to answer what gets logged. An access log makes sense so that a suspicion of misuse can be investigated at all, and it is itself a processing of personal data with its own legal basis, its own retention period and its own limits on evaluation. A short written decision works well: what is logged, how long it is kept, who may look at it and on what occasion. Without that decision, logs arise that either may never be evaluated or quietly turn into performance monitoring.

Article 32 GDPR requires measures appropriate to the risk. Appropriate means: depending on the state of the art, the cost, the nature of the processing and the risk to the people concerned. A company with thirty employees is expected to invest differently from a hospital group — but the basic elements are the same. The German federal authority for information security publishes building blocks that can be used as a checklist even without an in-house IT department (BSI).

In digitisation projects four measures are almost always affected: transfer between systems, access and permission control, backup with a tested restore, and logging. Alongside those sit organisational points that need no technology and are regularly missing anyway: a named responsible person, a confidentiality undertaking signed by staff, a short briefing on the new workflow and a procedure for when something goes wrong. Where ongoing IT operations are already governed by an agreement, these points can be anchored there instead of being run as a separate topic.

Data protection work in a digitisation project is not an endless side topic but a manageable set of results. When a digitised workflow goes live, these documents should exist — not as a ring binder but as a few pages that match actual practice and carry a date. For a single workflow the effort is typically a matter of hours, provided the details were captured while the workflow was being recorded (project experience); reconstructed afterwards, it multiplies.

These documents age. A system change, a new provider, an additional report or a change of responsibility makes part of the description inaccurate. An annual review with a fixed date is therefore more effective than the intention to update immediately after every change. And to be entirely clear once more: this article organises the tasks and does not replace legal advice. Whether a specific processing operation is lawful, which period applies in an individual case and how an agreement should be worded belongs in a review by a qualified adviser.