A GDPR DPIA (data protection impact assessment) flags privacy risks before you launch a new product, tool, or process — skip it on high-risk processing and the ICO can order you to stop, or fine you up to £17.5 million or 4% of global turnover under UK GDPR.
Why this matters
The ICO doesn't ask whether you did a DPIA after something goes wrong — it asks for the document. No document means no evidence you thought about the risk, and that alone can turn a minor incident into an enforcement action.
A GDPR DPIA also isn't optional paperwork for big companies only. If you're rolling out new tracking software, processing special category data, or automating decisions about customers, UK GDPR expects a DPIA regardless of headcount.
OneClickComply automates the evidence trail behind GDPR, ISO 27001, and SOC 2 programmes, so the DPIA register doesn't live in a forgotten spreadsheet. The mechanism matters more than the label — a DPIA is a structured way to catch a privacy problem before it becomes a customer complaint or an ICO case file.
What you'll need
- Time: 2-4 hours for a straightforward processing activity, 1-2 days for anything involving special category data or automated decision-making
- A project owner who understands what the system actually does with personal data
- Your DPO or privacy lead — required if you have one; strongly advised if you don't
- A systematic description template covering purpose, data flows, and retention
- A risk scoring matrix (likelihood x severity, on a consistent scale)
- Sign-off authority — someone senior enough to accept residual risk or kill the project
- Access to GDPR compliance software if you're running DPIAs across more than one team or product line
The steps
1. Screen the project against the threshold test
This decides whether a full GDPR DPIA is even required. Check the processing against the ICO's high-risk criteria: large-scale profiling, special category data, systematic monitoring, automated decisions with legal effect, or new technology applied to personal data.
Run the screening before development starts, not after launch. Common mistake: teams screen the finished product instead of the plan, which means findings arrive too late to change the design cheaply.
2. Describe the processing systematically
Write down what data you collect, why, how it flows, who touches it, where it's stored, and how long you keep it. Be specific — "customer data" isn't a description; "email, name, and purchase history retained for 24 months in a UK-hosted database" is.
This step produces the backbone of the entire DPIA. Common mistake: describing the intended system instead of the actual one, especially when a vendor's default settings differ from what your team assumes.
3. Assess necessity and proportionality
Justify why this processing is needed to achieve the stated purpose, and whether a less invasive option exists. If you can hit the same business outcome with less data or shorter retention, the DPIA should say so.
This is where GDPR DPIAs earn their keep — half the risk reduction in most assessments comes from cutting unnecessary data collection at this stage, not from adding controls later.
4. Identify and score the risks
List the specific ways the processing could harm individuals: unauthorised access, inaccurate profiling, discriminatory automated decisions, data loss, or excessive retention. Score each on likelihood (1-5) and severity (1-5) using the same scale every time.
Common mistake: scoring risk from the company's perspective ("this would embarrass us") instead of the individual's ("this could affect someone's credit, employment, or safety"). UK GDPR cares about the second one.
5. Identify measures to mitigate risk
For every risk scored above your acceptable threshold, list a specific control: encryption at rest, role-based access, shorter retention, anonymisation, or a manual review step before an automated decision goes live. Re-score the residual risk after each control.
If residual risk stays high after reasonable mitigation, that's the trigger for step 6, not a reason to lower your standards on what counts as "high."
6. Consult your DPO and, if needed, the ICO
Your DPO reviews the assessment and either signs off or sends it back. If residual risk remains high even after mitigation, UK GDPR requires prior consultation with the ICO before you start processing.
Common mistake: treating DPO consultation as a formality rather than a real checkpoint — a DPO who never pushes back on a DPIA isn't doing the job UK GDPR assigns them.
7. Sign off and integrate the findings
Get documented sign-off from someone with authority to accept the residual risk or halt the project. Feed the mitigations into actual build tickets, vendor contracts, or policy updates — a DPIA that sits in a folder unread changes nothing.
Set a review date. Processing changes, new integrations, or a data breach elsewhere in the business are all triggers to revisit the assessment, not wait for an annual calendar reminder.
Automate your GDPR DPIA evidence trail
Keep DPIA records, risk scores, and sign-offs in one place instead of a spreadsheet.
Troubleshooting
Risk scores don't match between reviewers. Fix it by locking the likelihood and severity definitions in writing before anyone scores anything — a 3 has to mean the same thing to every reviewer, every time.
The DPIA gets treated as a one-off form. Fix it by tying DPIA triggers to your change-management process, so any new integration, vendor, or data field automatically prompts a fresh screening in 2026 and beyond.
Residual risk stays high after mitigation. Fix it by escalating to ICO consultation rather than quietly lowering your risk threshold to make the number look acceptable.
No one owns the DPIA register. Fix it by naming a single accountable owner — usually the DPO or a compliance lead — who tracks open, in-progress, and reviewed assessments.
A vendor won't share enough detail for the third-party risk section. Fix it by treating an unresponsive vendor as a red flag in the assessment itself rather than skipping that row.
Tools and resources
- ICO's own DPIA guidance and screening checklist (ico.org.uk)
- A standing risk scoring matrix, shared across every project, not rebuilt each time
- Automated evidence collection so DPIA records, approvals, and mitigation tickets don't live in scattered documents
- A DPIA register that logs status, owner, and next review date for every assessment in flight
What to do next
A GDPR DPIA rarely stands alone — it usually sits next to a broader decision about which compliance framework fits your risk profile, especially if you're also working toward ISO 27001 or SOC 2 in the same year. Map the DPIA findings against whichever framework you're pursuing next so the evidence does double duty instead of getting collected twice.
Frequently asked questions
One last thing
Most DPIAs fail not on the risk scoring but on step 2 — the systematic description. Get the description wrong and every risk score built on top of it is wrong too, so spend the extra hour there before touching the risk matrix.