# DPIA: processing, risks, mitigation and sign-off

Complete this assessment before introducing or materially changing processing that is likely to create a high risk. Apply the ICO screening criteria and their conditions. Record risks to people as well as delivery risks to the organisation.

Document edition 2 — 1 November 2026

Organisation / activity: 
Owner: 
Reference and version: 
Review date: 

## 1. Project and DPIA screening

- Describe the proposal, the change from existing practice and the intended decision date.
- Check Article 35 and the ICO’s published list, including relevant combinations of risk criteria. A new CRM or AI tool prompts screening; it is not automatically a mandatory DPIA in every case.
- If concluding that a DPIA is unnecessary, record the evidence and reviewer’s reasoning and retain the screening record.

Project / version / owner: 
Proposed start date and decision gate: 
Controller / processor roles: 
Screening criteria and evidence: 
DPIA required? Reasoned decision: 
Screening reviewer and date: 

## 2. Describe the complete processing lifecycle

- Describe collection, use, analysis, sharing, storage, access, retention and deletion. Include support access, subcontractors and transfers.
- Identify data sources, affected groups, scale, frequency, geographical coverage and sensitive information.
- Describe automated decisions, monitoring and AI involvement, including meaningful human oversight where relevant.

Purpose and expected benefit: 
Data subjects and data categories: 
Data sources and collection method: 
Systems / suppliers / recipients / countries: 
Data-flow description or controlled diagram reference: 
Retention / deletion / access arrangements: 

## 3. Test necessity and proportionality

- Identify the Article 6 basis and any additional Article 9/10 conditions and safeguards. Do not assume a DPIA creates a lawful basis.
- Explain why the processing is necessary and compare less intrusive alternatives.
- Review minimisation, accuracy, transparency, rights, security, processor terms, transfers and safeguards for children or vulnerable people.

Lawful basis and additional conditions: 
Necessity and alternatives rejected with reasons: 
Data minimisation decisions: 
Transparency and rights mechanisms: 
Supplier / security / transfer safeguards: 
Children or vulnerable-person safeguards: 

## 4. Seek advice and relevant views

- Seek the appointed DPO’s advice and record it. Consult security, operations, legal, procurement and other relevant roles.
- Consider whether and how to seek affected people’s views or representatives’ views. Explain any decision not to consult.
- Record disagreement and the reason for accepting or rejecting advice.

DPO advice and date: 
Stakeholders consulted: 
Affected-person consultation or reason not undertaken: 
Objections and responses: 
Unresolved disagreement and escalation: 
Advice evidence references: 

## 5. Maintain the risk and mitigation register

- Create one row per scenario: source of risk, event, affected people and potential harm. Include exclusion, discrimination, distress, loss of confidentiality and loss of control where relevant.
- Use a stated likelihood and severity method. Record initial risk, mitigation, control owner, evidence, residual risk and whether the control is implemented.
- Do not reduce the residual rating for a control that is merely proposed. Describe uncertainty and limitations.

Risk ID / scenario / affected group / harm: 
Initial likelihood / severity / rationale: 
Mitigation and responsible owner: 
Implementation due date and evidence: 
Residual likelihood / severity / rationale: 
Assumptions, uncertainty and verification result: 

## 6. Decide, escalate and authorise

- State whether the proposal may proceed, needs redesign or must pause. Explain the decision and conditions.
- Where high residual risk cannot be reduced, record the Article 36 prior-consultation decision and do not treat internal approval as a substitute.
- Record accountable sign-off, DPO advice and control verification separately. A typed draft name does not establish actual approval.

Decision and conditions: 
Residual high risks: 
Prior ICO consultation required? Rationale: 
Consultation reference and outcome if applicable: 
Accountable approver / approval evidence / date: 
Launch gate and controls still outstanding: 

## 7. Review and maintain

- Set a review date and event triggers, including changed purpose, new supplier, incident, different data or affected population and new technology.
- Integrate agreed controls into project tasks, contracts, notices and the ROPA.
- Keep version history and record any divergence between approved design and live operation.

Review owner and next date: 
Review triggers: 
ROPA / notices / contract references: 
Post-launch control checks: 
Changes since approval: 
Version and review decision: 

## Sources

- ICO: When a DPIA is required: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/
- ICO: DPIAs and prior consultation: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/