Last updated: 4 November 2026

A DPIA template is a structured form for running a data protection impact assessment: you describe the processing, test whether it is necessary and proportionate, score the risks to the people involved, record the measures that reduce those risks, and sign off the result before the processing starts. This guide gives you a free DPIA template you can copy, a quick screening test to decide whether you need one, and a step-by-step method with a worked example.

The template follows the minimum contents in GDPR Article 35(7) and the section structure of the European Data Protection Board's 2026 draft template, so it works for EU and UK GDPR. We also show how the same assessment can serve South Africa's POPIA, California's CCPA risk assessment rules and the EU AI Act's fundamental rights impact assessment. If you only need the definition, see our short DPIA glossary entry.

When is a DPIA required?

Under Article 35(1) GDPR, a controller must carry out a DPIA before processing that is "likely to result in a high risk to the rights and freedoms of natural persons", in particular when using new technologies. One assessment can cover a set of similar processing operations that present similar high risks.

Article 35(3) names three cases that always need a DPIA:

  1. A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that leads to decisions with legal or similarly significant effects on the person.
  2. Processing on a large scale of special category data (Article 9(1)) or of personal data relating to criminal convictions and offences (Article 10).
  3. Systematic monitoring of a publicly accessible area on a large scale.

Each supervisory authority must also publish a list of processing types that require a DPIA (Article 35(4)), and may publish a list of types that do not (Article 35(5)). In the UK, the ICO's list of processing likely to result in high risk covers innovative technology, denial of service, large-scale profiling, biometric data, genetic data, data matching, invisible processing, tracking, targeting of children or other vulnerable people, and risk of physical harm.

Skipping a required DPIA is not a paperwork lapse. Infringements of Articles 35 and 36 fall within the Article 83(4) tier of administrative fines: up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher.

DPIA screening test: the nine WP248 criteria

Most processing is not on the Article 35(3) list, so you need a screening step. The Article 29 Working Party's DPIA guidelines (WP248 rev.01), endorsed by the EDPB on 25 May 2018, set out nine criteria. The guidelines say that "in most cases" processing that meets two criteria will need a DPIA, and that one criterion can be enough in some cases.

Use this table as your screening form. Tick each criterion that applies and keep the completed form even when the answer is "no DPIA needed", because it shows you considered the question.

# WP248 criterion Ask yourself Applies?
1 Evaluation or scoring Are we profiling or predicting behaviour, performance, health, reliability or preferences? Yes / No
2 Automated decision-making with legal or similar significant effect Does a system decide something important about a person without meaningful human review? Yes / No
3 Systematic monitoring Are we observing, tracking or monitoring people, including in workplaces or online? Yes / No
4 Sensitive data or data of a highly personal nature Special category data, criminal data, financial data, location, private communications? Yes / No
5 Data processed on a large scale Many people, a large volume of data, a long retention period or a wide geographic area? Yes / No
6 Matching or combining datasets Are we joining data collected for different purposes or by different controllers? Yes / No
7 Data concerning vulnerable data subjects Children, employees, patients, elderly people or anyone with less power to object? Yes / No
8 Innovative use or new technological or organisational solutions AI, biometrics, IoT, new combinations of existing technology? Yes / No
9 Processing that prevents people exercising a right or using a service or contract Could the result block someone from a service, a loan, a job or a contract? Yes / No

Screening decision:

  • Any Article 35(3) case, or a match on your supervisory authority's list: DPIA required.
  • Two or more criteria: DPIA required unless you can document a clear reason why the processing is not high risk.
  • One criterion: judgement call. Record your reasoning and who approved it.
  • No criteria: no DPIA needed. Keep the screening record and add the activity to your record of processing activities (ROPA).

Who should be involved

A DPIA is the controller's responsibility, but it should not be written by one person in isolation.

Role What they contribute
Project or system owner Describes the processing, purposes, data flows and timeline; owns the actions
Data protection officer (where designated) Must be asked for advice under Article 35(2); reviews the assessment and records their opinion
Information security Assesses technical risks and security measures
Legal or privacy team Confirms lawful basis, transparency, transfers and contract terms
Processors and vendors Supply details of their processing, sub-processors and security measures
Data subjects or their representatives Where appropriate, their views should be sought (Article 35(9)), for example through employee representatives or user research
Senior decision-maker Accepts residual risk and signs off

