Data protection impact assessments
UK GDPR Article 35 requires a data protection impact assessment (DPIA) before any processing likely to result in a high risk to people, such as large-scale use of sensitive data, profiling with significant effects or systematic monitoring. Where the risk stays high after mitigation, Article 36 requires you to consult the regulator before starting. EU GDPR has the same articles.
The requirement in plain English
A DPIA is a structured look at a piece of processing before you start it: what it does, whether it is necessary, what could go wrong for the people affected, and how you will reduce that. The same articles apply in EU GDPR.
When it is required. A DPIA is required where processing is likely to result in a high risk, taking into account its nature, scope, context and purposes, and especially where it uses new technology (UK GDPR Article 35(1)). Three cases always need one (UK GDPR Article 35(3)): systematic and extensive evaluation of people, including profiling, that leads to decisions with legal or similarly significant effects; large-scale processing of special category or criminal offence data; and large-scale systematic monitoring of a publicly accessible area. Regulators publish lists of further cases (UK GDPR Article 35(4)).
What it contains (UK GDPR Article 35(7)): a description of the processing and its purposes; an assessment of necessity and proportionality; an assessment of the risks to people; and the measures, safeguards and security that address them.
Who is involved. You must seek the advice of your data protection officer if you have one (UK GDPR Article 35(2)), and, where appropriate, the views of the people affected or their representatives (UK GDPR Article 35(9)). You review the assessment when the risk changes (UK GDPR Article 35(11)).
Prior consultation. If the DPIA shows a high risk you cannot reduce, you must consult the regulator before you begin (UK GDPR Article 36). The regulator has up to eight weeks to give written advice, extendable by six weeks for complex cases (UK GDPR Article 36(2)).
UK GDPR
The ICO publishes a list of processing that needs a DPIA, adding cases such as new technology, denying access to a service, large-scale profiling, biometric or genetic data, matching data sets, invisible processing, tracking and targeting children. Since 5 February 2026, online services likely to be used by children must also weigh children’s higher protection needs when designing their measures, which a DPIA is the natural place to record. Prior consultation goes to the ICO.
EU GDPR
Each supervisory authority publishes its own list (EU GDPR Article 35(4)), and the European Data Protection Board endorses guidance setting out nine criteria, such as evaluation or scoring, sensitive data, large scale, vulnerable people and new technology. Processing that meets two or more criteria usually needs a DPIA. Prior consultation goes to the competent supervisory authority.
This is guidance to help you understand the requirement, not legal advice.
What good looks like
A 50-person digital health company screens every new project and every significant change with a one-page questionnaire based on the regulator’s list. The product manager fills it in; the privacy lead decides whether a full DPIA is needed and records why, either way.
A full DPIA starts at design, not at launch. The privacy lead runs it with the product owner, an engineer and, for clinical features, the clinical safety officer. It describes the data flows, tests whether each data item is needed, scores each risk to patients by likelihood and severity, and lists the measures with an owner and a date. The company’s external data protection officer reviews it and their advice is recorded, including any advice not followed and why.
Approval sits with the managing director, who signs off the residual risk. The DPIA is reviewed whenever the feature changes and at least once a year, and the record of processing links to it. If a residual risk stays high, the team prepares the regulator consultation before any launch date is fixed.
Evidence an auditor expects
- Screening records: usual; the auditor checks why projects that skipped a DPIA did not need one.
- Completed DPIAs: required where high risk is likely; the auditor checks all four Article 35(7) elements are there.
- Data protection officer advice: required where you have one; the auditor looks for the advice and your response.
- Sign-off of residual risk: usual; it shows who accepted the remaining risk and when.
- Action tracking: usual; the auditor checks the measures the DPIA promised were implemented.
- Review history: required in substance by Article 35(11); the auditor looks for reviews after changes.
- Prior consultation correspondence: required where residual risk stayed high.
Common mistakes
The DPIA written to justify a decision already made
An assessment completed the week before launch changes nothing. Start at design, while the answer can still change the product.
Risks to the company instead of to people
Reputational damage and fines are your risks. A DPIA assesses the risks to the people whose data it is: discrimination, loss of control, financial harm, distress.
No record of the screening decision
When asked why a project had no DPIA, many teams have no answer on file. Keep the screening, even when it says no.
Measures with no owner
A list of mitigations without owners and dates is a wish list. Track each measure to done, and note when it was verified.
Assessing once and filing
Processing grows: new data, new users, new suppliers. Tie DPIA review to the change process, not to a calendar alone.
How Sted helps
- Sted has no DPIA record template.
- Sted’s Personal Data Protection Policy (POL-PDP) has its own sections on lawful basis, special category data, individuals’ rights, security, processors and international transfers, records of processing and the data protection officer, each tagged to the UK GDPR and EU GDPR requirements it meets.
- Administrators can create their own documents alongside the ones from Sted’s knowledge base.
- For UK GDPR and for EU GDPR Sted’s knowledge base carries 34 policies, procedures and notices and 35 record templates each, led by the Personal Data Protection Policy, the Data Subject Rights Handling Policy, the Data Retention and Erasure Policy and the two privacy notices.
Sted does not decide whether you need a DPIA, assess the risk or consult the regulator for you.
Related guides and terms
- Data protection impact assessments: the step-by-step way to run one.
- DPIA: the term defined.
- Special category data: one of the commonest triggers.
- Lawful basis for processing: the necessity test a DPIA also applies.
- Records of processing activities: where each DPIA is linked to its activity.
- Documents: where you can hold your own documents beside Sted’s knowledge base.
Frequently asked questions
Do I need a DPIA for a new CRM or HR system?
Usually not for a like-for-like replacement holding ordinary customer or staff data. You probably do if the new system adds profiling, monitors staff, matches data from several sources or handles health data at scale. A short screening record showing why you decided either way is worth keeping.
Can I start processing while the DPIA is still open?
No. The assessment must come before the processing it covers, and a DPIA written after launch cannot shape the design it was meant to test. If the timetable is tight, scope the assessment to the launch and review it as the processing grows.