How does Article 35 DPIA work?

What Article 35 is actually asking you to prove

Article 35 is not a paperwork exercise. It asks whether the proposed processing creates a high enough privacy risk that you must stop and assess it before launch, rather than discovering the problem after data collection has already begun. The practical question is whether the planned use of personal data is likely to create meaningful harm to people, not whether the project is technically complete.

A good DPIA starts with a clear description of the processing itself: what data is collected, why it is collected, who receives it, how long it is kept, and where it flows. That description matters because Article 35 is built around context. A processing activity that looks ordinary in isolation can become risky when it is large scale, combines datasets, uses profiling, or changes the expected relationship with the individuals involved.

The strongest way to read the requirement is through an evidential lens: you are building a reasoned assessment of necessity, proportionality, and privacy risk. A useful reference point for the overall Article 35 workflow is EU General Data Protection Regulation (GDPR), while a practical walkthrough of screening, risk scoring, mitigation, and review is set out in DPIA Guide: Running a Data Protection Impact Assessment.

How the assessment should be structured

In practice, the DPIA has four jobs. First, it describes the planned processing in enough detail that someone else can understand the data lifecycle and trust boundaries. Second, it tests necessity and proportionality, which means asking whether the goal can be achieved with less data, less retention, fewer recipients, or a less intrusive design. Third, it identifies the specific risks to individuals, including loss of control, unfair treatment, exclusion, surveillance, or exposure of sensitive data. Fourth, it records the measures that reduce those risks to an acceptable level.

The assessment works best when it is tied to the actual architecture and operating model, not written as a generic privacy statement. If the processing involves identity data, consent, or delegated access, the privacy risk often depends on how those data are minimised, retained, and shared, which is why Identity Data Privacy and Consent Guide is a useful companion for the data handling side of the assessment. If the work sits inside a broader programme rather than a one-off project, Privacy Programme Guide for Security Teams helps connect DPIA findings to governance, roles, and control ownership.

A DPIA is also a decision record. It should show why the chosen control set is proportionate to the risk, not merely list controls that sound reassuring. If the result is “high risk but acceptable after mitigation,” the logic should be explicit enough that a reviewer can follow it and challenge it. The DPIA Template is useful because it forces that discipline into a repeatable structure.

When you need to revisit it, and when the authority gets involved

A DPIA is not frozen at sign-off. It should be revisited when the processing changes in a way that alters the risk profile, such as a new data source, a broader population, a new purpose, a new recipient, a new retention model, or a change in analytics or automation. If the risk picture changes, the old assessment can quickly become misleading even if the original launch was well controlled.

If the assessment still leaves residual high risk after mitigation, the Article 35 process does not end with an internal approval. That is the point at which prior consultation becomes necessary, because the supervisory authority needs to review whether the organisation has identified the risk correctly and whether the proposed safeguards are sufficient. The practical test is simple: if you cannot reasonably explain how the remaining risk to individuals is being reduced, the DPIA is not complete enough to rely on.

That is why review discipline matters as much as the initial write-up. A privacy programme that treats DPIAs as one-time approvals will miss the operational reality that processing drifts over time. Privacy Programme Maturity Model is helpful here because it frames DPIA review as part of a broader capability, not a standalone document archive.

Risk and Threat Considerations

A weak DPIA usually fails in one of three ways: it understates the actual data flows, it softens the risk to individuals, or it records mitigations that are too vague to change the outcome. That creates exposure to both regulatory challenge and avoidable harm, especially where the processing is large scale, opaque, or hard to reverse once deployed.

Failure mechanism: The organisation treats the DPIA as a formality, so the assessment does not capture the true scale, purpose change, sharing model, or residual harm. When the real processing diverges from the paper assessment, the mitigation choices no longer match the risk.

Impact: Individuals can face unlawful or disproportionate processing, weaker control over their data, and higher exposure from downstream reuse or overcollection. The organisation also loses the evidential basis it needs to defend the decision if regulators ask why the processing was allowed to proceed.

Practitioner Guidance

What to prioritise: Start with the data flows and decision points that change the risk to individuals, not with template language. If you cannot explain who sees the data, why it is needed, and what would happen if the design changed, the DPIA is too shallow to trust.

What to verify: Confirm that the mitigation measures actually reduce the identified risks, rather than simply documenting existing controls. A useful DPIA can point to a decision, a control owner, and a review trigger, not just a list of intentions.

Practitioner takeaway: The value of Article 35 is not the form itself, it is the discipline of proving that high-risk processing was examined before launch, and that residual risk stays visible if the processing later changes.

Related resources from NHI Mgmt Group

• Article 35 DPIA
• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?