A Data Protection Impact Assessment (DPIA) is one of the most important — and most misunderstood — requirements under UK GDPR. Many organisations treat it as a compliance checkbox, producing a document that ticks boxes but doesn't genuinely assess risk. Done properly, a DPIA forces you to think through how your processing will affect real people, what could go wrong, and what you will do about it. This guide walks through the five steps the ICO recommends, with practical advice on what to include and what auditors expect to see.
When is a DPIA required?
UK GDPR Article 35 requires a DPIA before any processing that is "likely to result in a high risk to the rights and freedoms of natural persons." The ICO has published a screening checklist — if your processing meets any two of the following criteria, a DPIA is required:
- Evaluation or scoring of individuals (including profiling)
- Automated decision-making with legal or significant effects
- Systematic monitoring (CCTV, workplace monitoring, tracking)
- Processing of special category or criminal offence data
- Data processed on a large scale
- Matching or combining datasets from different sources
- Data concerning vulnerable individuals (children, patients, employees)
- Innovative use of new technologies (AI, biometrics, IoT)
- Processing that prevents individuals from exercising their rights
- Processing involving the transfer of data outside the UK
Even if a DPIA is not strictly required, conducting one is good practice for any significant new processing activity — and is evidence of a privacy-by-design approach that auditors value.
Step 1: Describe the processing
The foundation of a DPIA is a clear, complete description of what you are doing with personal data. This is not a high-level summary — it needs to be specific enough for someone unfamiliar with the project to understand the data flows. Cover:
- What data — list every category of personal data involved, flagging any special category data (health, biometric, racial, religious, sexual orientation, criminal, genetic, political opinions, trade union membership)
- Whose data — employees, customers, children, patients, members of the public?
- Where from — collected directly, obtained from third parties, derived from other data?
- What for — the specific purposes, not vague descriptions like "business operations"
- Who sees it — internal teams, processors, third parties, international transfers?
- How long — retention periods for each data category
If special category data or children's data is involved, flag this prominently — it triggers additional requirements under Articles 9 and 8 and significantly increases the risk profile.
Step 2: Assess necessity and proportionality
This step asks: do you actually need to do this, and are you doing it in the least intrusive way possible? The questions to answer honestly:
- Lawful basis — which of the six Article 6 bases applies? If you are relying on legitimate interests, have you conducted a Legitimate Interests Assessment (LIA)?
- Necessity — is the processing genuinely necessary for the stated purpose, or is it merely convenient?
- Data minimisation — could you achieve the same purpose with less data, fewer data subjects, or shorter retention?
- Transparency — have individuals been told about the processing through a clear privacy notice?
- Rights — do you have a process for handling data subject rights requests (access, rectification, erasure, portability)?
If the answer to the necessity question is "no" or the data minimisation question is "yes, we could use less data" — stop and redesign the processing before continuing the DPIA. Proceeding with unnecessary processing is itself a GDPR violation.
Step 3: Identify and assess risks to individuals
This is the most important step — and the one most commonly done badly. The risks in a DPIA are risks to individuals, not risks to your organisation. The ICO is explicit about this distinction.
Consider each of these risk categories:
- Loss of control — can individuals manage, access, or correct their data?
- Discrimination — could the processing lead to unfair treatment?
- Financial loss — could individuals suffer financial harm?
- Reputational damage — could individuals be embarrassed or stigmatised?
- Loss of confidentiality — could sensitive information be disclosed?
- Unwanted intrusion — is the processing more invasive than individuals expect?
- Physical harm — could the processing create safety risks?
- Chilling effect — could it discourage people from exercising their rights?
Score each risk on likelihood (1–4: remote to almost certain) and severity (1–4: minimal to severe). The product gives you a risk score: 1–3 Low, 4–7 Medium, 8–11 High, 12–16 Very High.
Step 4: Identify measures to mitigate risks
For each risk scored Medium or above, document specific measures that will reduce either the likelihood or the severity:
- Technical measures — encryption, pseudonymisation, access controls, automated deletion, audit logging
- Organisational measures — staff training, policies, contractual clauses with processors, DPIAs for sub-processing
- Design measures — data minimisation by design, privacy defaults, purpose limitation built into the system architecture
After documenting mitigations, re-score each risk to determine the residual risk — the risk that remains after controls are in place. If any residual risks remain High or Very High, you must consult the ICO under Article 36 before proceeding.
Step 5: Record the outcome and sign off
The final step documents the decision:
- Proceed — all residual risks are acceptable
- Proceed with conditions — processing may begin once specific mitigations are implemented (document what and by when)
- Do not proceed — risks cannot be adequately mitigated; the processing should not go ahead in its current form
Record who approved the DPIA, the date, and when it should be reviewed. A DPIA is not a one-time document — it should be revisited whenever the processing changes or at least annually.
Exporting your DPIA
A completed DPIA needs to exist as a document that can be shared with auditors, the DPO, the ICO (if prior consultation is required), and senior management. The GovernStack DPIA tool produces two export formats:
- Spreadsheet (XLSX) — a multi-sheet workbook with Processing Description, Necessity Assessment, Risk Assessment, and Outcome on separate tabs. Ideal for working documents and risk registers that are updated over time.
- PDF Report — a formatted management report with cover page, all five sections laid out in prose and tables, and a risk summary. Suitable for board presentations, audit evidence, and ICO submissions.
Linking your DPIA to financial exposure
A DPIA identifies risks — but senior management and boards want to know: what does this actually cost us if it goes wrong? GovernStack provides three tools that quantify the financial consequences:
- The GDPR Fine Estimator models your maximum ICO fine exposure based on violation type and turnover
- The Data Breach Cost Calculator estimates the full operational cost of a breach using IBM 2024 benchmarks
- The Data Breach Compensation Calculator estimates what affected individuals could claim under Article 82
Together with the DPIA, these create a complete risk picture: what could happen, how likely it is, and what it would cost. That is the business case for data protection investment.
For the complete UK GDPR compliance framework — including principles, data subject rights, breach notification, international transfers, and ICO enforcement — see the UK GDPR Compliance Guide.