DPIA Starter Pack | Privacy Practice Lab

Everything below is on this page in full — copy it, print it, or download the Markdown and CSV versions from the panel. Nothing is emailed and no form stands between you and the content.

Use this pack alongside the Data Protection Impact Assessment (DPIA): Step-by-Step Guide, which explains the reasoning behind each section, the risk-scoring method and a worked AI example.

The pack has five parts: a screening checklist, the DPIA template, a risk register, a mitigations tracker, and an approval and review log.

Part 1 — Screening checklist

Complete this before any DPIA work. Record the outcome even when the answer is "no DPIA required".

#	Screening question	Yes / No	Evidence or note
1	Evaluation or scoring, including profiling and prediction?
2	Automated decision-making with legal or similarly significant effect?
3	Systematic monitoring of people, including publicly accessible areas?
4	Sensitive data or data of a highly personal nature?
5	Processing on a large scale?
6	Matching or combining datasets from different purposes or controllers?
7	Data concerning vulnerable data subjects (children, employees, patients)?
8	Innovative use of new technological or organisational solutions?
9	Processing that prevents people exercising a right or using a service?

Also check:

☐ Does the activity fall within one of the three Article 35(3) cases?
☐ Is it on the supervisory authority's mandatory DPIA list under Article 35(4)?
☐ Is it on any exemption/whitelist under Article 35(5)?
☐ Has the DPO been asked whether a DPIA is required, and is the advice recorded?

Screening outcome: DPIA required / DPIA not required / voluntary DPIA Reason for the outcome: Decided by: Date:

Two or more indicators is a strong signal that a DPIA should be carried out. It is a prompt for reasoned judgement, not an automatic legal test — a single criterion can be enough where potential impact is severe.

Part 2 — DPIA template

2.1 Project identification

Field	Entry
Project / processing name
Reference number
Controller (legal entity)
Joint controllers, if any
Project owner (accountable)
DPO consulted (name, date)
Author and contributors
Version and date
Status	Draft / In review / Approved / Superseded

2.2 Systematic description of the processing (Article 35(7)(a))

Prompts: what happens, to whose data, in which systems, by whom, for how long, and where?

Purpose, in one plain sentence:
Business rationale and expected outcome:
Where legitimate interests is the basis, the interest pursued:
Lawful basis for each purpose (and Article 9 condition if special category data):
Data subject categories and approximate numbers:
Personal data categories (flag special category, criminal, children's, financial data):
Sources of the data:
Systems and components involved:
Processing steps, in order:
Internal recipients and access model:
Processors and sub-processors:
International transfers, destinations and transfer mechanism:
Retention period and deletion mechanism, per data category:
Automation and human involvement (is there a decision, and is a human in the loop?):
Transparency: what people are told, where, and when:
Explicitly out of scope:

2.3 Necessity and proportionality (Article 35(7)(b))

Test	Assessment
Does the processing actually achieve the stated purpose?
Is there a less intrusive way to achieve the same outcome?
Is every data element used, and what breaks without it?
Is the volume, population and frequency the minimum needed?
Is the retention period justified by the purpose?
Is the lawful basis sound; if legitimate interests, where is the balancing test?
How are data subject rights (access, objection, erasure, portability) delivered?
How is accuracy maintained, and errors corrected?
Where relevant: how is model behaviour documented and tested?

2.4 Consultation (Article 35(9))

Stakeholder	Date	Input received	How it changed the design
DPO
Information security
Legal / privacy counsel
Data / process owner
Procurement / vendor management
Data subjects or their representatives

If the views of data subjects were not sought, record the justified reason here:

2.5 Risks to the rights and freedoms of individuals (Article 35(7)(c))

Use the risk register in Part 3. Describe harms as consequences for people, not costs to the organisation.

2.6 Measures and safeguards (Article 35(7)(d))

Use the mitigations tracker in Part 4. Only count controls that are funded and committed.

Part 3 — Risk register

Score each risk before mitigation (inherent) and again after committed mitigations (residual), using likelihood 1–4 × severity 1–4.

Risk ID	Risk to the person (plain language)	Affected group	Cause / source	Likelihood (1–4)	Severity (1–4)	Inherent score	Band	Residual likelihood	Residual severity	Residual score	Residual band	Accepted by
R-001
R-002
R-003

Likelihood: 1 remote · 2 possible · 3 likely · 4 near certain Severity for the person: 1 negligible · 2 limited · 3 significant · 4 severe Bands: 1–3 low · 4–7 medium · 8–11 high · 12–16 very high

Scoring supports reasoned legal judgement; it does not replace it. A single severe, irreversible harm can justify stopping a project that scores "medium".

Part 4 — Mitigations, owners and due dates

Action ID	Linked risk ID	Control type	Status
M-001	R-001	Technical / Organisational / Contractual	Not started
M-002
M-003

Control types to consider: data minimisation · pseudonymisation or aggregation · encryption in transit and at rest · least-privilege access and MFA · retention limits and automated deletion · human review of automated outputs · opt-out or objection route · transparency notice update · model documentation and bias testing · logging and monitoring · Article 28 contract terms · sub-processor controls · transfer mechanism · deletion on exit.

Part 5 — Approval, DPO advice, decision and review log

5.1 DPO advice

Field	Entry
DPO name
Date advice sought
Advice given (summary)
Advice accepted in full?	Yes / No
If not accepted, reasons recorded

5.2 Decision

Field	Entry
Decision	Proceed / Proceed with conditions / Do not proceed
Conditions that must be met before go-live
Highest residual risk score and band
Is any residual risk high in the absence of further measures?	Yes / No
If yes, is prior consultation under Article 36 required?	Yes / No — with reasons
Article 36 submission date and authority response
Approved by (name, role)
Approval date

5.3 Review log

Review date	Trigger	Change assessed	Outcome	Next review date	Reviewer
	Scheduled review
	Purpose change
	New data categories
	New recipient, processor or sub-processor
	Model, algorithm or automation change
	New jurisdiction or transfer mechanism change
	Incident, complaint or objection
	Control failure
	Material change in scale

How to use this pack

Screen with Part 1 and record the outcome, whichever way it goes.
Complete Part 2 sections 2.2 and 2.3 first — description and necessity surface most real issues.
Build the risk register in Part 3 from harms to people, scored before mitigation.
Assign every mitigation in Part 4 a named owner and a date, and put them in your normal delivery backlog.
Re-score residual risk, then complete Part 5 and diary the review.

For the reasoning behind each step, the nine screening indicators, the scoring bands and a worked AI example, read the DPIA step-by-step guide. To build the surrounding programme, take the free Practical Privacy Programme Implementation course, and use the Privacy Readiness Assessment to see where DPIA governance sits against the rest of your programme.

This pack is educational material from the PrivacyBuilt Editorial Team. It is not legal advice. Adapt it to your own context and take qualified advice where a legal judgement is needed.