DPIA Checklist: The Essential 2026 Guide to 18 Checks Before You Sign Off

A DPIA checklist is a list of checks that helps you confirm a data protection impact assessment is needed, complete and ready for sign-off. It follows the structure of GDPR Article 35, which requires an assessment where processing is likely to result in a high risk to people’s rights and freedoms.

Teams often treat the DPIA as a form to fill in after the project is designed. A checklist pushes the work earlier and makes sure each required element is covered, from the description of the processing to the consultation and the measures that reduce risk.

The checks below are grouped into six blocks. They are general guidance, so confirm any national list of processing operations that require a DPIA with your supervisory authority.

Why use a DPIA checklist

A DPIA is both a risk tool and a record of accountability. If a regulator asks how you considered the privacy impact of a new system, the DPIA is the document you will hand over, and gaps in it are easy to spot.

A checklist keeps quality consistent across projects and authors. It helps busy product teams see what is required, it makes the review by your data protection officer faster and it reduces the number of DPIAs sent back for missing sections.

Use it at three points: during screening to decide whether a DPIA is needed, mid-way to test that the content is complete, and at the end as a final gate before approval.

Screening checks on your DPIA checklist

Check one: does the processing fall within Article 35(3), meaning systematic and extensive profiling with significant effects, large-scale processing of special category or criminal data, or large-scale systematic monitoring of a public area? Check two: is the processing on your supervisory authority’s list of operations that require a DPIA? Check three: do two or more of the criteria from the Article 29 Working Party guidelines apply, such as sensitive data, vulnerable subjects, innovative technology or large scale?

If the answer is no to all, record why you decided a DPIA is not required. The record is itself evidence. The legal wording is at GDPR Article 35 text.

When in doubt, do one. A short DPIA costs little compared with a regulator finding that a required assessment was skipped.

Block	Key checks	Evidence
Screening	Trigger criteria considered	Screening record
Description	Nature, scope, context, purpose	Processing description, data flows
Necessity	Lawful basis, proportionality	Necessity and proportionality note
Risks	Harm to individuals rated	Risk register with scores
Measures	Controls and residual risk	Measures list, residual rating
Sign-off	DPO advice, consultation, approval	Signed record, review date

Description and mapping checks

Check four: is the nature of the processing described, including what you collect, how, and from whom? Check five: are scope, context and purposes stated, including volume, retention and the categories of people? Check six: is there a data flow map showing systems, recipients, processors and any transfers abroad? The method in DPIA data flow mapping shows a simple way to draw it.

Be precise. Generic statements such as “customer data” do not help. List the fields, for example name, email, purchase history and device identifiers.

Include the legitimate interests or other lawful basis and who is responsible. Processors and joint controllers should be named, because their roles affect the risk and the measures.

Necessity and proportionality checks

Check seven: is the lawful basis identified and, for legitimate interests, is there a documented assessment? Check eight: is the data limited to what is needed, with an explanation of why less data would not work? Check nine: are retention periods set and justified? Check ten: have you described how individuals will be informed and how their rights will be handled?

Article 35(7)(b) requires an assessment of necessity and proportionality in relation to the purposes, so do not skip it. Many weak DPIAs describe risks well but never ask whether the processing is needed at all.

If the answer to the necessity question is that the goal can be reached with less data, change the design rather than record the weakness.

Risk assessment checks in a DPIA checklist

Check eleven: are risks framed as harm to individuals, not to the company? Examples include loss of control over data, discrimination, financial loss, physical harm and reputational damage. Check twelve: does each risk have a likelihood and severity rating with a defined scale? Check thirteen: is there a risk register with an owner for each item? See DPIA risk scoring for a simple five-point approach.

Special categories need extra attention. Children’s data, for instance, calls for a closer look, as DPIA for children’s data explains. AI-driven processing brings its own issues, covered in DPIA for AI.

Consider risks from misuse by insiders and from third parties, not just external attackers.

Measures and residual risk checks

