Every data protection officer eventually asks the same question about a new project. Does this need a DPIA, or can we get away without one? Understanding DPIA as a concept is one thing. Actually screening a project against the test the Information Commissioners Office expects is another, and it is where most teams lose confidence.
This DPIA screening checklist sets out the practical mechanics: the nine screening criteria the ICO uses to identify high risk processing, the difference between a DPIA that is legally required and one that is simply advisable, who is accountable for signing it off, and the point at which residual high risk means you must consult the ICO before you can process at all. Where a project involves artificial intelligence specifically, our companion piece on scoping a DPIA for AI systems takes the same screening logic further. This article is the general purpose version that sits underneath it.
What Is A DPIA Screening Checklist?
A DPIA screening checklist is a structured set of questions used to decide whether a processing activity is likely to result in high risk to individuals, and therefore whether a full data protection impact assessment is required under Article 35 of UK GDPR. It is a filter, applied before a project starts, not the assessment itself.
Screening exists because not every processing activity carries the same level of risk. Running it properly means every project gets the right level of scrutiny. Skip it, and organisations either miss genuine high risk processing or waste effort writing DPIAs for activities that never needed one.
What Are The ICO’s Nine Screening Criteria For High Risk Processing?
The ICO sets out nine common factors, drawn from the former Article 29 Working Party guidelines, for identifying processing likely to result in high risk. Meeting two or more of these factors is a strong signal that a DPIA is needed. Meeting even one can be enough, depending on the context.
- Evaluation or scoring, including profiling and predicting behaviour, performance, or preferences.
- Automated decision making with legal or similarly significant effect on an individual.
- Systematic monitoring, such as ongoing surveillance or observation of a public area or workforce.
- Special category or highly personal data, including health, criminal offence, or financial information.
- Large scale processing, judged by the number of people affected, the volume of data, and its geographical extent.
- Matching or combining datasets from different sources, or beyond what an individual would reasonably expect.
- Data concerning vulnerable data subjects, including children, employees, or people in unequal power relationships with the organisation.
- Innovative use of technology or organisational solutions, including new applications of artificial intelligence or biometrics.
- Processing that prevents someone exercising a right, using a service, or entering into a contract.
Working through this list at the start of a project takes minutes. Working out afterwards that a DPIA should have been done takes considerably longer, and leaves the organisation exposed for however long the processing has already been running.
When Is A DPIA Legally Required Rather Than Advisable?
A DPIA is legally required under Article 35(3) for three categories of processing without further screening needed: systematic and extensive profiling with legal or similarly significant effects, large scale processing of special category or criminal offence data, and systematic monitoring of a publicly accessible area on a large scale. Outside those three categories, the nine point test above determines whether a DPIA is required.
The ICO also maintains a supplementary list of specific processing types it considers automatically high risk. This covers areas such as innovative technology, denial of service decisions, large scale profiling, biometric identification, genetic data, data matching, invisible processing, tracking, and processing that could put someone’s physical safety at risk if a breach occurred. Where a project matches one of these named types, screening is largely a formality since the answer is already established.
Everything else falls into a judgement zone. Here, the ICO’s own advice is unambiguous: if in doubt, do a DPIA. It costs relatively little to complete a light touch assessment and record a conclusion of low risk, whereas defending a decision not to do one, after the fact, in front of a regulator, is a considerably harder conversation.
Who Should Sign Off A DPIA?
Article 35(1) places responsibility for identifying the need for a DPIA, and completing it, on the controller, not the DPO personally. In practice this means a project owner or senior manager takes ownership of the assessment and its outcome, while the DPO plays an advisory and challenge role throughout.
The DPO must be consulted on whether a DPIA is needed, on the methodology used, and on whether the residual risk is acceptable. That advice should be recorded within the DPIA itself. If the organisation chooses to proceed against the DPO’s advice, UK GDPR expects that decision, and the reasoning behind it, to be documented rather than left unsaid.
Final sign off therefore usually sits with a named accountable owner, informed by documented DPO advice, information security input where relevant, and legal input for higher risk or novel processing. A DPIA with no named owner and no recorded advice is difficult to defend later, whatever conclusion it reached.
What Are The Seven Steps Of The DPIA Process?
The ICO’s own methodology breaks a DPIA into seven steps, and screening is only the first of them.
- Identify the need for a DPIA, using the nine point test above.
- Describe the processing: its nature, scope, context, and purpose.
- Consider whether to consult individuals or their representatives.
- Assess necessity and proportionality against the stated purpose.
- Identify and assess risks to the rights and freedoms of individuals.
- Identify measures to mitigate those risks.
- Sign off the outcome and record it, along with any DPO advice not followed.
A DPIA is meant to run alongside project planning, not follow it. Building it into the earliest stages of a project, rather than treating it as a compliance step bolted on before go live, is what data protection by design actually looks like in practice.
Manual Screening Compared With A Structured Platform
| Aspect | Manual spreadsheet tracking | ProvePrivacy platform |
|---|---|---|
| Screening trigger | Relies on someone remembering to ask | Screening question built into every new processing activity |
| Nine point test | Applied inconsistently, often from memory | Structured, repeatable screening workflow |
| DPO advice | Recorded in email threads or not at all | Captured against the DPIA record itself |
| Sign off | Chased manually, easy to lose track of | Reviewer sign off workflow with an audit trail |
| Reporting | A static document, rarely revisited | Live dashboard showing outstanding and completed DPIAs |
When Do You Need To Consult The ICO Before Processing?
You must consult the ICO before processing begins if, after identifying and mitigating the risks in a DPIA, a high risk to individuals remains. This is prior consultation under Article 36 of UK GDPR, and it is not optional. Processing cannot lawfully start until that consultation has concluded.
The submission to the ICO needs to cover several things. These are the roles of any joint controllers or processors involved, the purposes and means of the processing, the safeguards already in place, DPO contact details where applicable, and the completed DPIA itself. The ICO will acknowledge receipt within ten days. It aims to provide written advice within eight weeks, extendable to fourteen weeks for complex cases, with notice given within the first month if that extension is needed.
The ICO can respond in several ways. It may confirm the safeguards are sufficient, recommend further mitigation, issue a formal warning where a likely contravention is identified, or place limits on the processing. This is one reason residual risk should never be treated as an afterthought. A DPIA that closes with a high risk conclusion and no further action is not finished, it has simply reached the point where the regulator needs to be brought in before anything proceeds.
How Does The ProvePrivacy Platform Support DPIA Screening?
The ProvePrivacy platform builds the nine point screening test directly into the Records of Processing Activities workflow, so screening happens at the point a new processing activity is logged rather than as a separate exercise someone has to remember to run. Where screening flags high risk, the platform carries that activity straight into a linked DPIA, complete with evidence upload, DPO reviewer sign off, and a connection back to the central risk register.
Because every processing activity is recorded individually, a data protection team can see at a glance which activities have been screened, which still need a DPIA, and which are waiting on sign off, through a live MI dashboard rather than a spreadsheet that only one person understands. That visibility is what turns DPIA screening from a task one person carries in their head into a governed, repeatable part of how the organisation runs.
How Does This Fit With DPIAs For AI Systems?
This nine point test is the general foundation every DPIA screening decision rests on, whatever the technology involved. Where the processing activity involves an AI system specifically, the same screening applies, but the assessment then needs to look closely at the system’s training data, accuracy, and behaviour, because those characteristics shape the risk to individuals. Our companion article on DPIA for AI systems covers that scoping question in full, including why one AI system can quietly need several separate DPIAs across different purposes.
Treat this DPIA screening checklist as the first control in the process, not an afterthought bolted on at the end. Applied consistently, it keeps assessments proportionate to the actual risk, keeps the DPO’s advice on record, and keeps the organisation ready to show a regulator exactly how each processing decision was reached.
Frequently Asked Questions
Is a DPIA screening checklist the same as a DPIA?
No. A screening checklist is a short filter used to decide whether a full DPIA is required. The DPIA itself is the detailed assessment that follows once screening identifies likely high risk processing.
Do you need a DPIA for every new processing activity?
No. A DPIA is only required where processing is likely to result in high risk, based on the nine screening criteria or the ICO’s list of specific high risk processing types. Lower risk activities can be screened and recorded without a full assessment.
What happens if an organisation skips the screening step?
Skipping screening means high risk processing can go ahead without the safeguards a DPIA would have identified. If the ICO later finds a DPIA should have been completed, this is treated as a failure to comply with Article 35, regardless of whether harm actually occurred.
How long does ICO prior consultation take?
The ICO aims to acknowledge a prior consultation submission within ten days and to provide written advice within eight weeks, extendable to fourteen weeks for complex cases. Processing cannot begin until that advice has been received.
Sources
- ICO, When do we need to do a DPIA: ico.org.uk
- ICO, How do we do a DPIA: ico.org.uk
- ICO, Examples of processing likely to result in high risk: ico.org.uk
- ICO, Do we need to consult the ICO: ico.org.uk
- UK GDPR, Article 35, Data protection impact assessment: uk-gdpr.org
- UK GDPR, Article 36, Prior consultation: uk-gdpr.org
