How it works today in most organizations
It starts with a column. In the systems list – usually a spreadsheet called "Systems_Overview.xlsx" or a second worksheet in the records of processing activities – there is a column called "Protection needs" on the far right, with three possible values: low, medium, high. The column takes two minutes to create, and it looks like a method.
It is filled in a single meeting. Two hours, three people: the data protection officer, someone from IT and the head of a business unit. The list is worked through from top to bottom. For every system a sentence like "That one is critical, I would put it on high" comes up, nobody objects, the cell is filled, the next system follows.
The meeting is not the problem. The problem is that the three people carry different yardsticks in their heads without noticing it. For IT, "high" is a system whose outage brings operations to a halt. For data protection, "high" is a system holding special categories of personal data. For the business unit, "high" is whatever its own department needs in order to work. All three say the same word and mean something different.
The result reads oddly after only a few weeks
Applicant management is on "high" because someone in the meeting was thinking of unencrypted attachments. The payroll system is on "medium", even though health data, wage garnishments, religious affiliation and bank details all come together there. Why one rating turned out higher than the other, nobody can say any more. The justification was spoken, not documented. The spreadsheet holds nothing but the result.
Two years later a different person reassesses the same systems – after a change of staff, ahead of an audit, or because a new set of records is being built. They arrive at different levels, because they have different scenarios in mind. Both assessments are equally unfounded, and neither can be defended against the other. In the end they sit side by side, often in two files, and the question of which one applies gets postponed.
The moment it becomes visible
In day-to-day work it does not become visible. It becomes visible in two situations. The first: measures and budgets are supposed to be derived from the protection needs. For a system on "high", two-factor authentication, a second site or a shorter backup interval is requested – and management asks what that follows from. The second: an auditor does not ask about the level, but about the justification. "How did you arrive at high, and why is the payroll system on medium?" A dropdown list has no answer to that question.
The analysis
Five Problems Every Estimated Rating Creates
They do not arise from carelessness, but from the fact that a single dropdown field can hold neither a yardstick nor a justification.
View Processing Activities in preecoNo shared yardstick
The same processing activity is given a different level depending on who assesses it. That leaves the ratings incomparable with one another, and any prioritization across the systems list ends up in the wrong order.
The security objectives get mixed together
A system can be high on confidentiality and low on availability. A single value hides that difference and leads to measures at the wrong end: encryption where redundancy is needed, or the other way round.
No justification, only a result
Without a described damage scenario the level cannot be reviewed. It can neither be explained in an audit nor defended against a department that considers the rating excessive.
Linked systems are left out
A system that bundles data from three processing activities needs more protection than any single one of them. In a list of individual rows this cumulation effect drops out systematically – and it hits precisely the systems that contain the most: data warehouse, archive and backup.
The assessment ages unnoticed
New categories of data are added, an interface suddenly delivers personnel numbers along with the rest, a service provider takes over operations. The level stays the same, because nobody has a reason to touch it.
The target process in six steps
A robust assessment differs from an estimate not through more effort, but through a fixed order. These six steps describe it – no matter which tool you work with.
1. Assess the security objectives separately. Confidentiality, integrity and availability are rated individually, not combined into a single aggregate value. Only then does it become visible that an applicant portal is above all a confidentiality matter, while time tracking above all needs to be available.
2. Describe one damage scenario per security objective. The actual statement is not the level, but the sentence underneath it: what happens in concrete terms if this data is disclosed, falsified or unavailable – for the data subjects, for operations, for contractual and statutory obligations. Writing that down is the work; the level is only its result.
3. Apply the maximum principle instead of averaging. A processing activity with one high and two low security objectives is not "medium". The highest value determines the overall protection needs, because damage does not become smaller just because other aspects are uncritical.
4. Include linked systems and assess the cumulation. Wherever several processing activities converge on the same system, you check whether the bundling raises the protection needs beyond the highest individual value. That is the cumulation effect, and it almost always concerns analysis, archive and backup systems.
5. Inherit the protection needs instead of maintaining them twice. The protection needs determined on the processing activity feed into the linked data processing systems. A separate, second assessment of the same thing becomes unnecessary – and with it the contradiction between two lists.
6. Export the assessment so that it can be reviewed. A summary with the overall protection needs, the damage-scenario matrix and the inherited sources, as PDF or DOCX. That turns a cell into a document you can put in front of an auditor.
Protection needs or risk – what is the difference
Both terms are often used interchangeably, but they answer different questions. Protection needs answer how severe damage would be if it occurred. Risk analysis answers how likely it is and what is being done about it. Protection needs therefore come first: they limit which measures are appropriate at all. Art. 32 GDPR requires measures appropriate to the risk – without determined protection needs there is no yardstick for "appropriate". The term itself does not come from the GDPR but from BSI IT-Grundschutz, and that is also where the methodology sits.
Before and after in direct comparison
| Criterion | Before: a column in the systems list | After: an assessment with method |
|---|---|---|
| Yardstick | Everyone rates by their own gut feeling | One shared damage-scenario matrix for all objects |
| Security objectives | One aggregate value for everything | Confidentiality, integrity and availability kept separate |
| Justification | Spoken in the meeting, lost afterwards | One described scenario per security objective on the object |
| Linked systems | Stay out of scope | Are included in the assessment |
| Cumulation | Not provided for | The cumulation effect is explicitly assessed |
| Inheritance | Duplicate maintenance in two lists | Protection needs feed into the linked systems |
| Analyzability | Sorting a text column | Protection needs visible and filterable in the overview table |
| Evidence | One cell with one word | Export as PDF or DOCX with matrix and sources |
In practice
What this looks like in preeco | data protection
The three building blocks that carry the process described above.
Protection needs on the processing activity
The assessment sits directly on the processing activity and runs through a damage-scenario matrix following the maximum principle – for confidentiality, integrity and availability, either manually or AI-assisted. The resulting protection needs are visible and filterable in the overview table.
Risk analysis and DPIA build on it
The assessment of likelihood and the review under Art. 35 GDPR draw on the same set of data. The protection needs are therefore not a side document but the basis on which the risk analysis is conducted.
Inheritance into the linked systems
The protection needs feed into the linked data processing systems following the maximum principle, including the cumulation effect. If you also use preeco | information security, you work there in asset management with the same set of data instead of a second list.
What the switch means in practice
The most common objection is that a methodical assessment takes too long for a hundred systems. That is true for the first pass and not afterwards. The scenarios repeat heavily: personnel data, customer data, payment data and access credentials cover most processing activities. Once a scenario has been formulated, rating comparable processing activities is a matter of minutes. What takes effort are the cases where it really is unclear how severe the damage would be – and those are exactly the cases an estimate has skipped so far.
So do not begin with the complete list, but with the processing activities that are going to be reviewed anyway: personnel, recruiting, customer data, payments and the central analysis systems. Those few assessments produce the scenarios all the others can be aligned to. The rest follows on a cycle, and it follows wherever a processing activity is being touched anyway.
Three mistakes that make the assessment worthless
Recording only the level. Anyone who does not describe the scenario has not documented the assessment, only its result. Six months later the difference is no longer recognizable.
Averaging across the security objectives. An average of three security objectives looks balanced and is unusable: it lowers precisely the value that should be driving the measures. The maximum principle is not a precaution, it is the logic of the matter.
Assessing the processing activity without its systems. As long as processing activity and system are rated separately, two truths come into being, and the higher one is usually in the file nobody opens any more. Only inheritance turns two assessments into one.
How to tell that it is time
- You cannot say for any given rating which damage scenario sits behind it.
- Two people arrive at different levels for the same processing activity.
- The protection needs in the systems list and in the records differ.
- Measures or budgets are supposed to be justified from the protection needs.
- The last assessment is further back than the last change to the system.
If none of that applies, the existing estimate is enough. If two or more apply, it will not hold up in the next review.
FAQ
Frequently asked questions about protection-needs assessment
Protection needs describe how severe damage would be if confidentiality, integrity or availability were breached. The term comes from BSI IT-Grundschutz, not from the GDPR. Art. 32 GDPR requires measures appropriate to the risk – the protection-needs assessment supplies the yardstick that makes it possible to judge that appropriateness in the first place.
Protection needs answer how severe damage would be. Risk analysis answers how likely it is and which measures reduce it. Protection needs come first and limit which measures are appropriate; the risk analysis builds on them. Keeping the two apart prevents an unlikely threat from talking down protection needs that are in fact high.
The maximum principle means that the highest individual value determines the overall protection needs. A processing activity with high confidentiality needs and low availability needs is therefore high, not medium. An average would lower the level that carries the measures – the damage from a disclosure does not become smaller because an outage would be bearable.
There is no statutory deadline. A review on a fixed cycle makes sense, supplemented by reviews triggered by events: new categories of data, a new interface, a change of provider or a changed group of users. Follow-up dates and tasks remind the responsible person, so the assessment does not age more quietly than the system.
No, and duplicate maintenance is actually harmful, because it creates two states. In preeco | data protection the protection needs are determined on the processing activity and feed into the linked data processing systems following the maximum principle. The only systems that need an assessment of their own are those where bundling several processing activities raises the protection needs further.
Go through one rating together
Take a system from your list that is on "high". In 30 minutes we will go through the damage scenarios and show what the assessment makes of it.