Art.35 GDPR

GDPR Art.35: Data Protection Impact Assessment

What This Control Requires

Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.

In Plain Language

Before you launch any processing that could pose a high risk to individuals, you need to carry out a Data Protection Impact Assessment (DPIA). Think of it as a structured way to identify privacy risks, evaluate them honestly, and design mitigations before you go live - not after. DPIAs are especially important when deploying new technologies or handling large-scale or sensitive data.

Three situations always require a DPIA: systematic profiling that produces legal or similarly significant effects on people, large-scale processing of special category or criminal conviction data, and large-scale systematic monitoring of publicly accessible areas. Your supervisory authority will also publish lists of processing types that trigger the requirement, so check those.

At a minimum, the DPIA must include a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an evaluation of risks to individuals, and the safeguards and security measures you plan to put in place. Involve your DPO in the process, and where appropriate seek the views of affected data subjects or their representatives.

How to Implement

Define clear criteria for when a DPIA is needed. Start with the Article 35(3) mandatory triggers, add your supervisory authority's published list, and apply the EDPB's nine criteria for high-risk processing: evaluation or scoring, automated decision-making with legal effect, systematic monitoring, sensitive data, large scale, dataset matching or combining, vulnerable data subjects, innovative technology use, and cross-border transfers. If your processing hits two or more of these, you almost certainly need a DPIA.

Create a DPIA methodology and reusable template. Cover a systematic description of the processing (purpose, scope, data flows, technology), an assessment of necessity and proportionality (is there a less intrusive way to achieve the same goal?), identification and scoring of risks to data subjects (likelihood and severity), measures to mitigate those risks (technical, organisational, legal), and a clear conclusion on residual risk and whether processing can proceed.

Embed the DPIA process into your project management and change management workflows. Require a screening assessment at the start of any project involving personal data. If screening flags potential high risk, make a full DPIA a mandatory gate before implementation can proceed. Do not let projects reach production without this step.

Bring your DPO in early, as Article 35(2) requires. They should advise on whether a DPIA is needed, which methodology to use, and whether the proposed safeguards are adequate. Where the processing will significantly affect particular groups, seek their views too. Document every consultation and how you incorporated the feedback.

If the DPIA reveals high residual risk that you cannot mitigate sufficiently, you must consult the supervisory authority under Article 36 before going ahead. Treat DPIAs as living documents - review and update them whenever the nature, scope, context, or purposes of processing change, when new risks emerge, or when the processing environment shifts significantly.

Evidence Your Auditor Will Request

DPIA screening criteria and threshold assessment procedure
DPIA methodology and template documentation
Completed DPIAs for all processing activities meeting the threshold
Evidence of DPO consultation during DPIA process
Records of DPIA reviews and updates following changes in processing

Common Mistakes

DPIAs not conducted for processing that clearly meets the high-risk threshold
DPIAs conducted as a retrospective documentation exercise rather than a genuine risk assessment before processing begins
DPIA methodology that does not adequately assess risks to data subjects' rights and freedoms
DPO not consulted during the DPIA process as required
DPIAs treated as one-time documents and never reviewed when processing changes

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.34	Related
NIS2	Art.21.2a	Partial overlap

Frequently Asked Questions

When is a DPIA mandatory?

Whenever processing is likely to result in a high risk to individuals. The three automatic triggers are systematic profiling with legal or significant effects, large-scale special category data processing, and large-scale systematic monitoring of public areas. Beyond those, check your supervisory authority's published list and the EDPB's nine criteria. When you are on the fence, just do the DPIA - it is good practice regardless.

Can we proceed with processing if the DPIA identifies high residual risk?

Not without consulting your supervisory authority first, under Article 36. They may suggest additional safeguards, impose conditions, or block the processing entirely. Never press ahead with high-residual-risk processing without that prior consultation.

Do we need a DPIA for existing processing activities?

The GDPR does not explicitly mandate retrospective DPIAs, but the EDPB strongly recommends them for existing high-risk processing. In practice, regulators expect them. And any time you make a significant change to existing processing, a DPIA becomes a firm requirement.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment