Data Protection Impact Assessment (DPIA): Step-by-Step Guide

A Data Protection Impact Assessment (DPIA) is a documented process for identifying, assessing and reducing the risks that a processing activity creates for people, before that processing begins. Under the EU GDPR, Article 35 makes a DPIA mandatory where processing is "likely to result in a high risk to the rights and freedoms of natural persons". The output is a written record: what you are doing, why it is necessary and proportionate, what could go wrong for the people affected, what you are doing about it, and who approved the decision.

This guide gives you the screening test, the full workflow, a risk-scoring method, a worked AI example, and a downloadable starter pack you can use on your next project.

PIA vs DPIA: are they the same thing?

In everyday use the terms overlap, but they are not automatically interchangeable in law.

• Privacy Impact Assessment (PIA) is the older, broader, international term for any structured assessment of privacy impacts. It is used widely outside the EU and carries no single statutory definition. France's supervisory authority, the CNIL, publishes its methodology under the PIA name while addressing GDPR requirements.
• Data Protection Impact Assessment (DPIA) is the specific instrument named in Article 35 of the GDPR, with prescribed minimum contents, a mandatory trigger test, a duty to seek the advice of the Data Protection Officer where one is designated, and a prior consultation route under Article 36.

Practical implication: if your obligation arises under the GDPR or UK GDPR, produce something that satisfies Article 35 and call it a DPIA. If you operate under another framework, a PIA using a comparable method is usually a sound governance practice — but check what your own applicable law and regulator actually require rather than assuming equivalence.

When is a DPIA required under GDPR Article 35?

Article 35(1) sets the general trigger: a DPIA is required where a type of processing, in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons.

Article 35(3) then gives three cases that require a DPIA in particular:

1. Systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the person or similarly significantly affect them.
2. Processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10.
3. Systematic monitoring of a publicly accessible area on a large scale.

Article 35(4) requires each supervisory authority to publish a list of processing operations that are subject to a mandatory DPIA, and Article 35(5) allows authorities to publish a list of operations for which no DPIA is required. Those national lists are binding context for your assessment, so always check the list published by the authority that supervises you before concluding a DPIA is unnecessary.

When a DPIA is advisable even if not strictly mandatory

A DPIA is a proportionate way to evidence accountability, and running one is rarely wasted effort. Consider doing one voluntarily when:

• you are introducing a new technology, vendor or data flow and cannot yet articulate the risk to people;
• an existing activity is changing materially in scale, purpose or population;
• you are close to the threshold and want a documented, defensible basis for the decision either way.

Where you screen and conclude that no DPIA is required, record that screening decision and its reasons. An undocumented "we decided it wasn't needed" is very hard to defend later.

The 60-second DPIA screening checklist

The European Data Protection Board's guidance for SMEs sets out nine criteria that indicate processing likely to result in high risk. Work through them quickly at the start of any project.

Tick every one that applies to your processing:

• ☐ 1. Evaluation or scoring, including profiling and predicting — for example credit scoring, health prediction, behavioural or marketing profiling.
• ☐ 2. Automated decision-making with legal or similarly significant effect on the person.
• ☐ 3. Systematic monitoring — observing, monitoring or controlling people, including in publicly accessible areas.
• ☐ 4. Sensitive data or data of a highly personal nature — special category data, criminal data, location, financial data, or other data whose disclosure would be intrusive.
• ☐ 5. Data processed on a large scale, judged by number of people, volume and range of data, duration and geographical extent.
• ☐ 6. Matching or combining datasets, for example from two or more processing operations performed for different purposes or by different controllers.
• ☐ 7. Data concerning vulnerable data subjects — children, employees, patients, asylum seekers, or anyone with a power imbalance in the relationship.
• ☐ 8. Innovative use or application of new technological or organisational solutions — for example AI, biometrics, IoT.
• ☐ 9. Processing that prevents data subjects from exercising a right or using a service or a contract.

How to read your score. In most cases, processing that meets two or more of these criteria is a strong signal that a DPIA should be carried out. This is a well-established rule of thumb, not an automatic legal test: a single criterion can be enough where the potential impact on people is severe, and meeting two may not settle the matter where the processing is genuinely low-impact. Treat the count as a prompt for reasoned judgement, take and record your DPO's advice, and check your supervisory authority's mandatory and exemption lists before you finalise the decision.

Roles and responsibilities

A DPIA is a team exercise with one accountable owner.

Accountability does not move. Advisers advise; the controller decides and answers for the decision.

What an Article 35 DPIA must contain

Article 35(7) sets the minimum contents. Anything you produce should be traceable back to these four elements.

1. A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller. In practice: data categories, data subjects, volumes, systems, flows, recipients, retention, transfers, and the specific purpose of each element.
2. An assessment of the necessity and proportionality of the processing in relation to the purposes. Would a less intrusive option achieve the same outcome? Is every data element actually used? Is the retention period justified?
3. An assessment of the risks to the rights and freedoms of data subjects. Note the framing: risks to people, not risks to the organisation.
4. The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance, taking account of the rights and legitimate interests of data subjects and other persons concerned.

Article 35(9) adds the duty to seek the views of data subjects or their representatives where appropriate, and Article 35(11) requires review where the risk changes.

The DPIA workflow, step by step

1. Screen

Run the checklist above at the earliest design stage — while the concept can still change cheaply. Record the outcome either way. A DPIA started after launch is a compliance report, not an impact assessment.

2. Scope and describe

Write the systematic description. State the purpose in one sentence a non-specialist would understand, then the boundaries: populations, systems, countries, time period, and explicitly what is out of scope.

3. Map data, flows, vendors, retention and transfers

Build the factual base: data categories (flagging special category data), sources, systems, recipients, processors and sub-processors, transfers and their mechanisms, retention and deletion mechanics. Verify with the people who operate the system, not the design document.

4. Consult

Engage the DPO, security, legal, the business owner and — where appropriate — representatives of the people affected. Early consultation changes the design; late consultation only changes the paperwork.

5. Test necessity and proportionality

For each data element and processing step, ask: what breaks if we remove this? Could aggregation, pseudonymisation, sampling or shorter retention deliver the same outcome? Confirm the lawful basis holds, and where you rely on legitimate interests, record the balancing test.

6. Identify harms to people

Describe concrete consequences: discrimination, financial loss, fraud or identity theft, reputational damage, loss of confidentiality, denial of a service, chilling effects, distress, physical safety. Write them in plain language, from the person's point of view.

7. Assess inherent likelihood and severity

Score each risk before your planned mitigations, so the value of the controls is visible.

8. Select controls, assign owners and dates

Every mitigation needs a named owner, a due date and a link to the risk it reduces. Typical controls: data minimisation, pseudonymisation, encryption, least-privilege access, retention limits and deletion jobs, human review of automated outputs, opt-outs, transparency notices, model documentation and bias testing, logging, and vendor contractual terms.

9. Reassess residual risk

Re-score with agreed controls in place. Only count controls that are actually funded and committed — an aspirational control does not reduce residual risk.

10. Approve, record and set the review date

Record the decision (proceed, proceed with conditions, or do not proceed), the DPO's advice, any views of data subjects, the sign-off, and the review date and triggers. Store it where audit, security and the project team can find it.

A simple 4×4 risk-scoring method

Score each identified risk on two axes and multiply.

Likelihood (1–4)

Severity for the person (1–4)

Bands

Two warnings. First, scoring supports reasoned legal judgement, it does not replace it: a single severe, irreversible harm to a vulnerable group can justify stopping a project that scores "medium" on a grid. Second, score the consequences for people, not the cost to the organisation. Regulatory fines and brand damage belong in the enterprise risk register, not in the severity column of a DPIA.

Worked example: AI churn-risk scoring in customer support

Purpose. A subscription business wants to predict which customers are likely to cancel, so support agents can prioritise outreach.

Data. Account and contract data, billing and payment history, product usage telemetry, support ticket metadata, and the free-text content of support conversations. A third-party model provider hosts the model.

People affected. Approximately 400,000 consumer customers, including some who disclose health or financial hardship in support conversations.

Screening. Criteria met: evaluation and scoring (1), sensitive or highly personal data because free text may contain special category or financial hardship information (4), large scale (5), matching and combining datasets (6), innovative technology (8). Five indicators — clearly in DPIA territory.

Risks to people (before mitigation)

Mitigations selected

• Exclude free-text transcripts from model features; use structured usage and billing signals only, with a documented filter and periodic sampling check. (Owner: Data Science Lead)
• Scores drive prioritisation of outreach only. No automated decision on price, service eligibility or account closure; any adverse action requires human review with recorded reasoning. (Owner: Head of Support)
• Publish a plain-language explanation of retention scoring in the privacy notice and provide an objection route. (Owner: Privacy Lead)
• Feature store retention limited to 12 months with an automated deletion job and quarterly evidence check. (Owner: Platform Engineering)
• Article 28 terms with the model vendor: no training on our data, named sub-processors, transfer mechanism documented, audit and deletion-on-exit rights. (Owner: Procurement)
• Quarterly outcome-disparity testing across customer segments. (Owner: Data Science Lead)

Residual risk after mitigation

Decision. Proceed with conditions: the free-text exclusion filter, the deletion job and the executed vendor terms must be in place and evidenced before launch, and human review is a standing control. DPO advice was sought and recorded; the DPO agreed no prior consultation is required because no high residual risk remains. Review at six months, or earlier on any trigger below. Had the business insisted on ingesting full transcripts and acting on scores automatically, residual risk would have stayed high — and the right outcome would have been redesign, or prior consultation under Article 36.

Prior consultation under Article 36

Article 36(1) requires the controller to consult the supervisory authority prior to processing where a DPIA under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. In practice, this is the route when your DPIA cannot bring residual risk down to an acceptable level.

Article 36(3) requires you to provide, among other things: the responsibilities of any joint controllers and processors; the purposes and means of the intended processing; the measures and safeguards protecting data subjects; the DPO's contact details; the DPIA itself; and any other information the authority requests.

Under Article 36(2), where the authority considers the intended processing would infringe the Regulation, it must give written advice within eight weeks of the request — extendable by six weeks depending on complexity — and may use its Article 58 powers. Build that timeline into the project plan. Most projects never reach this point, and reaching it is not a failure of the DPIA; it is the DPIA doing what it is for.

When to review a DPIA

Article 35(11) requires the controller to carry out a review where necessary, and at least when there is a change in the risk represented by the processing operations. Set a scheduled review date, and treat these as immediate triggers:

• the purpose changes, or a new secondary purpose is added;
• new data categories are introduced, especially special category, children's or financial data;
• new recipients, processors or sub-processors are added;
• the model, algorithm or degree of automation changes, including a change of model provider or a shift from human-in-the-loop to automated action;
• processing extends to new jurisdictions, or a transfer mechanism changes or is invalidated;
• an incident, near miss, complaint or data subject objection reveals an unanticipated impact;
• a control fails, is descoped, or the evidence check shows it was never implemented;
• scale changes materially — a pilot of 2,000 people becoming a rollout to 400,000 is a different assessment.

Common mistakes

• Starting too late. A DPIA run after the architecture is frozen documents risk rather than reducing it.
• Assessing organisational risk instead of harm to people. If your risk table reads "regulatory fine, reputational damage", it is not yet a DPIA.
• Treating the checklist score as the decision. Two indicators is a signal to assess, not a verdict — and one indicator can be enough.
• Skipping the necessity test. Most DPIAs jump straight to security controls. The strongest mitigation is usually not collecting the data.
• Counting uncommitted controls. Residual risk based on unfunded intentions is fiction.
• No named owners or dates. Mitigations without an owner are opinions.
• Never reviewing. A DPIA is a live record of a live activity, not a launch artefact.
• Not recording DPO advice. Where a DPO is designated, their advice must be sought, and the record of it — including any reasoned departure — is accountability evidence.
• One DPIA per ticket. Similar operations presenting similar high risks can share a single assessment; fragmenting them buries the real risk picture.

What to do next

1. Run the 60-second screening checklist against your two most significant live or planned projects.
2. Download the DPIA Starter Pack — screening checklist, DPIA template, risk register, mitigations tracker and approval/review log — and complete the description and necessity sections for one of them. Those two sections usually surface the real issues.
3. Get DPO or privacy counsel input on the screening outcome, and record it.
4. Put the mitigations into your normal delivery backlog with owners and dates, not into a separate compliance tracker nobody reads.
5. Diary the review date and register the triggers with the project owner.