If a vendor is doing the processing for you, run the DPIA alongside your vendor risk assessment so security answers and contract terms feed both records.

How to conduct a DPIA: 8 steps

The ICO sets out seven steps in How do we do a DPIA?: identify the need, describe the processing, consider consultation, assess necessity and proportionality, identify and assess risks, identify measures to mitigate the risks, and sign off and record outcomes. We add an eighth step, because a DPIA that is never revisited goes stale quickly.

Step 1: Screen and decide

Complete the screening table above at the design stage, not the week before launch. The DPIA must happen prior to the processing, and starting early means privacy measures can still change the design.

Step 2: Describe the processing

Record the nature, scope, context and purposes of the processing. Article 35(7)(a) requires "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, cover:

  • What personal data, about whom, and how much
  • Where it comes from and where it goes (a simple data flow diagram helps)
  • Systems, vendors and sub-processors involved
  • Retention periods and deletion method
  • Any transfers outside the country or region

If you already maintain a data map, link the DPIA to the relevant processing activity instead of describing it twice.

Step 3: Consult

Decide who to consult and record what they said: the DPO, security, the vendor, and where appropriate the people affected or their representatives. If you decide not to seek data subjects' views, write down why (for example, commercial confidentiality or security).

Step 4: Assess necessity and proportionality

Article 35(7)(b) requires "an assessment of the necessity and proportionality of the processing operations in relation to the purposes". Answer these questions in writing:

  • What is the lawful basis, and why does it fit?
  • Does the processing actually achieve the purpose? Is there a less intrusive way?
  • Are we collecting only the data we need (data minimisation)?
  • How will people be told (transparency notices)?
  • How will people exercise their rights, including access, objection and erasure? Link to your DSAR process.
  • What do processor contracts say, and are international transfers covered?

Step 5: Identify and assess risks

Article 35(7)(c) requires an assessment of the risks to the rights and freedoms of data subjects. Focus on harm to people, not risk to the organisation: discrimination, loss of confidentiality, financial loss, reputational damage to the individual, loss of control over their data, chilling effects on behaviour, and physical harm.

Score each risk for likelihood and severity before any new measures (inherent risk). This matrix is our own suggested scale; GDPR does not prescribe one.

Likelihood / Severity Minimal (1) Significant (2) Serious (3) Severe (4)
Remote (1) 1 Low 2 Low 3 Low 4 Medium
Possible (2) 2 Low 4 Medium 6 Medium 8 High
Likely (3) 3 Low 6 Medium 9 High 12 High
Almost certain (4) 4 Medium 8 High 12 High 16 High

Severity guide: minimal means minor inconvenience; significant means distress or difficulties people can overcome; serious means significant consequences such as financial loss or discrimination; severe means irreversible or long-term harm.

Step 6: Identify measures and residual risk

Article 35(7)(d) requires "the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data". For each risk, record the measure, its owner and due date, and re-score the risk after the measure (residual risk). Typical measures include minimising fields, pseudonymisation, shorter retention, role-based access, human review of automated outputs, clearer notices, opt-outs, and contract clauses with the vendor.

Step 7: Sign off, and consult the regulator if needed

The decision-maker accepts or rejects the residual risk, and the DPO's advice is recorded alongside the decision (including where the decision departs from it). If the DPIA shows the processing would still result in a high risk without further mitigation, Article 36 requires prior consultation with the supervisory authority before you start. The authority has up to eight weeks to give written advice, extendable by six weeks for complex processing.

Step 8: Integrate and review

Turn the actions into tracked tasks, and set a review trigger. Article 35(11) requires a review "at least when there is a change of the risk represented by processing operations". Good triggers include a new data source, a new vendor or sub-processor, a new purpose, a security incident, or a set review date (annually is a sensible default for high-risk processing). If an incident does occur, your DPIA will help you judge severity for breach notification.

Free DPIA template

Copy the sections below into your own document or system. The numbering follows the structure of the EDPB's draft Template for Data Protection Impact Assessment so it will be familiar to EU regulators, and each section notes the GDPR provision it satisfies.

Section 0. Overview

Field Your answer
Processing activity name
Controller (and joint controllers)
Project owner
DPO
DPIA version and date
Screening result and criteria met
Related ROPA entry

Section 1. Systematic description of the processing (Art 35(7)(a))

Field Your answer
Purpose(s)
Data subjects (categories and approximate number)
Personal data categories (flag special category and criminal data)
Sources of data
Systems and assets
Processors and sub-processors
Recipients
International transfers and safeguard
Retention period and deletion method
Data flow diagram (attach)

Section 2. Analysis of the processing

Field Your answer
Lawful basis (Art 6) and, if relevant, Art 9 condition
Legitimate interest pursued (if relied on)
New technology involved
Why the processing is likely to be high risk

Section 3. Necessity and proportionality (Art 35(7)(b))

Question Your answer
Is the processing necessary for the purpose? Less intrusive alternatives considered?
Data minimisation: which fields were removed or reduced?
Accuracy and data quality measures
Transparency: which notice, and when is it shown?
How individuals exercise their rights
Processor contract terms (Art 28)
Transfer mechanism

Section 4. Risk assessment and management (Art 35(7)(c) and (d))

Risk to individuals Likelihood Severity Inherent score Measure(s) Owner Due Residual score

Section 5. Involvement of interested parties (Art 35(2) and 35(9))

Field Your answer
DPO advice and date
Was the DPO's advice followed? If not, why?
Views of data subjects or representatives (or reason not sought)
Vendor or processor input

Section 6. Conclusion and decision

Field Your answer
Overall residual risk Low / Medium / High
Prior consultation required (Art 36)? Yes / No
Decision Proceed / Proceed with conditions / Do not proceed
Approved by, role and date
Next review date and triggers

About the EDPB DPIA template

The EDPB adopted version 1.0 of its Template [2026] for Data Protection Impact Assessment ('DPIA') for public consultation on 10 March 2026, with an accompanying explainer. The consultation ran from 14 April to 9 June 2026, and the EDPB says the template will be finalised after the consultation. Using it is not mandatory, but it sets out a minimum set of information the EDPB expects a DPIA to record, and the EDPB encourages organisations to use it in the meantime. Its sections are an overview, a systematic description, an analysis of the processing, necessity and proportionality, risk assessment and management (inherent risk, action plan, residual risk), involvement of interested parties, and a conclusion, with an annex linking to national authorities' guidance.

Our template keeps the same order so you can move to the final EDPB version with little rework. Check the EDPB consultation page for the current status before relying on the draft wording.

Worked example: monitoring software for remote staff

A 400-person company plans to install productivity software on employee laptops. It records active application time, takes periodic screenshots and produces a weekly "focus score" for each employee, which managers can see.

Screening. The processing meets at least four WP248 criteria: evaluation or scoring (the focus score), systematic monitoring, vulnerable data subjects (WP248 treats employees as vulnerable because of the power imbalance with their employer), and innovative technology. A DPIA is required.

Necessity and proportionality. The stated purpose is to understand workload and support staff. Screenshots capture private messages, banking pages and health searches, which goes far beyond that purpose. Aggregate team-level application data would achieve the purpose with much less intrusion.

Risk register extract (illustrative):

Risk to individuals Inherent Measures Residual
Screenshots expose private communications and special category data Likely x Serious = 9 High Disable screenshots entirely Remote x Serious = 3 Low
Focus score used for disciplinary decisions without context Likely x Serious = 9 High Report at team level only; no individual scores for managers; policy bars use in performance decisions Remote x Significant = 2 Low
Staff unaware of the extent of monitoring Possible x Significant = 4 Medium Updated employee privacy notice, briefing and FAQ before launch Remote x Significant = 2 Low
Vendor retains activity data indefinitely Possible x Significant = 4 Medium Contract sets 90-day retention and deletion certificate; vendor added to vendor register Remote x Significant = 2 Low

Outcome. With screenshots removed and reporting limited to team level, residual risk is low, so no prior consultation is needed. The DPO advised consulting employee representatives; their feedback led to the policy restriction on disciplinary use. Review is set for six months after launch or on any change to the vendor's features.

The scores and measures above are our own example, not regulatory guidance, but they show the pattern a reviewer looks for: a clear link from each risk to a specific measure and a re-scored residual risk.

DPIA requirements in other jurisdictions

The DPIA method transfers well. Several regimes require a similar assessment under a different name.

