What this review helps you do
A useful DPIA turns a proposed use of personal information into a recorded decision about risks to people. Start with screening, then connect each material risk to a practical control, an owner and evidence that the control works before the processing is approved.
AT A GLANCE
Identify risks to people before a project starts. Record why processing is necessary, how risks will be reduced and who accepts the remaining risk.
Who should use this review?
Project owners considering AI, monitoring, biometrics, profiling, data matching, sensitive records or large-scale processing.
What to review
- Screen the nature, scale, context and purpose of the proposal. Record why a DPIA is or is not required.
- Describe collection, use, sharing, retention and affected groups; test necessity, alternatives and proportionality.
- Assess likelihood and severity of harm to people, then document mitigations and residual risks.
- Seek DPO advice where appointed, consult relevant stakeholders where appropriate and record approval and review triggers.
Working outputs
- DPIA record ready for organisational review and sign-off.
- Risk and mitigation register with owners and review dates.
- Residual-risk decision and any required ICO consultation record.
PUT THIS GUIDE TO WORK
Review it. Record it. Keep the evidence.
Open the relevant assessment area or complete the matching working document.
Evidence checklist
Use these checks to gather references and identify the evidence that still needs testing.
Are new and changed projects screened before procurement or launch?
Evidence to look for: Screening record and project approval gate.
If it is missing: Introduce an early DPIA screening step.
Does each required DPIA assess necessity, proportionality and risks to individuals?
Evidence to look for: Completed assessment and alternatives considered.
If it is missing: Complete the missing risk analysis before processing starts.
Are mitigations owned, implemented and checked before approval?
Evidence to look for: Actions, tests, DPO advice and sign-off.
If it is missing: Assign and verify controls before authorising the project.
Is unresolved high residual risk escalated for prior ICO consultation?
Evidence to look for: Residual-risk decision and consultation record, if applicable.
If it is missing: Pause the proposed processing and obtain specialist advice on Article 36.
Apply the limits carefully
A new CRM, EHR or AI tool is a reason to screen; it is not automatically a statutory DPIA requirement in every case.
Some ICO list entries apply only alongside another specified risk criterion. High residual risk that cannot be reduced requires prior ICO consultation before processing begins.
Common misunderstandings
The need for a DPIA depends on the actual processing and the relevant legal criteria. Apply Article 35 and the ICO’s published list in full, including any conditions or required combinations of factors. A technology label by itself does not answer the screening question.
A completed browser worksheet records an assessment. Organisational approval, implementation of controls and any required prior ICO consultation remain separate steps.
Worked example: reviewing a proposed clinic triage tool
Illustrative scenario. This is a fictional teaching example, not a client case, professional finding or verified outcome.
A clinic is considering a supplier's appointment-triage tool. This fictional example demonstrates an evidence process; it does not determine whether any particular product is lawful.
- Control
The project must be screened early and any required DPIA must address the actual data flows, decisions and potential effects on patients.
- Evidence
Collect the proposed workflow, data fields, access roles, supplier terms and explanation of any onward use of information.
- Finding
The sales description says the tool is private, but the supplier's position on model training and support access is unresolved. The assessment cannot treat those issues as settled.
- Owner and action
The project owner seeks documented answers and considers a less intrusive configuration or alternative. The reviewer records risks, controls, DPO advice where relevant and the approval conditions.
- Verification
Check the selected configuration and binding terms against the approved data flow. Reopen the assessment if the purpose, supplier use or decision process changes.
Practical questions
What should a DPIA say about a control?
Explain the risk it addresses, what it changes, who will implement it and how you will check it. A phrase such as 'staff will be trained' is incomplete without the relevant roles, content and evidence of understanding.
When should we revisit a completed DPIA?
Use review triggers tied to the project, such as a new purpose, dataset, supplier, decision process or material risk. Record what changed and whether the previous controls and approval remain appropriate.
Official sources
- ICO — When do we need to do a DPIA? (opens in a new tab)
- ICO — DPIA overview and prior consultation (opens in a new tab)
- ICO — DPIA audit controls (opens in a new tab)
Source-linked editorial review: 1 November 2026. Guidance supports a documented process. It does not replace advice about your particular circumstances or verify your organisation’s compliance.
Content update — 2 November 2026: added an illustrative evidence record, practical questions and related guidance. The existing legal-source baseline is 1 November 2026.