How it works today in most organizations
The trigger is concrete: a new applicant management system, a location feature in time tracking, or marketing wanting to analyze customer data and build segments. At some point someone says "we will probably need a risk analysis" – and the search for last time's file begins.
What turns up is usually an Excel assessment matrix. It is called "Risk_Assessment_Applicant_Management.xlsx" or "Risk_Time_Tracking_2024.xlsx" and sits in "Data protection/Risks" on the shared drive. The structure is always similar: a column for the risk event, one for the likelihood of occurrence, one for the severity of damage, next to it the product of both and a format coloring the row green, yellow or red. On the far right a column "Measures" holds running text on what one could do.
For the data protection impact assessment (DPIA) a second document joins in, usually a Word form from a seminar or trade association: "DPIA_Template.docx". It is copied, renamed, adapted to the case and finally filed as a PDF. The two files have nothing to do with each other, except that the same person fills them in.
What is copied each time is not only the template but the scale. Because the matrix is rebuilt for every case, one analysis uses three levels, the next five, and in a third the likelihood column reads "medium to high". The colors suggest a comparability that does not exist.
What regularly falls by the wayside
Whether a DPIA is required for the processing at all is mostly answered in someone's head. Somebody reads Art. 35(3) GDPR, glances at the list of the competent supervisory authority, arrives at "not here" – and records that result nowhere. Later, careful examination cannot be told apart from never having thought of it.
The measures decided on also stay in that far-right column, as a declaration of intent: restrict access rights, set up a deletion routine, review encryption. Without a name, date or status. And whatever risk remains after they are implemented is not noted at all.
The moment it becomes apparent
It rarely surfaces in day-to-day business, but in three situations: in an audit, when the assessment methodology is queried; in a customer review, when evidence of the appropriateness of the measures is demanded; and when the person who assessed so far leaves.
The question is then not "do you have a risk analysis?" but "by what method did you assess, which residual risk did you accept – and who decided that?" A collection of spreadsheets has no answer to these three questions.
The analysis
Five Problems Every Assessment Matrix Creates
They do not depend on the care taken by the person assessing, but on the fact that every analysis arises as its own document and ends with the assessment.
View risk analyses in preecoEvery Analysis Has Its Own Scale
Three levels here, five levels there, free text values in between. Results from two analyses cannot be set against each other that way. The question which of twenty processing activities is the most critical stays unanswerable.
The Threshold Analysis Is Not Documented
The check whether a data protection impact assessment is needed under Art. 35 GDPR happens in the head of the person assessing. If it comes out negative, no document arises – and therefore no evidence. In an audit a careful check is then indistinguishable from one that was never made.
The Assessment Does Not Know the Processing
Data categories, data subjects, recipients and existing protective measures are copied into the table. If the processing activity changes, the analysis stays at its old state without anyone noticing.
Measures Without Owners and Deadlines
Whatever stands in the "Measures" column is an intention, not a task. Without a responsible person and a due date it is not followed up. At the next assessment the same measure appears in that column again – once more as a proposal.
Residual Risk and Repetition Are Missing
After the measures nothing is assessed a second time, so it stays open what risk remains and who has accepted it. And if the processing changes later, nobody runs through the analysis again.
The target process in six steps
A robust risk assessment differs from a traffic-light table not by more numbers but by a fixed methodology. These six steps describe it – whatever the tool.
1. Document the threshold analysis, do not just think it. Before every assessment comes the question whether a DPIA is required at all under Art. 35(1) GDPR. This pre-check belongs at the processing activity, with the criteria examined and the result. A documented "not required" is evidence, a thought one is not.
2. Set one scale for all analyses. Likelihood of occurrence and severity of damage are defined once – same number of levels, same meaning per level, same matrix. Only then does a red field mean the same in two analyses, and only then does prioritization across all processing activities make sense.
3. Determine the protection needs by protection goals. Confidentiality, integrity and availability are rated separately, through damage scenarios instead of a gut feeling. That replaces the unanswerable question "how critical is this?" with three questions a department can answer. In preeco | data protection the rating runs through a damage-scenario matrix following the maximum principle; linked systems are included with the accumulation effect.
4. Anchor the analysis at the processing activity. Data categories, data subjects, legal bases, recipients and the technical and organizational measures already sit in the records of processing activities. An analysis that refers to them instead of copying them does not age separately from the processing.
5. Give measures owners and deadlines. Every risk-reduction measure gets a responsible person and a date. That turns a table row into a case that can be followed up – and the next assessment into a continuation, not a repetition.
6. Record the residual risk and set a follow-up. After the measures are implemented, the assessment is repeated. The remaining risk is expressly documented and accepted by a named person. If a high risk persists despite them, Art. 36 GDPR provides for prior consultation of the supervisory authority. Art. 35(11) GDPR also requires a review when the risk associated with the processing changes – which is why a follow-up belongs at the end of every analysis.
Why the methodology counts more than the individual number
No supervisory authority and no auditor will argue that a likelihood should be four rather than three. Something else is examined: whether a comprehensible method exists, whether it was applied consistently, and whether the conclusions fit the measures taken.
That is where individual spreadsheets fail. Ten analyses with ten scales make no methodology, only ten opinions. A fixed scale makes even an uncertain estimate robust, because it stands in relation to all other assessments. That holds for the DPIA under Art. 35 GDPR as much as for a transfer impact assessment (TIA) or a supplier assessment.
Before and after in direct comparison
| Criterion | Before: assessment matrix in Excel | After: methodical risk analysis |
|---|---|---|
| Methodology | Rebuilt per case, scale per template | One scale and matrix for all analyses |
| Threshold analysis | Checked mentally, not recorded | Documented pre-check at the processing activity |
| Data basis | Details copied from the records | Linked to processing, recipients and measures |
| Protection needs | One blanket criticality judgment | Separated by confidentiality, integrity, availability |
| Measures | Free text in the last column | Measure with responsible person and deadline |
| Residual risk | Not reassessed | Assessed after measures, documented and accepted |
| Repetition | Only on a new trigger | Follow-up and reassessment on changes |
| Provability | File of unknown status | Approved revision with risk mapping, as PDF or DOCX |
In practice
This is what it looks like in preeco | data protection
The three building blocks that carry the process described.
Risk Analysis and Impact Assessments
A guided form for the DPIA under Art. 35 GDPR and for the TIA after Schrems II, graphical risk mapping as a risk matrix, measures with responsible people and deadlines, plus an automatic revision on every approval.
Processing Activities and Systems
The threshold analysis sits directly in the processing activity, and its result feeds into the check under Art. 35. The protection needs assessment rates confidentiality, integrity and availability through a damage-scenario matrix.
TOMs and Policies
Technical and organizational measures under Art. 32 GDPR are recorded in a structured way and linked to the processing activities they apply to. The risk analysis thereby assesses the actual state instead of an assumption.
What the switch means in practice
The most common objection is that all previous assessments would then have to be redone. That is not necessary. The sensible route is the reverse: first set the scale that will apply to all analyses, then move over the processing activities due anyway – new systems, upcoming reviews, everything with a recognizably high risk. The existing stock follows in the regular cycle.
The effort rarely lies in the technology. It lies in the decisions: how many levels the scale should have, what the highest severity level means concretely for your organization, and who may accept a residual risk. Those three answers are the actual work. Once made, every further analysis is an application, not a new construction.
Three mistakes that make the switch unnecessarily hard
Building the scale too fine. A ten-level assessment produces false precision and debates about decimal places. Three to five clearly described levels per axis are more robust in practice, because they are applied consistently.
Skipping the threshold analysis. Anyone who starts straight away with the DPIA later has no evidence why it was prepared for this processing activity and not that one. Precisely the negative result is the evidence needed in an audit.
Running the analysis without the department. The department that operates the process knows the likelihoods, not data protection. Without it, a methodically clean assessment gets the wrong input values.
How you can tell it is time
An Excel matrix is not a mistake. It becomes a risk as soon as one of these applies:
- Two of your analyses use different scales.
- You cannot show why no DPIA was prepared for a processing activity.
- Measures from an old assessment reappear unchanged in the next.
- For no processing activity is it documented who accepted the residual risk.
- After a change to a processing activity the analysis was not run again.
If none of these applies, your methodology is fine. If two or more apply, your analyses already document less than they cost.
FAQ
Frequently asked questions about risk analysis and the DPIA
A DPIA is required under Art. 35(1) GDPR where a processing operation is likely to result in a high risk to the rights and freedoms of natural persons. Art. 35(3) GDPR names standard examples, such as systematic and extensive evaluation with automated decisions, large-scale processing of special categories of data under Art. 9 GDPR, or systematic monitoring of publicly accessible areas on a large scale. In addition, the supervisory authorities publish lists of processing operations for which a DPIA is mandatory. The legal assessment in the individual case remains with the controller.
The threshold analysis is the pre-check of whether an impact assessment is needed for a processing activity. The GDPR does not prescribe any particular form for this pre-check, but through the accountability obligation under Art. 5(2) GDPR it does require that you can substantiate your decisions. In practice that means: record the result "no DPIA required" together with the criteria examined. Without that documentation it cannot be shown in an audit that the question was asked at all.
For a single assessment, yes – the GDPR does not prescribe a tool. The limit is not reached with the first analysis but with the tenth: as soon as assessments are meant to be comparable with each other, measures followed up and repetitions triggered, the spreadsheet lacks exactly the properties that matter. What is decisive is not the format but a uniform scale, a documented residual risk and a verifiable state.
Art. 35(11) GDPR requires a review when the risk associated with the processing changes – for example with a new service provider, a changed processing purpose, additional data categories or a new technical environment. The regulation names no rigid cycle. In practice a scheduled follow-up in addition to the event-driven check has proven itself, so that the assessment does not become outdated unnoticed.
Responsibility for carrying it out lies with the controller. Where a data protection officer has been designated, their advice must be sought under Art. 35(2) GDPR. The area that operates the processing and IT should also be involved professionally – that is where the knowledge about likelihoods of occurrence and about the protective measures actually implemented sits. If the assessment shows a high residual risk despite the planned measures, the supervisory authority must be consulted under Art. 36 GDPR before the processing begins.
Go through your assessment methodology together
Bring an existing risk assessment along. In 30 minutes we clarify the scale, the threshold analysis and the route to a documented residual risk.