Back to GRC

Data Protection Impact Assessment (DPIA): When You Need One and How to Do It

7 min read

Data protection impact assessment (DPIA) under GDPR

A data protection impact assessment (DPIA) is a structured review of how a new processing activity could affect people's privacy, and what you will do to reduce that risk. Under GDPR Article 35, a DPIA is mandatory when processing is likely to result in a high risk to individuals. For SaaS companies, common triggers are new AI features, large-scale monitoring, sensitive data such as health information, and profiling. This guide explains when you need one, how to do it, and what it must contain.

Related guides: Data processing agreements · GDPR breach notification · AI governance framework

Key takeaways

  • A DPIA is required before processing that is likely to result in a high risk to people's rights and freedoms.
  • GDPR names three mandatory cases, and European regulators list nine criteria. If two or more apply, a DPIA is usually needed.
  • A DPIA must describe the processing, assess necessity and proportionality, assess risks to individuals, and set out measures to address them.
  • If high risk remains after mitigation, you must consult the supervisory authority before starting.

When is a DPIA required?

Article 35(3) makes a DPIA mandatory for:

  1. Systematic and extensive evaluation of personal aspects, including profiling, that leads to decisions with legal or similarly significant effects
  2. Large-scale processing of special category data, such as health, biometric or genetic data, or data about criminal convictions
  3. Systematic monitoring of a publicly accessible area on a large scale

European data protection authorities, through the European Data Protection Board's guidelines, also list nine criteria that indicate high risk:

# Criterion SaaS example
1 Evaluation or scoring Lead scoring or credit risk scoring of individuals
2 Automated decisions with significant effect Automatically rejecting job applicants
3 Systematic monitoring Employee monitoring or tracking user behavior across sites
4 Sensitive or highly personal data Health, biometric, financial or location data
5 Large scale Millions of users or a whole national population segment
6 Matching or combining datasets Enriching customer data from several sources
7 Vulnerable people Children, patients, employees
8 Innovative technology New AI or biometric features
9 Processing that blocks a right or service Using data to decide who can access a service

If two or more criteria apply, plan for a DPIA. Many supervisory authorities also publish their own lists of processing that always requires one.

When a DPIA is required and the steps to complete one

What a DPIA must contain

Article 35(7) requires at least:

  • A systematic description of the processing and its purposes, including any legitimate interest relied on
  • An assessment of the necessity and proportionality of the processing
  • An assessment of the risks to the rights and freedoms of individuals
  • The measures to address those risks, including safeguards, security measures and mechanisms to demonstrate compliance

How to do a DPIA in seven steps

  1. Screen the project. Check the mandatory cases and the nine criteria. Record the decision even when no DPIA is needed.
  2. Describe the processing. What data, whose data, where it comes from, who sees it, where it is stored and for how long.
  3. Consult. Involve your DPO if you have one, security, engineering and, where appropriate, the people affected or their representatives.
  4. Assess necessity and proportionality. Is the processing needed for the purpose? Could you use less data or anonymize it? What is the legal basis?
  5. Identify and score risks. Consider harm to individuals, such as discrimination, loss of control over data, financial loss or reputational damage, and rate likelihood and severity.
  6. Plan measures. For example, data minimization, pseudonymization, access controls, retention limits, human review of automated decisions, and transparency notices.
  7. Sign off and review. Record residual risk and approval. If high risk remains, consult the supervisory authority under Article 36 before starting. Review the DPIA when the processing changes.

Example DPIA risk table

Risk to individuals Likelihood Severity Measures Residual risk
Unauthorized access to health data Possible High Encryption, MFA, role-based access, logging Low
Inaccurate automated decision about a user Possible Medium Human review of negative decisions, appeal route Low
Data kept longer than needed Likely Medium Retention schedule with automatic deletion Low
Users unaware of profiling Likely Medium Clear privacy notice and in-product explanation Low
Re-identification of pseudonymized data Unlikely High Separate key storage, access restrictions Low

Keep the scoring simple and consistent. What matters is that each risk to people has a clear measure and a recorded decision.

Who should be involved

The project owner leads, with the DPO or privacy lead advising. Engineering describes the data flows, security reviews safeguards, legal confirms the legal basis, and, where reasonable, the people affected or their representatives are consulted. Article 35(2) requires the controller to seek the DPO's advice when a DPO has been designated.

DPIAs and AI features

New AI features often meet several criteria at once: innovative technology, evaluation or scoring, and sometimes automated decisions. Run the DPIA early in design, when changes are cheap. If you also follow ISO 42001 or the EU AI Act, align the DPIA with your AI system impact assessment so one review covers both privacy and broader AI impacts. See the EU AI Act compliance checklist.

DPIA vs privacy impact assessment

A privacy impact assessment (PIA) is the general term used in many countries and frameworks. A DPIA is the specific assessment required by GDPR, with the content Article 35 sets out. If you run PIAs already, adapt your template to cover the GDPR requirements.

Common mistakes

  • Doing the DPIA after launch, when it can no longer shape the design
  • Treating it as a security risk assessment and ignoring harm to individuals
  • No record of the screening decision when a DPIA was judged unnecessary
  • Never updating the DPIA after the processing changes
  • Missing prior consultation when high risk remains

How SecureSlate helps

SecureSlate helps you track DPIAs alongside your GDPR controls, link them to risks, vendors and systems, and remind owners when reviews are due.

FAQ

Is a DPIA mandatory?

Only when processing is likely to result in a high risk to individuals, including the three cases in Article 35(3). Record your screening decision either way.

Who carries out a DPIA?

The controller is responsible. The project owner usually leads it, with advice from the DPO, security and legal teams.

Do processors need to do DPIAs?

The controller does the DPIA, but processors must assist under their data processing agreement, for example by providing security information.

How long does a DPIA take?

A focused DPIA for a single feature can take a few days. Larger or riskier processing can take several weeks, especially if consultation is needed.

What happens if we skip a required DPIA?

Failing to carry out a required DPIA can lead to fines of up to 10 million euros or 2% of worldwide annual turnover under Article 83(4), and increases the risk of harm to individuals.


Is there an official DPIA template?

GDPR does not prescribe one, but many supervisory authorities publish templates, such as the UK ICO and the French CNIL, which provides free DPIA software.

Should a DPIA be published?

It is not required, but publishing a summary can build trust, especially for public-facing or high-profile processing. Remove sensitive security details first.

How does a DPIA relate to a legitimate interests assessment?

They are different. A legitimate interests assessment checks whether you can rely on that legal basis. A DPIA assesses high risks to individuals. Some projects need both.

Can one DPIA cover several similar processing operations?

Yes. Article 35(1) allows a single assessment for a set of similar processing operations with similar high risks, such as the same feature offered to many customers.

Do we need a DPIA for processing that started before GDPR?

If the processing has changed significantly, or now meets the high-risk criteria, carry out a DPIA. It is good practice to review older high-risk processing anyway.

Does the DPO sign off the DPIA?

The DPO advises, and the controller makes the decision. Record the DPO's advice and, if you do not follow it, the reasons why.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.

Need compliance without the complexity?

SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.

Find compliance gaps in 30 seconds

Keep reading

Jun 1, 2026 · GRC

Data Protection Strategy

Jun 17, 2026 · GRC

India Data Protection Rules Are Coming

Jun 14, 2026 · GRC

What Is Risk Assessment

View more posts
Jamie
Virtual Agent

Hi! I'm Jamie. Curious about your current compliance challenges and how automation might help your team?