DPIA Explained: When You Need One and How It Meets NIS2 Risk Assessment

The Data Protection Impact Assessment is GDPR's structured way of asking a question before it becomes a problem: this processing we are about to do — how badly could it go for the people whose data it is? It is one of the GDPR's more genuinely useful instruments, and also one of the most inconsistently applied, because the threshold for when it is mandatory is widely misunderstood.

This article covers when a DPIA is legally required, how to run one, and — the part most guidance omits — how the DPIA overlaps with the risk assessments NIS2 and DORA already demand, so an organisation in scope of more than one regime builds one coherent process rather than three. For the broader picture, start with GDPR, NIS2 and DORA: How the Three EU Regimes Intersect.

This is not legal advice. National data protection authorities publish their own DPIA lists, and the proposed Digital Omnibus would harmonise DPIA practice — both noted below.

What a DPIA is

A Data Protection Impact Assessment, governed by GDPR Article 35, is an assessment of the impact of envisaged processing operations on the protection of personal data. It is conducted before the processing begins — it is a forward-looking instrument, not a post-incident review.

The DPIA is also an expression of the GDPR's accountability principle. It produces a documented record showing the controller identified the risks to individuals, assessed them, and decided how to mitigate them. If a regulator later asks why a particular processing activity was designed the way it was, the DPIA is the answer.

When a DPIA is mandatory

This is where most organisations go wrong — either running a DPIA for everything (wasteful) or for nothing (non-compliant). Article 35(1) sets the trigger: a DPIA is required where processing is likely to result in a high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context, and purposes of the processing.

Article 35(3) gives three specific cases where a DPIA is always required:

1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based
2. Large-scale processing of special categories of data (health, biometric, racial or ethnic origin, political opinions, and the other Article 9 categories) or of personal data relating to criminal convictions and offences
3. Systematic monitoring of a publicly accessible area on a large scale

Beyond those three, the European Data Protection Board has published nine criteria; the working guidance is that processing meeting two or more of the EDPB criteria likely requires a DPIA. The criteria include evaluation or scoring, automated decision-making with significant effect, systematic monitoring, sensitive data, large-scale processing, matching or combining datasets, data concerning vulnerable subjects, innovative use of technology, and processing that prevents data subjects from exercising a right or using a service.

National data protection authorities additionally publish mandatory DPIA lists (and, in some cases, lists of processing that does not require a DPIA). These lists are jurisdiction-specific and must be checked — what triggers a mandatory DPIA in one member state may not in another.

Cross-functional from the start. Photo: Austin Distel / Unsplash.

How to run a DPIA

Article 35(7) sets the minimum content. A DPIA must contain:

1. A systematic description of the envisaged processing operations and the purposes, including, where applicable, the legitimate interest pursued
2. An assessment of the necessity and proportionality of the processing in relation to the purposes
3. An assessment of the risks to the rights and freedoms of data subjects
4. The measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and demonstrate compliance

A workable process:

• Describe the processing. What data, whose data, for what purpose, by what means, shared with whom, retained how long. Map the data flow.
• Assess necessity and proportionality. Is the processing actually needed for the purpose? Could the purpose be achieved with less data, or less intrusive means? This is the step organisations most often skip — and the one regulators most often probe.
• Identify and assess risks to individuals. Not risks to the organisation — risks to the people. Identity theft, discrimination, financial loss, reputational harm, loss of control over personal data, distress. Rate likelihood and severity.
• Identify mitigations. Technical and organisational measures that reduce the risks. Encryption, minimisation, access control, retention limits, transparency measures.
• Consult the DPO. Where the organisation has a Data Protection Officer, Article 35(2) requires their advice to be sought.
• Document the residual risk and the decision. After mitigation, what risk remains, and is it acceptable?

Prior consultation

If, after mitigation, the DPIA indicates the processing would still result in a high residual risk, Article 36 requires the controller to consult the supervisory authority before starting the processing. Prior consultation is uncommon — it signals that the controller could not bring the risk down to an acceptable level on its own — but it is a legal obligation where the high residual risk remains.

One assessment, three regimes. Photo: Nick Morrison / Unsplash.

Where the DPIA meets NIS2 and DORA risk assessment

Here is the part that turns the DPIA from an isolated GDPR chore into a component of a coherent multi-regime programme.

NIS2 requires risk analysis as the first of its Article 21 measures — see NIS2 Article 21: All 10 Risk Management Measures Explained. DORA requires ICT risk identification and annual risk assessment under Pillar 1 — see DORA ICT Risk Management Framework Explained. The GDPR requires the DPIA for high-risk processing. Three regimes, three risk-assessment obligations.

They are not the same assessment — and conflating them entirely is a mistake — but they share enough that they should be designed as one connected process.

What they share

All three are structured risk assessments: identify the asset or activity, identify the threats, assess likelihood and impact, identify mitigations, document residual risk. The methodology — ISO 27005-style risk assessment — is identical. An organisation that has a single, well-built risk assessment methodology can run all three through it.

Where they genuinely differ

The difference is the risk lens — whose risk is being assessed:

