Loading…
Under GDPR Article 35, a DPIA should be completed before the relevant processing begins. It should be treated as a practical risk-management exercise that can influence product design, data collection, security controls, retention, access, and other processing decisions—not simply as a compliance document.
This guide provides a five-stage methodology for determining whether a DPIA is required, documenting the processing, assessing risks, selecting safeguards, and approving and reviewing the assessment.
Important: Whether a DPIA is required depends on the specific processing activity, its nature, scope, context and purposes, applicable supervisory-authority lists, and the risks to individuals. This guide provides general information and does not replace legal advice.
Article 35(1) requires a controller to carry out a DPIA where a type of processing, particularly processing involving new technologies, is likely to result in a high risk to the rights and freedoms of natural persons.
The assessment should consider:
A DPIA is specifically required in particular where processing involves:
These are not the only circumstances in which a DPIA may be required. Supervisory authorities also publish lists of processing operations that require a DPIA under Article 35(4).
Where it is not immediately clear whether a DPIA is required, organisations can use the established risk criteria developed by the Article 29 Working Party and endorsed by the EDPB.
The nine commonly used criteria are:
These criteria are useful indicators of potentially high-risk processing. They should not be treated as a statutory "two criteria = DPIA" formula.
The assessment must consider the processing as a whole and the applicable national supervisory-authority requirements. A processing activity may require a DPIA even if a simple numerical threshold is not met. Conversely, the presence of one factor does not automatically determine the outcome in every case.
Ask:
If several indicators are present, a documented DPIA threshold assessment is strongly advisable.
The first stage is to document what the organisation intends to do with personal data.
A useful DPIA should describe:
Consider:
Document:
Where appropriate, supplement the written description with a data-flow diagram showing:
This can reveal data flows and third parties that may not be obvious from narrative documentation alone.
A DPIA should not only ask whether processing is technically possible. It should assess whether the proposed processing is necessary and proportionate to its purpose.
Identify the relevant Article 6 legal basis.
Where special-category data is processed, identify the applicable Article 9 condition. Where criminal-conviction or offence data is involved, assess Article 10 and relevant national law.
For each significant data element, ask:
Document:
Confirm that each category of data is connected to a defined and legitimate purpose.
Identify controls for:
Explain:
A strong DPIA should document alternatives considered and explain why the selected approach is proportionate.
The DPIA should focus on risks to individuals' rights and freedoms, rather than simply listing cybersecurity vulnerabilities.
For each material risk, document:
Depending on the processing, consider:
Consider both:
The assessment should be understandable enough that another reviewer can follow how the organisation reached its conclusion.
Once risks have been identified, determine what safeguards are required.
Potential measures include:
Consider whether the system can be redesigned to:
The objective is not simply to reduce the risk score. The organisation should determine whether the safeguards reduce the likelihood or severity of risks sufficiently to make the processing appropriate.
After safeguards have been selected, reassess the remaining risk.
If the DPIA indicates that processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk, Article 36 requires prior consultation with the competent supervisory authority before processing begins.
Prior consultation is therefore not a routine step in every DPIA. It becomes relevant where the remaining circumstances meet the Article 36 threshold.
The controller should be prepared to provide the information required by Article 36, including:
A DPIA should have clear ownership and approval.
Where a DPO has been designated, the controller must seek the DPO's advice when carrying out the DPIA under Article 35(2).
The DPO's advice should be documented, including any decision by the controller to depart from that advice.
This does not mean that every organisation is required to appoint a DPO solely because it conducts a DPIA. The obligation to have a DPO is governed separately by Article 37.
Depending on the processing, involve:
Where appropriate, Article 35(9) also allows the controller to seek the views of data subjects or their representatives, subject to the conditions in that provision.
Record:
A DPIA is not necessarily a one-time document.
Article 35(11) requires the controller to carry out a review where necessary to assess whether processing is performed in accordance with the DPIA, at least when there is a change in the risk represented by the processing operations.
Review may therefore be appropriate when:
An organisation may also choose to conduct periodic reviews—for example annually—as a governance practice. But an annual review is not a universal Article 35 statutory deadline.
Consider an organisation proposing to deploy a biometric attendance system for employees across multiple facilities.
The organisation should not simply conclude that a DPIA is required because "biometrics always require a DPIA."
Instead, it should assess:
Consider whether less intrusive alternatives could achieve the same objective, such as:
Assess potential consequences such as:
Potential controls could include:
The legal basis and Article 9 condition should be determined based on the actual employment context and applicable national law. Consent should not be assumed to be an appropriate solution simply because it is convenient, particularly where there may be an imbalance between employer and employee.
The nine criteria are a practical risk-screening framework, not a statutory numerical formula.
Article 35 requires the assessment before the relevant high-risk processing begins. A DPIA should be early enough to influence the design and decision-making process.
Security is important, but the DPIA must assess risks to individuals' rights and freedoms.
A strong DPIA connects risks to actual individuals, data, processing operations, and potential consequences.
The legal basis and special-category condition depend on the actual processing and applicable law.
The controller remains responsible for the DPIA. A designated DPO provides advice under Article 35(2).
Article 36 prior consultation is triggered where the DPIA indicates that high risk would remain in the absence of mitigating measures. It is not required for every DPIA.
Material changes to processing or its risk profile should trigger reassessment.
A practical DPIA file should normally contain, as applicable:
A DPIA is often part of a wider governance process.
A security risk assessment focuses primarily on information-security threats and controls.
A DPIA focuses on risks to individuals' rights and freedoms arising from the processing of personal data.
The two assessments can inform one another but should not automatically be treated as the same document.
A Legitimate Interest Assessment evaluates whether processing based on legitimate interests satisfies the applicable legal requirements.
A DPIA addresses whether processing is likely to result in high risk to individuals' rights and freedoms.
A processing activity may require both.
An AI-related Fundamental Rights Impact Assessment under the EU AI Act is distinct from a GDPR DPIA. Where both are applicable, they can be coordinated and may share relevant factual information, but they address different legal frameworks.
The EDPB published a DPIA template for public consultation in April 2026. The template is intended to support a more consistent approach to DPIAs, with national data protection authorities expected to consider how it can be adopted as a common or compatible template.
Organisations can use the EDPB template as a useful reference while also checking the requirements and guidance of the relevant national supervisory authority.
No. The use of AI does not automatically mean that a DPIA is required. The organisation must assess the nature, scope, context and purposes of the processing and whether it is likely to result in high risk.
Not automatically in every circumstance. However, biometric processing can present significant risks and may also involve special-category data. The actual processing, purpose, scale and applicable supervisory-authority requirements must be assessed.
Yes. Article 35 allows a single assessment to address a set of similar processing operations presenting similar high risks.
The normal requirement is to complete the DPIA before the relevant processing begins. If an existing processing activity has changed or its risk profile has increased, the controller should assess whether a DPIA is now required or needs to be updated. A retrospective DPIA may help remediate an existing governance gap, but it does not erase an earlier failure to comply.
No. Where a DPO has been designated, the controller must seek the DPO's advice. The controller remains responsible for the assessment and decision.
No. Prior consultation under Article 36 is required where the DPIA indicates that processing would result in high risk in the absence of measures taken to mitigate that risk.
No. GDPR Article 35 does not impose a general requirement to publish the complete DPIA. Organisations may choose to publish a summary or other information where appropriate, subject to confidentiality, security, and other considerations.
There is no universal GDPR requirement for an annual DPIA review. Review when necessary and at least when the risk represented by the processing changes. Organisations may establish additional periodic review cycles as a governance measure.
A DPIA should help the organisation make better decisions about how personal data is collected, used, secured, retained, and shared.
The most effective DPIAs:
RegulatoryBridge can support organisations with DPIA threshold assessments, full DPIA preparation, stakeholder coordination, remediation planning, and regulatory consultation where Article 36 requirements are met.
Explore our GDPR compliance services or contact RegulatoryBridge to discuss your DPIA requirements.