A Data Protection Impact Assessment helps an organisation identify privacy risks before a project, system or processing activity goes live. This DPIA UK GDPR guide explains when an assessment is legally required, how to complete one and when unresolved risks must be referred to the Information Commissioner’s Office.
Article 35 contains the central DPIA requirement. UK GDPR must be read alongside the Data Protection Act 2018 and amendments made by the Data (Use and Access) Act 2025. In 2026, the ICO continues to treat DPIAs as a core accountability and data protection by design measure, although parts of its guidance are under review.
What Is a DPIA?
A DPIA is a structured process for analysing how proposed processing may affect people and for identifying measures that reduce those risks. It is not simply a compliance form completed after a project has already been approved.
A good assessment explains what personal data will be used, tests whether the processing is necessary and proportionate, identifies possible harm, compares less intrusive alternatives and records safeguards. Its purpose is not to eliminate every conceivable risk, but to reduce risk and determine whether the remainder is acceptable.
The ICO describes DPIAs as flexible and scalable. The depth of analysis should reflect the proposed processing and help the organisation apply data protection by design before the service is launched.
DPOs who want broader context on responsibility, independence and oversight can read our DPO role explained.
When Is a DPIA Required Under UK GDPR?
Article 35 requires a controller to complete a DPIA before processing where the proposed activity is likely to result in a high risk to people’s rights and freedoms. The decision must take account of the nature, scope, context and purposes of the processing.
Article 35(3) identifies three types of processing that require a DPIA:
- Systematic and extensive evaluation or profiling used to make decisions producing legal or similarly significant effects
- Large-scale processing of special category data or criminal offence data
- Systematic monitoring of a publicly accessible area on a large scale
The ICO also maintains a list of additional processing operations likely to result in high risk. These include certain uses of innovative technology, denial of access to services, large-scale profiling, biometric or genetic data, data matching, invisible processing, tracking and processing that could create a risk of physical harm.
Some categories automatically require a DPIA, while others trigger the requirement when combined with another risk criterion.
Examples include facial recognition, large-scale employee monitoring, AI-based applicant assessment, large-scale health-data processing, location tracking and services involving children.
If a project does not fall clearly within a mandatory category, the organisation must still consider whether its features make high risk likely. Where there is doubt, completing an assessment is usually the safer and more accountable approach.
If screening concludes that no DPIA is needed, record the decision and reasoning, including relevant DPO advice.
The ICO's High-Risk Processing Screening Checklist
A screening checklist is the practical first stage of deciding when a DPIA is required. It should be built into procurement, project initiation, product development and change-management processes rather than left until final approval.
The ICO’s screening approach considers indicators such as:
- Evaluation or scoring
- Automated decision-making with significant effects
- Systematic monitoring
- Sensitive or highly personal information
- Large-scale processing
- Matching or combining datasets
- Information about vulnerable individuals
- Innovative technology or new organisational solutions
- Processing that prevents people from exercising a right or accessing a service
A combination of two indicators will often suggest that a DPIA is necessary, although this is not an inflexible rule. One factor may be enough where its effect could be particularly serious, while an organisation may occasionally justify why a combination does not create likely high risk. The reasoning should always be documented.
A practical DPIA checklist UK should ask whether the project:
- Introduces new ways of collecting, sharing or analysing personal data
- Handles special category, biometric or criminal offence information
- Makes decisions that significantly affect individuals
- Monitors, scores, profiles or tracks people
- Combines information from unexpected sources
- Involves children, employees, patients or other vulnerable groups
- Could cause serious financial, physical or psychological harm
Record the project owner, screening decision, evidence considered, DPO advice and review date. This provides an auditable record for a wider GDPR compliance checklist UK organisations can use to support GDPR readiness and audit preparation.
How to Carry Out a DPIA — Step by Step
For teams asking how to do a DPIA, the ICO DPIA guidance sets out seven broad stages: identify the need, describe the processing, consider consultation, assess necessity and proportionality, identify risks, identify mitigating measures, and sign off and record the outcome.
The results should then be incorporated into the project plan and kept under review. Organisations may use an ICO-style DPIA template UK format or develop their own template, provided it covers the required elements.
Describing the Processing
Begin by documenting what the organisation plans to do in language that both technical and non-technical reviewers can understand.
Describe:
- The purpose and expected outcome
- The people affected
- Categories and sources of personal data
- Collection, use, storage, sharing and deletion
- Systems, suppliers and processors involved
- Data locations and international transfers
- Processing scale and duration
- Automated decisions, profiling or monitoring
A data-flow diagram may help teams understand where information enters the organisation, who can access it, where it is transferred and when it will be deleted.
Avoid vague aims such as “improving customer experience”. Explain whether the system analyses conversations, generates risk scores, monitors behaviour or recommends decisions.
Consult relevant stakeholders where appropriate. This could include affected individuals, staff representatives, processors, security specialists and operational teams. Where consultation is not suitable, record the reason.
Assessing Necessity and Proportionality
The next step is to establish whether the processing is genuinely needed to achieve the stated purpose. A system being useful or commercially attractive does not automatically make every element of its processing necessary.
Consider whether:
- The same outcome could be achieved with less personal data
- Anonymous or pseudonymous information would be sufficient
- The lawful basis is appropriate
- Privacy information will be clear and accessible
- Data will remain accurate and relevant
- Retention periods are justified
- Individuals can exercise their rights
- Processors and international transfers are properly controlled
- The expected benefits justify the level of privacy intrusion
This stage should challenge the project rather than simply validate it. Removing an unnecessary dataset, changing a default setting or reducing monitoring may be more effective than adding paperwork after the design is complete.
Identifying and Assessing Risks
A DPIA assesses risks to people, not only financial, operational or regulatory risks to the organisation.
Possible harms include:
- Identity fraud or financial loss
- Discrimination or unfair exclusion
- Loss of confidentiality
- Inaccurate or unfair decisions
- Unwanted surveillance
- Distress or reputational damage
- Loss of control over personal information
- Exclusion from employment, credit or essential services
- Physical harm in safety-critical settings
For each risk, assess both its likelihood and potential severity. Record who may be affected, how the harm could occur, existing controls and the initial risk rating.
A consistent scoring method can help teams compare risks across projects. However, numerical scores should support, rather than replace, informed professional judgement.
Identifying Mitigating Measures
Choose controls that reduce either the likelihood of harm, its severity or both. Each action should have an owner, implementation deadline and method of verification.
Measures may include:
- Collecting fewer data fields
- Shortening retention periods
- Encrypting information
- Applying role-based access controls
- Pseudonymising identifiable information
- Introducing meaningful human review
- Testing for bias, accuracy and security
- Improving privacy notices
- Strengthening supplier contracts
- Creating objection and appeal routes
- Removing a high-risk feature
Re-score each risk after mitigation. The final DPIA should state whether the processing is approved, approved subject to conditions, redesigned, paused or rejected.
An authorised decision-maker should sign off the assessment. Any decision not to follow the DPO’s advice should be recorded and justified.
A DPIA remains a living document. Review it when the purpose, technology, data sources, supplier arrangements, processing scale or risk profile changes, and confirm that promised safeguards were actually implemented. The ICO expects DPIA outcomes to feed back into the project plan and remain under ongoing review.
For practical support with these data protection impact assessment steps, explore Technical project teams can also streng GDPR training for Data Protection Officers.then their governance through IT Compliance & GDPR for Tech Teams and our wider IT compliance guide.
When to Consult the ICO
Completing a DPIA does not mean it must automatically be submitted to the ICO. Prior consultation is required only when the assessment identifies a high residual risk that the organisation cannot sufficiently reduce.
Residual risk means the risk remaining after all realistic safeguards have been considered. If the original risk was high but effective controls reduce it below that level, prior consultation is not required.
If the risk remains high, the organisation must consult the ICO before starting the processing.
A prior-consultation submission should include:
- The purposes and methods of the intended processing
- Controller, joint-controller and processor responsibilities
- Measures designed to protect individuals
- The completed DPIA
- The DPO’s contact details, where applicable
- Any supporting information needed to understand the project
The ICO states that it normally provides advice within eight weeks after accepting a complete DPIA for prior consultation, although the process may take longer in complex cases. The organisation must not begin the high-risk processing while consultation is outstanding.
Consultation is not a way to transfer responsibility to the regulator. The organisation must first conduct a credible assessment, explore alternatives and make genuine efforts to reduce the risks.
Who Should Be Involved in a DPIA?
The controller remains accountable for ensuring that a required DPIA is completed, even if a consultant, processor or supplier prepares part of it. An organisation can decide which role manages the assessment and who signs it off, but ownership must be clear.
A multidisciplinary team may include:
- The business or project owner
- The DPO or privacy lead
- IT and information security specialists
- Legal and compliance teams
- Procurement and supplier managers
- HR or operational teams
- Processors and technology suppliers
- Representatives of affected individuals
Where a DPO is appointed, the organisation must seek and document their advice. The DPO advises on whether and how to complete the assessment, suitable safeguards, the quality of the DPIA and whether the processing should proceed.
The DPO monitors the process but should not become the project decision-maker, as this could undermine the independence of the role.
Developing this capability across privacy teams is a central part of effective DPO training UK. The aim is not to make one person complete every assessment, but to ensure that project teams receive competent, independent advice at the correct stage.
DPIA Training for Your Team
DPIA failures often begin before the assessment itself. A project team may not recognise a trigger, procurement may sign a contract too early or developers may treat privacy review as a final-stage approval.
Training should cover:
- Personal and special category data
- High-risk processing triggers
- DPIA screening procedures
- Data-flow descriptions
- Risks to individuals
- Necessity and proportionality
- Technical and organisational safeguards
- Recording and approving mitigations
- Events that require a DPIA review
Build screening questions into project forms, procurement gates and change requests. Staff should understand that a DPIA begins during planning, not shortly before launch.
ICO accountability guidance recommends early-stage awareness, documented procedures and appropriate training for staff who screen projects or carry out assessments.
Use practical exercises based on realistic projects, such as employee monitoring, CRM migration, AI-assisted recruitment or biometric access. This helps operational teams move beyond definitions and practise identifying risks, alternatives and safeguards.
FAQs
When is a DPIA legally required under UK GDPR?
A DPIA is required before processing that is likely to result in a high risk to individuals’ rights and freedoms. Article 35 identifies mandatory cases, while the ICO’s high-risk list and screening criteria cover additional activities.
Who is responsible for completing a DPIA?
The controller remains accountable for ensuring the DPIA is completed and properly approved, even where the work is delegated or outsourced. If the organisation has a DPO, it must seek and record the DPO’s independent advice.
What happens if I skip a required DPIA?
The organisation may breach Article 35, overlook serious risks and face ICO enforcement action. It may also struggle to demonstrate accountability or data protection by design if the project causes harm or is challenged.
Do I need to consult the ICO after a DPIA?
Not in every case. Prior consultation is required only where a high risk remains after reasonable mitigating measures have been applied, and the processing must not begin until the ICO has been consulted.
How long does a DPIA take to complete?
There is no fixed duration. A focused project may require a relatively short assessment, while novel, sensitive or large-scale processing may require extensive technical work, consultation and redesign. The time and resources used should be proportionate to the project’s risks.
Master practical DPIA work. Build practical DPIA skills across your team by exploring our GDPR Training for Data Protection Officers course.