Check fourteen: for each risk above your threshold, is there a measure that addresses it, such as minimization, pseudonymization, access control, encryption, shorter retention or better transparency? See DPIA mitigation measures. Check fifteen: is the residual risk after measures rated? Check sixteen: if the residual risk remains high, is prior consultation with the supervisory authority under Article 36 planned? The steps are in DPIA prior consultation.

Link each measure to an owner and a date. A measure without an owner is a wish. DPIA residual risk shows how to record the remaining exposure.

Do not accept a high residual risk without a decision by a senior person and a documented reason.

Consultation, sign-off and review checks

Check seventeen: was the data protection officer asked for advice, and was that advice recorded, along with any reason for not following it? Where appropriate, were the views of data subjects or their representatives sought? Check eighteen: is there a named approver, a date and a review trigger? Guidance is in DPIA consultation with the DPO and data subjects.

A DPIA is a living document. Review it when the processing changes, when new risks emerge or at set intervals, as explained in DPIA monitoring and review.

Store the final version with version history. If the regulator asks, you can show what you knew and what you decided at each stage.

A short DPIA checklist example

Suppose a clinic plans a patient appointment app that stores health information and sends reminders. Screening: special category data at scale, so a DPIA is required. Description: fields include name, contact details, appointment type and notes. Necessity: notes are optional, and reminders show only a time.

Risks: a lost phone could reveal clinic visits; staff could view records without need. Measures: device lock requirement, role-based access and limited reminder content. Residual risk: medium. The DPO advises stronger logging, which is added. Approval by the clinic manager, review in twelve months. The scenario is invented for illustration, yet each step maps to a check on the DPIA checklist.

Notice that the outcome is a set of design decisions, not just a document.

Common mistakes with a DPIA checklist

The first mistake is starting too late. A DPIA completed after the system is built can only document problems, not prevent them. Add a screening question to your project intake form so the work begins at design stage. The second is treating the DPIA checklist as a tick-box exercise where every answer is yes. Reviewers should ask for the evidence behind each tick.

A third mistake is rating risk to the company instead of to individuals. A data leak that costs the firm little but exposes a patient’s diagnosis is a serious privacy risk. A fourth is ignoring processors: if a vendor handles the data, its controls are part of your risk picture, and its contract should reflect the measures you rely on.

Finally, avoid the filing-cabinet effect. The DPIA should drive changes in the product, the contract or the notice, and those changes should be visible in the project plan.

Who should sign off a DPIA checklist

Approval needs authority. The project owner confirms the description is accurate, the DPO records advice, and a senior manager accepts any residual risk. Where risk stays high, the decision to consult the regulator or to drop the project should sit with the executive team.

Give reviewers a short window, such as five working days, so the DPIA checklist does not become a bottleneck. Track the average time from screening to approval as a simple service metric. If projects regularly wait weeks, simplify the template or train more reviewers.

Using a ready-made DPIA checklist

You can convert the checks into your own template, but defining the scoring, the sections and the sign-off steps takes effort. A prepared structure saves time so that teams spend it on the facts.

The DPIA Report provides screening, a necessity test, risks to individuals, measures, sign-off and a live workbook, so the DPIA checklist above maps directly onto the sections. Try it on one real project before rolling it out.

Whatever you use, keep the DPO involved and record their advice.

DPIA checklist FAQ

When is a DPIA required?

When processing is likely to result in a high risk to individuals, including the cases listed in GDPR Article 35(3) and any operations on your supervisory authority’s list.

Who completes the DPIA?

The controller is responsible. The project owner usually drafts it, the DPO advises and senior management approves.

Do I need to consult the regulator?

Only if the residual risk remains high after measures. Article 36 then requires prior consultation with the supervisory authority.

How often should a DPIA be reviewed?

Whenever the processing or its risks change, and at a set interval such as yearly for ongoing high-risk processing.

Is a DPIA public?

No, there is no general duty to publish it, although publishing a summary can build trust.