• GDPR DPIA assesses risk to the rights and freedoms of individuals. The harm is to the data subject — identity theft, discrimination, distress.
• NIS2 risk analysis assesses risk to the security and continuity of services. The harm is operational disruption.
• DORA risk assessment assesses risk to operational resilience. The harm is to the entity's and the system's resilience.

The same processing activity — say, a new customer-analytics platform — is assessed three ways. The DPIA asks how badly it could go for the customers. The NIS2 analysis asks how badly its compromise would disrupt services. The DORA assessment asks how it affects operational resilience.

Building it as one process

The efficient model: one risk assessment methodology, one risk register, three lenses applied deliberately.

When a new processing activity or system is assessed, run it through the single methodology — but apply each relevant lens explicitly and record each. The output is one assessment document with three clearly labelled risk perspectives, satisfying the DPIA where the activity is high-risk processing, the NIS2 risk analysis where NIS2 applies, and the DORA assessment where DORA applies.

This is more efficient than three parallel assessments — and, importantly, it surfaces interactions. A security control added for NIS2 reasons may reduce the DPIA's residual risk to individuals; a data-minimisation decision made for GDPR reasons may reduce the NIS2 attack surface. One connected process sees these interactions; three siloed assessments do not.

The one caution: the DPIA's individual-harm lens must not be lost in the merge. It is the easiest of the three to under-weight, because organisational risk thinking naturally gravitates to organisational harm. The DPIA exists specifically to force attention onto the people. Keep that lens distinct and explicit even inside a unified process.

The Digital Omnibus on DPIAs

The proposed Digital Omnibus would harmonise DPIA practice at EU level — introducing EU-wide lists of processing operations that do, and do not, require a DPIA, plus a common template and methodology, subject to periodic review. If adopted, this would reduce the current fragmentation of national DPIA lists. It is a proposal, not law; see Report Once, Share Many: What the Digital Omnibus Actually Changes.

Common pitfalls

1. Running a DPIA for everything. The trigger is high-risk processing. Routine, low-risk processing does not need a DPIA — running one anyway wastes effort and dilutes attention from the processing that genuinely needs it.
2. Running a DPIA for nothing. The opposite error. Large-scale special-category processing, systematic profiling with significant effects, and large-scale public monitoring always need one.
3. Skipping the necessity and proportionality step. Jumping straight to "what security measures will we apply" without asking whether the processing is necessary at all. Regulators probe this.
4. Assessing organisational risk instead of individual risk. The DPIA is about harm to people. An assessment that only considers harm to the organisation has missed the point.
5. Treating the DPIA as a one-time document. Article 35(11) expects review where the risk changes. A DPIA for a system that has materially changed is out of date.
6. Running it after the processing starts. The DPIA is a prior assessment. Conducting it retrospectively defeats its purpose and is non-compliant for processing that required one.

Frequently asked questions

Is a DPIA mandatory for every processing activity? No. It is mandatory only for processing likely to result in a high risk to individuals — including the three always-required cases in Article 35(3) and processing meeting two or more EDPB criteria.

Who should conduct the DPIA? The controller is responsible. Where a DPO exists, their advice must be sought (Article 35(2)). In practice the DPIA is often run by the project owner with DPO and security input.

Can a DPIA cover several similar processing operations? Yes. Article 35(1) allows a single DPIA to address a set of similar processing operations presenting similar high risks.

What's the difference between a DPIA and a NIS2 risk assessment? The methodology is similar; the lens differs. A DPIA assesses risk to individuals' rights; a NIS2 risk analysis assesses risk to service security and continuity. Build one process, apply both lenses.

What happens if the residual risk is still high after the DPIA? Article 36 requires prior consultation with the supervisory authority before the processing begins.

Do I need a DPIA for processing that started before GDPR? Not automatically, but if such processing is high-risk and materially changes, a DPIA becomes appropriate. Authorities expect long-running high-risk processing to be assessed.

The bottom line

Three takeaways:

1. The DPIA trigger is high-risk processing — not all processing. Know the three always-required cases and the two-or-more-criteria rule.
2. Necessity and proportionality is the step that matters most. Ask whether the processing should happen at all, not just how to secure it.
3. Build one risk process, apply three lenses. The DPIA, the NIS2 risk analysis, and the DORA assessment share a methodology — but the DPIA's individual-harm lens must stay distinct and explicit.

For how the three regimes intersect across more than risk assessment, see GDPR, NIS2 and DORA: How the Three EU Regimes Intersect.

---

Sources & further reading

• Regulation (EU) 2016/679 — GDPR — Article 35 (DPIA), Article 36 (prior consultation)
• European Data Protection Board (EDPB) — Guidelines on Data Protection Impact Assessment and the nine DPIA criteria
• National data protection authority DPIA lists (jurisdiction-specific — see your supervisory authority's site)
• Directive (EU) 2022/2555 — NIS2 — Article 21(2)(a) (risk analysis)
• Regulation (EU) 2022/2554 — DORA — Article 8 (identification and risk assessment)
• European Commission — Digital Strategy: NIS2 directive — Digital Omnibus Package and DPIA harmonisation