What a DPIA is (and when UK teams need one)
A Data Protection Impact Assessment (DPIA) is a structured way to identify and reduce privacy risks before you start (or significantly change) a project that uses personal data. In UK GDPR terms, it helps you describe what data you’ll use, why you need it, who will access it, how long you’ll keep it, and what safeguards you’ll put in place. A good UK DPIA template typically covers: the purpose and lawful basis, data flows (collection to deletion), categories of people and data, processors and third parties, security measures, risk scoring, and an action plan with owners and dates.
UK teams generally need a DPIA when processing is “likely to result in a high risk” to individuals’ rights and freedoms. Common triggers include:
- New or expanded monitoring (e.g., workplace tracking, CCTV analytics, call recording with automated review).
- Large-scale processing of sensitive data (health, biometrics, criminal offence data) or data about vulnerable people.
- Automated decision-making or profiling that could significantly affect people (credit-style scoring, eligibility decisions, targeted interventions).
- Systematic use of new technology (AI tools, facial recognition, device fingerprinting) where impacts aren’t well understood.
- Combining datasets in ways people wouldn’t expect, or reusing data for a new purpose.
Even when not strictly required, completing a DPIA is a practical way to evidence accountability, align stakeholders (product, security, HR, marketing), and catch issues early—especially before procurement, go-live, or a major feature release.
UK DPIA template: copy-and-paste sections you can use today
Use the headings below as a practical UK DPIA template. Replace the bracketed text with your details and keep evidence (links, screenshots, meeting notes) alongside the DPIA.
1) Project overview
What are we doing? [Describe the service/process and why it needs personal data.]
Owner: [Name/role] Date: [DD/MM/YYYY] Version: [#]
2) Processing description (what data, whose data, where it goes)
Data subjects: [Customers/staff/children/etc.]
Data types: [Identifiers, contact details, usage logs, special category?]
Sources: [User input, third parties, cookies, devices.]
Recipients: [Internal teams, processors, partners.]
Locations/transfers: [UK/EEA/other; hosting regions.]
Retention: [How long and why; deletion method.]
3) Purpose and lawful basis (UK GDPR)
Purpose: [Specific, measurable purpose(s).]
Lawful basis: [Contract/Legal obligation/Legitimate interests/Consent/etc.]
Legitimate interests test (if used): [Benefit, necessity, balancing summary.]
4) Necessity and proportionality
[Explain why each data item is needed, data minimisation steps, access controls, and how transparency is provided (privacy notice, just-in-time notices).]
5) Risk assessment
- Key risks to individuals: [Unauthorised access, distress, discrimination, loss of control.]
- Likelihood/impact: [Low/Med/High with brief rationale.]
6) Mitigations and residual risk
[Encryption, MFA, least privilege, logging, DPIA review points, staff training, vendor due diligence, incident response.]
Residual risk: [Low/Med/High] Decision: [Proceed/Proceed with changes/Stop]
7) Consultation and sign-off
Consulted: [DPO/IT/Security/HR/processor] Outcome: [Summary]
Approved by: [Name/role] Date: [DD/MM/YYYY]
How to complete a DPIA step by step (with practical examples)
1) Describe the project and data flow. Write what you’re doing, who’s involved, and where data goes. Example: “We’re adding an online appointment form for a GP practice. Data is collected on the website, sent to a booking system, and stored in the patient record.” Include categories (names, contact details, health info), volumes, and locations (UK/EU hosting).
2) Define the purpose and lawful basis (and any special category condition). Keep it specific and link to the outcome. Example: “Purpose: schedule appointments and send reminders. Lawful basis: task in the public interest. Special category: health data processed for health care provision.”
3) Assess necessity and proportionality. Explain why each data item is needed and how long it’s kept. Example: “We don’t collect NI numbers; we only ask symptoms as free text with a 500-character limit; form submissions auto-delete after 30 days once transferred.”
4) Identify risks to people. List realistic harms: disclosure, distress, discrimination, loss of control. Example: “Risk: reminder texts reveal sensitive info if seen by others; risk: staff mis-send appointment emails.”
5) Add controls and rate residual risk. Map each risk to measures. Example: “Use neutral SMS wording (‘You have an appointment’), role-based access, MFA, audit logs, staff training, and email address validation.” Record likelihood/impact before and after.
6) Record consultation and sign-off. Note who reviewed it (DPO/IG lead, IT, clinical lead), any supplier input, and decisions. Example: “Supplier confirmed encryption in transit and at rest; DPO approved with annual review and incident testing.”
DPIA vs LIA vs ROPA vs TRA: which assessment do you need?
DPIA (Data Protection Impact Assessment) is the UK GDPR tool for high-risk processing. You’ll typically need a DPIA when you introduce new technology, scale up monitoring, use special category data, or make decisions that could significantly affect people. A DPIA documents the processing, assesses necessity and proportionality, identifies risks to individuals, and sets out mitigations. If your DPIA shows residual high risk, you may need to consult the ICO before going live.
LIA (Legitimate Interests Assessment) is only relevant if you plan to rely on legitimate interests as your lawful basis. It’s a three-part check: purpose (why you need it), necessity (why this way), and balancing (whether your interests override people’s rights). An LIA is often used for marketing to existing customers, fraud prevention, or internal analytics—where appropriate safeguards and opt-outs exist.
ROPA (Record of Processing Activities) is your ongoing inventory of processing, not a one-off risk assessment. It captures what data you process, why, lawful bases, retention, recipients, international transfers, and security measures. Many organisations use ROPA as the “source of truth” that feeds DPIAs and privacy notices.
TRA (Transfer Risk Assessment) applies when you transfer personal data outside the UK (and/or rely on UK Addendum to SCCs). It evaluates whether the destination country’s laws and practices could undermine protections, and what supplementary measures (technical, contractual, organisational) reduce risk.
Quick rule: high risk = DPIA; lawful basis = LIA; governance inventory = ROPA; international transfers = TRA. Often you’ll need more than one for the same project.
UK DPIA FAQs (ICO expectations, sign-off, and common pitfalls)
What does the ICO expect to see in a DPIA? The ICO generally expects a clear description of the processing, the purpose and lawful basis, who data is shared with, and what personal data is involved. Your DPIA should evidence necessity and proportionality, assess risks to individuals, and document practical mitigations (technical and organisational). Keep it specific: link each risk to a control, owner, and timeframe.
When is a DPIA required in the UK? Typically where processing is “likely to result in a high risk” to people’s rights and freedoms—common triggers include large-scale monitoring, use of special category data, innovative tech, or significant profiling. If you’re unsure, record your screening decision and rationale.
Who should sign off a DPIA? Many organisations use a two-step approach: the project owner confirms accuracy and commits to actions, while the DPO (or privacy lead) provides independent review. Final approval is often by a senior risk owner (e.g., Head of Department) to ensure resourcing and accountability.
Do we need to consult the ICO? Only if high risks remain after mitigations and you cannot reduce them to an acceptable level. Document what you tried, what remains, and why.
Common pitfalls to avoid? Reusing generic text, skipping data flows, listing controls without mapping them to risks, ignoring processor/third-party roles, and treating the DPIA as a one-off. Update it when scope changes (new datasets, vendors, AI features, or expanded retention).