To build the surrounding programme, the free Practical Privacy Programme Implementation course covers how DPIAs connect to your records of processing, vendor management and retention work. The Privacy Readiness Assessment shows where DPIA governance sits against the rest of your programme in about ten minutes, with no email required to see your score.

Frequently asked questions

What is the difference between a DPIA and a PIA?

A DPIA is the specific assessment required by Article 35 of the GDPR, with prescribed minimum contents, a mandatory trigger and a prior consultation route under Article 36. A PIA is the broader, international term for a structured privacy impact assessment and has no single statutory definition; CNIL, for example, publishes its methodology under the PIA name. The terms overlap in everyday use but are not automatically interchangeable in law, so satisfy the requirements of the framework that actually applies to you.

Who should complete a DPIA?

The controller is accountable, and in practice the project or business owner drives it. Where a DPO is designated, the controller must seek their advice, and that advice should be recorded. Security, legal, data and process owners, and procurement all contribute, and where appropriate the controller should seek the views of the people affected or their representatives.

How long does a DPIA take?

It varies with complexity. A well-scoped activity where the data map already exists can be completed in a few working sessions across two to three weeks. A novel AI or large-scale monitoring case takes longer, because necessity analysis, vendor due diligence and consultation take elapsed time. If prior consultation under Article 36 is needed, add the statutory response period of eight weeks, extendable by six.

Can one DPIA cover several similar processing operations?

Yes. Article 35(1) provides that a single assessment may address a set of similar processing operations that present similar high risks. This is useful for a common platform rolled out across markets or business units — but the assessment must genuinely reflect each variation, particularly differences in jurisdiction, population and scale.

Does a DPIA have to be published?

There is no general obligation in the GDPR to publish a DPIA. Publishing a summary can support transparency, and some organisations do so for high-visibility processing; redact security detail and commercially sensitive information if you do. You must be able to produce the DPIA to your supervisory authority on request.

What is the vendor's or processor's role?

The controller remains accountable, but processors must assist the controller in ensuring compliance with the DPIA obligations, taking into account the nature of processing and the information available to them. In practice: request sub-processor lists, security documentation, transfer mechanisms, retention behaviour and deletion capability, and put the assistance duty in the Article 28 contract.

Does every AI project need a DPIA?

Not automatically, but many will meet the threshold. AI use cases often trigger several of the nine indicators at once — evaluation and scoring, innovative technology, large scale, combined datasets, and sometimes automated decisions with significant effects. Screen the specific use case, not the technology: a tool summarising published documents with no personal data is very different from a model that scores individuals.

We are outside the EU — for example an India-based team serving EU or UK customers. Does this apply to us?

It depends on whether the GDPR or UK GDPR applies to your processing, which turns on the territorial scope rules and your role as controller or processor, not on where your office is. Organisations offering goods or services to people in the EU or UK, or monitoring their behaviour, may be in scope and should assess that with qualified advice rather than assume either way. Your local law will also have its own requirements — India's Digital Personal Data Protection Act, for example, imposes obligations including periodic data protection impact assessments for Significant Data Fiduciaries. And where you act as a processor for an EU controller, expect to be asked to assist with their DPIA. For most global teams the practical answer is one method that satisfies the strictest applicable framework, with local variations recorded.

Official sources

This guide reflects the following official primary sources. Where a point requires legal judgement, consult qualified counsel or your supervisory authority.

• Regulation (EU) 2016/679 (GDPR), Articles 35 and 36 — EUR-Lex consolidated text
• European Data Protection Board — Be compliant: DPIA guidance for SMEs, including the nine high-risk criteria
• EDPB-endorsed WP29 Guidelines on Data Protection Impact Assessment (WP248 rev.01)
• Information Commissioner's Office (UK) — Data protection impact assessments
• CNIL — Privacy Impact Assessment: the CNIL publishes its PIA manual

This guide is educational material from the PrivacyBuilt Editorial Team. It is not legal advice and does not create a lawyer–client relationship.