Jurisdiction Requirement What to add to the GDPR template
EU GDPR Article 35 DPIA; Article 36 prior consultation Nothing extra; check the lead supervisory authority's list
UK GDPR DPIA under UK GDPR Article 35; ICO seven-step process and sample template Check the ICO high-risk list. The ICO's summary of the Data (Use and Access) Act 2025 does not list any change to DPIAs, and the ICO notes its DPIA guidance is under review
South Africa (POPIA) Regulation 4(1)(b) requires the information officer to ensure "a personal information impact assessment is done to ensure that adequate measures and standards exist in order to comply with the conditions for the lawful processing of personal information" Map risks to the eight POPIA conditions; check whether section 57 prior authorisation applies (for example, credit reporting, or transferring special or children's personal information to a country without adequate protection)
California (CCPA) CPPA regulations, effective 1 January 2026, require a risk assessment before processing that presents significant risk, such as selling or sharing personal information, processing sensitive personal information, or using automated decision-making technology for significant decisions Record the CCPA-specific contents; review at least every three years; assessments conducted in 2026 and 2027 must be submitted (as an attestation and summary) by 1 April 2028
EU AI Act Article 27 fundamental rights impact assessment for certain deployers of high-risk AI systems (public bodies, private entities providing public services, and deployers of credit scoring and life or health insurance pricing systems) The FRIA can build on and "complement" your DPIA; under Article 26(9) deployers use the provider's instructions to carry out their DPIA

For South African organisations, the POPIA compliance guide covers the information officer's wider duties.

Common DPIA mistakes

  • Doing it after launch. A DPIA written once the system is live cannot change the design and does not meet the "prior to the processing" requirement.
  • Assessing risk to the company instead of to people. Regulators look for harm to individuals.
  • Generic risks with generic measures. "Data breach: mitigated by security" tells a reviewer nothing. Name the data, the harm and the specific control.
  • No residual risk score. Without it, nobody can tell whether the measures were enough or whether Article 36 applies.
  • Ignoring vendors. Many high-risk activities run on a processor's platform. Their sub-processors, retention and security belong in Section 1 and Section 4.
  • Never reviewing it. Treat the DPIA as a living record tied to the processing activity, not a one-off document.

Frequently asked questions

What is a DPIA template?

A DPIA template is a standard form that walks you through the contents GDPR Article 35(7) requires: a description of the processing, a necessity and proportionality assessment, a risk assessment and the measures to address the risks. Using the same template across projects makes assessments consistent and easier for a DPO or regulator to review.

Is the EDPB DPIA template mandatory?

No. The EDPB says organisations are not required to use its template. It was adopted for public consultation in 2026 and will be finalised afterwards. Some national authorities, such as the ICO, publish their own sample templates.

When is a DPIA required under GDPR?

Before any processing likely to result in a high risk to individuals, and always for the three cases in Article 35(3): large-scale profiling with significant effects, large-scale processing of special category or criminal data, and large-scale monitoring of public areas. The WP248 guidelines suggest that meeting two of their nine criteria usually means a DPIA is needed.

Who is responsible for carrying out a DPIA?

The controller. Processors should help by providing information about their processing, and the controller must seek the DPO's advice where one is designated.

How long does a DPIA take?

It depends on complexity. A well-scoped DPIA for a single vendor tool can take a few working days of effort; a new large-scale or AI-driven system can take several weeks, mostly spent on consultation and agreeing measures. Starting at design stage shortens the process because fewer changes are needed late.

What is the difference between a DPIA and a PIA?

"DPIA" is the GDPR term for the assessment in Article 35. "Privacy impact assessment" (PIA) is a broader, older term used in many other frameworks, and POPIA's regulations refer to a "personal information impact assessment". The method is similar; the legal triggers and required contents differ by law.

Run DPIAs in one place

Core GRC's privacy assessments module lets you run DPIAs, PIAs, TIAs and LIAs from consistent templates, link each assessment to the processing activity in your data map and ROPA, and log identified risks and actions in the risk and issue registers so they are tracked to completion. Linked vendor records mean the security and contract evidence you gather in third-party risk management is available when you assess the processing. See the Privacy Risk & Compliance Suite.

This guide is general information, not legal advice. Check your supervisory authority's current guidance before relying on it for a specific project.

Cover photo by Sasun Bughdaryan on Unsplash