Data protection assessment for software, tools and business processes

What a data protection concept delivers

A data protection concept is a comprehensive record of the relevant facts and an initial assessment under data protection law. It is comparable to an initial consultation with a data protection consultant or data protection officer: what happens to which data, who is involved, what is the legal basis and where is action needed?

This makes the concept a very good basis for further reviews and next steps, such as contracts, privacy notices or a data protection impact assessment. At the same time, it fulfills your accountability obligation (Art. 5(2), Art. 24 GDPR): you can demonstrate that you have assessed the processing. The GDPR-Giraffe draws on extensive expertise and procedural guidance developed from Dr. Thomas Helbing’s experience with many hundreds of data protection consultations.

The right scope: process, not software

The subject of the assessment is a specific business process, not a product. “Microsoft 365”, “HR” or “CRM” are not processing activities, whereas “applicant management via Personio” or “newsletter delivery via an email tool” are. Only then can purposes, data and legal bases be assigned properly.

Larger projects are divided sensibly, for example by topic, by groups of data subjects or by function. For a website, this could mean treating server log files, the contact form and web analytics as separate parts.

Facts first, then the assessment

A robust concept strictly separates what actually happens from the legal classification. The facts describe the subject matter, the parties involved, the processing phases from collection to deletion, data categories and sources, purposes and recipients. Only then comes the assessment, with references to the law and in more detail where things get critical.

This separation makes the concept comprehensible, including for third parties such as the supervisory authority, the works council or customers. Open assumptions are marked as such and listed as points to be clarified.

The purpose-data matrix as the backbone

At its core, the concept assigns each data category to the purposes for which it is used. Each of these combinations needs its own legal basis under Art. 6 GDPR. A single justification covering several purposes does not work, and the CJEU also examined the legal bases purpose by purpose (C-252/21, Meta Platforms).

Likewise, each combination receives a deletion rule with a period and a starting point, for example six or ten years from the end of the calendar year for retention obligations under German commercial and tax law (Sec. 257 HGB, Sec. 147 AO). “Indefinite” or “as long as useful” is not a deletion rule.

Roles, recipients and third countries

For every service provider involved, you need to clarify whether it is a processor, a joint controller or an independent controller. What matters is who actually decides on purposes and means. An existing contract is only an indication. This determines which contract is required: a data processing agreement, an arrangement under Art. 26 GDPR or none.

A transfer to a third country does not only occur when servers are located abroad. It is enough that, for example, a US parent company, a sub-processor or support staff in a third country can access the data. In that case, a legal basis and an adequate level of protection must both be in place, for instance via the EU-US Data Privacy Framework or standard contractual clauses with a transfer impact assessment. The GDPR does not recognize an intra-group privilege.

Special cases: sensitive data, change of purpose and AI

Some constellations require an additional review:

• Special categories (Art. 9 GDPR): health data often hides in free text, application documents or absence records. Besides an exception under Art. 9(2), a legal basis under Art. 6 is also required.
• Change of purpose (Art. 6(4) GDPR): if existing data is used for new purposes, such as training an AI, compatibility with the original purpose and the legal basis must be assessed separately. The guiding question is the reasonable expectation of the data subjects.
• Automated decisions (Art. 22 GDPR): if a system, such as an AI, decides about individuals without genuine substantive review by a human, strict limits apply. What matters is the actual process, not what is written on paper.

Common mistakes

These weaknesses come up particularly often in practice:

• A piece of software instead of a specific business process as the subject of the assessment
• A single legal basis covering several purposes
• Performance of a contract (Art. 6(1)(b)) as the basis for advertising, product improvement or third-party data
• Acceptance of terms and conditions treated as consent
• Deletion periods without a starting point or justification
• Third-country transfers assessed solely by server location
• Roles derived from an existing contract instead of the actual circumstances