A controller must complete a DPIA before processing that is likely to create a high risk to people's rights and freedoms, while the design can still change.
Use this guide for implementation planning, not as a substitute for checking the consolidated UK GDPR, applicable Data Protection Act 2018 provisions, current ICO guidance, contracts, and the facts of the processing.
Run a before processing likely to create a , while design choices can still change. The workflow describes the processing and necessity, assesses risks to people, not only organisational cyber risk, selects measures, records residual risk, obtains advice where applicable, and escalates unmitigated high risk for .
1
Section 1
How should a DPIA Workflow run under the UK GDPR?
Begin with a written screening before processing starts. A is required where the nature, scope, context, and purposes make likely, including the three Article 35 examples: systematic and extensive evaluation based on automated processing, including profiling, where decisions have legal or similarly significant effects; large-scale special-category or criminal-offence processing; and large-scale systematic monitoring of publicly accessible areas.
Also check the ICO's published required-processing list and relevant risk indicators. Several indicators together, or one unusually serious indicator, may make likely. ICO examples include innovative technology combined with another risk criterion; profiling, automated decisions, or special-category data used to decide access to a service, opportunity, or benefit; large-scale profiling; specified biometric or genetic uses; combining data from multiple sources; certain tracking; children's profiling, automated decisions, marketing, or direct online services; and processing that could cause physical harm after a security breach. The facts and the ICO list control; the project label does not.
Record the screening facts and reasoning even when a full is not required. Article 35(10) has a narrow case for public-task or legal-obligation processing where a DPIA has already been carried out as part of a general impact assessment required by domestic law, unless domestic law says otherwise. Do not treat an old, generic, supplier, or group DPIA as an automatic exemption; it must cover the processing and risk being approved.
Controller and project owner: describe purposes, operations, data flows, people, technologies, recipients, retention, locations, and intended outcomes.
Privacy owner: assess necessity and proportionality, including lawful basis, purpose limits, data minimisation, transparency, rights, retention, access, sharing, and less intrusive alternatives.
Risk owners: identify possible physical, material, and non-material harm to people, then score likelihood and severity before and after each measure.
Data protection officer: give independent advice where one is designated; record that advice and explain any decision not to follow it.
Controller: seek people's or representatives' views where appropriate, unless commercial or public interests or processing security justify not doing so.
Controller: do not start processing if high residual risk remains without measures; consult the ICO under Article 36 before processing.
ICO consultation outcome: keep the submission and correspondence. Article 36 gives the ICO up to eight weeks to provide written advice, with a possible six-week extension for complexity and a suspension while requested information is outstanding; advice, a warning, or an order may require redesign or prevent launch.
What fields should the DPIA Workflow template capture?
The must contain the Article 35 minimum: a systematic processing description and purposes, necessity and proportionality, risks to people's rights and freedoms, and measures to address risk and demonstrate compliance.
Scope and actors: controller, joint controllers, processors, , project owner, affected people, systems, vendors, and data-flow diagram.
Processing: purposes, lawful basis, data sources and categories, scale, frequency, retention, recipients, transfers, automated decisions, and technology.
Necessity and proportionality: purpose fit, alternatives, minimisation, accuracy, notices, rights, access, retention, contracts, security, and transfer controls.
Consultation: affected-person or representative views where appropriate, expert and processor input, advice, disagreements, response, and any reason consultation was not appropriate.
Lifecycle: launch condition, approval authority, implemented-measure evidence, ICO consultation record, assumptions, change triggers, and next review.
How should teams review and improve the DPIA Workflow?
Review the when risk changes, not only on a fixed calendar. Triggers include a new purpose or population, more data or wider access, a new model or decision effect, a processor or destination change, security incidents, complaints, rights trends, or evidence that a measure is ineffective.
Compare the deployed processing with the approved description and test whether each promised measure operates. A risk acceptance is not a substitute for Article 36 consultation where would remain without measures. If the design changes before approval or monitoring shows that the test is no longer met, pause the affected processing until the controller has reassessed and approved a lawful route.
Verify that the live processing still matches the assessed purpose, data flow, retention, recipients, and safeguards.
Close measures only when the evidence shows they operate as described.
Recalculate residual risk after material changes and obtain fresh advice where applicable.
Pause or redesign processing when new evidence makes likely and existing measures are insufficient.