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.
§When Is a DPIA Required?
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:
- Nature of the processing
- Scope of the processing
- Context in which processing occurs
- Purposes of the processing
- Potential impact on individuals
- Likelihood and severity of risks
Article 35(3): Three Express Examples
A DPIA is specifically required in particular where processing involves:
- Systematic and extensive evaluation of personal aspects, including profiling, where decisions based on the processing produce legal effects or similarly significant effects.
- Large-scale processing of special categories of personal data under Article 9(1), or personal data relating to criminal convictions and offences under Article 10.
- Systematic monitoring of a publicly accessible area on a large scale.
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).
§The DPIA Threshold Test
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:
- Evaluation or scoring, including profiling
- Automated decision-making with legal or similarly significant effects
- Systematic monitoring
- Sensitive or highly personal data
- Large-scale processing
- Matching or combining datasets
- Processing involving vulnerable individuals
- Innovative technology or organisational solutions
- Processing that prevents individuals from exercising a right, using a service, or entering into a contract
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.
Practical Screening Questions
Ask:
- Does the processing evaluate or profile individuals?
- Could automated decisions significantly affect individuals?
- Are individuals systematically monitored?
- Does the processing involve sensitive or highly personal information?
- Is processing conducted on a large scale?
- Are datasets from different sources being combined?
- Are vulnerable individuals affected?
- Does the processing introduce innovative technology or methods?
- Could the processing restrict an individual's ability to exercise a right or access a service?
If several indicators are present, a documented DPIA threshold assessment is strongly advisable.
§Stage 1 — Describe the Processing
The first stage is to document what the organisation intends to do with personal data.
A useful DPIA should describe:
Nature
- Categories of personal data
- Sources of data
- Data recipients
- Controllers, joint controllers, processors and sub-processors
- Processing operations
- Security measures
- International transfers
- Retention and deletion arrangements
Scope
- Number of individuals affected
- Volume of data
- Geographic coverage
- Duration of processing
- Frequency of processing
Context
Consider:
- The relationship between the organisation and individuals
- Individuals' expectations
- Whether individuals have meaningful control
- The sensitivity of the environment
- Whether vulnerable individuals are involved
- Whether the processing could affect employment, healthcare, finance, education, or other important aspects of life
Purpose
Document:
- What the organisation wants to achieve
- Why the processing is necessary
- Expected outcomes
- Business or operational objectives
Data Flow Mapping
Where appropriate, supplement the written description with a data-flow diagram showing:
- Collection
- Processing
- Storage
- Access
- Sharing
- Transfer
- Deletion
This can reveal data flows and third parties that may not be obvious from narrative documentation alone.
§Stage 2 — Necessity and Proportionality
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.
Legal Basis
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.
Data Minimisation
For each significant data element, ask:
- Do we actually need this information?
- Can the same objective be achieved with less data?
- Can information be aggregated or anonymised?
- Can identifiers be removed or pseudonymised?
Retention
Document:
- How long data will be retained
- Why the period is necessary
- What triggers deletion or review
- How deletion is enforced
Purpose Limitation
Confirm that each category of data is connected to a defined and legitimate purpose.
Accuracy
Identify controls for:
- Maintaining accurate information
- Correcting inaccurate records
- Handling outdated information
Transparency and Rights
Explain:
- How individuals will be informed
- Which rights apply
- How rights requests will be handled
- How individuals can raise concerns
Less Intrusive Alternatives
A strong DPIA should document alternatives considered and explain why the selected approach is proportionate.
§Stage 3 — Identify and Assess Risks
The DPIA should focus on risks to individuals' rights and freedoms, rather than simply listing cybersecurity vulnerabilities.
For each material risk, document:
- Risk description
- Cause or threat
- Categories of affected individuals
- Potential consequences
- Likelihood
- Severity
- Overall risk assessment
- Existing safeguards
- Residual risk
Common Risk Areas
Depending on the processing, consider:
- Unauthorised access
- Loss of confidentiality
- Loss or alteration of data
- Excessive collection
- Excessive retention
- Unlawful disclosure
- Identity theft
- Fraud
- Discrimination
- Profiling
- Loss of autonomy
- Reputational harm
- Financial harm
- Physical or psychological harm
- Re-identification
- Inability to exercise data-subject rights
Likelihood and Severity
Consider both:
- How likely is the harm to occur?
- How serious would the consequences be if it occurred?
The assessment should be understandable enough that another reviewer can follow how the organisation reached its conclusion.
§Stage 4 — Risk Treatment
Once risks have been identified, determine what safeguards are required.
Potential measures include:
Technical Measures
- Encryption
- Pseudonymisation
- Access controls
- Multi-factor authentication
- Network segmentation
- Logging and monitoring
- Data-loss prevention
- Secure deletion
- Vulnerability management
Organisational Measures
- Privacy policies
- Staff training
- Access governance
- Retention schedules
- Incident-response procedures
- Vendor controls
- Data-protection agreements
- Internal audits
- Periodic reviews
Privacy-by-Design Measures
Consider whether the system can be redesigned to:
- Collect less information
- Reduce access
- Shorten retention
- Remove unnecessary identifiers
- Process information locally
- Aggregate information
- Give individuals greater control
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.
§Residual Risk and Prior Consultation
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:
- Responsibilities of the parties involved
- Purposes and means of processing
- Measures and safeguards
- DPO contact details, where applicable
- The DPIA
- Other information requested by the authority
§Stage 5 — Approval and Review
A DPIA should have clear ownership and approval.
DPO Involvement
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.
Stakeholder Review
Depending on the processing, involve:
- Privacy
- Legal
- Security
- Engineering
- Product
- Compliance
- Procurement
- HR
- Business owners
- Relevant processors
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.
Approval
Record:
- DPIA owner
- Date completed
- Processing owner
- DPO advice, where applicable
- Identified risks
- Required controls
- Residual risks
- Approval decision
- Outstanding actions
- Review triggers
§When Should a DPIA Be Reviewed?
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:
- The processing purpose changes
- New categories of data are introduced
- Processing volume increases materially
- A new technology is introduced
- A new processor is appointed
- The geographic scope changes
- New jurisdictions are added
- A security incident occurs
- A new vulnerability or risk emerges
- Regulatory requirements change
- The system is materially redesigned
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.
§Worked Example — Employee Biometric Attendance System
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:
Processing
- What biometric information is collected?
- How is it generated and stored?
- Is a template stored instead of a raw image?
- Who can access the information?
- How long is it retained?
- Are vendors involved?
- Are data transfers involved?
Purpose
- Is the system being used solely for attendance?
- Is it also used for employee monitoring or performance assessment?
- Could it affect employment decisions?
Necessity and proportionality
Consider whether less intrusive alternatives could achieve the same objective, such as:
- Access cards
- PINs
- Mobile authentication
- Other non-biometric attendance methods
Risk
Assess potential consequences such as:
- Irreversible compromise of biometric identifiers
- Unauthorised access
- Function creep
- Employee monitoring
- Discrimination or inaccurate matching
- Excessive retention
- Loss of control over sensitive information
Safeguards
Potential controls could include:
- Template-based storage
- Strong encryption
- Strict access controls
- Short retention periods
- Purpose limitation
- Alternative attendance mechanisms
- Accuracy testing
- Human review of disputed matches
- Vendor restrictions
- Incident-response procedures
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.
§Common DPIA Mistakes
Mistake 1: "Two criteria means a DPIA is mandatory."
The nine criteria are a practical risk-screening framework, not a statutory numerical formula.
Mistake 2: Starting the DPIA after launch
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.
Mistake 3: Treating the DPIA as a cybersecurity assessment
Security is important, but the DPIA must assess risks to individuals' rights and freedoms.
Mistake 4: Using generic risk descriptions
A strong DPIA connects risks to actual individuals, data, processing operations, and potential consequences.
Mistake 5: Assuming every biometric or AI project has the same legal basis
The legal basis and special-category condition depend on the actual processing and applicable law.
Mistake 6: Treating the DPO as the person who "owns" the DPIA
The controller remains responsible for the DPIA. A designated DPO provides advice under Article 35(2).
Mistake 7: Automatically consulting the supervisory authority
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.
Mistake 8: Never revisiting the DPIA
Material changes to processing or its risk profile should trigger reassessment.
§DPIA Deliverables Checklist
A practical DPIA file should normally contain, as applicable:
- DPIA threshold assessment
- Processing description
- Data-flow diagram
- Purpose and legal-basis analysis
- Necessity and proportionality assessment
- Data-minimisation assessment
- Risk register
- Risk methodology
- Existing safeguards
- Additional mitigation measures
- Residual-risk assessment
- DPO advice, where applicable
- Stakeholder input
- Approval record
- Remediation plan
- Review triggers
- Prior-consultation documentation, where applicable
§DPIA vs Other Assessments
A DPIA is often part of a wider governance process.
DPIA vs Security Risk Assessment
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.
DPIA vs Legitimate Interest Assessment
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.
DPIA vs AI Fundamental Rights Impact Assessment
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.
§EDPB DPIA Template
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.
§Frequently Asked Questions
Is a DPIA always required for AI?
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.
Is a DPIA mandatory for biometric data?
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.
Can one DPIA cover multiple processing activities?
Yes. Article 35 allows a single assessment to address a set of similar processing operations presenting similar high risks.
Can a DPIA be completed after processing begins?
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.
Does every DPIA require DPO approval?
No. Where a DPO has been designated, the controller must seek the DPO's advice. The controller remains responsible for the assessment and decision.
Does every DPIA require supervisory-authority consultation?
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.
Does every DPIA need to be published?
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.
How often should a DPIA be reviewed?
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.
Build a DPIA That Supports Real Decisions
A DPIA should help the organisation make better decisions about how personal data is collected, used, secured, retained, and shared.
The most effective DPIAs:
- Start early
- Involve the right stakeholders
- Focus on individuals' rights and freedoms
- Evaluate necessity and proportionality
- Identify concrete risks
- Assign practical safeguards
- Document residual risk
- Record decisions and accountability
- Are revisited when processing or risk changes
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.