What Is a Data Protection Impact Assessment (DPIA): When Is It Required?

6 min read

If you have been trying to figure out when a DPIA is required and whether you need one, you are in good company. Many compliance and legal teams face the same question, and the honest answer is more nuanced than most resources suggest. This guide walks you through DPIA requirements, how to recognize when one is mandatory, and how to build one that actually withstands regulatory scrutiny.

Think of a Data Protection Impact Assessment the way an architect thinks about a structural review before breaking ground. You can build without one. But if there’s a problem in the design, finding it after construction is infinitely more expensive than finding it before.

What a DPIA Is (and What It Isn’t)

A Data Protection Impact Assessment (DPIA) sounds intimidating, but the concept is straightforward: it’s a documented analysis of a data processing activity, its risks to individuals, and the measures you’ve put in place to mitigate those risks.

It’s not a security assessment. It’s not a compliance checklist. It’s not box-ticking for regulators. A DPIA is a thinking exercise, a systematic way to identify where things could go wrong with a particular processing activity, and to ensure you’ve built safeguards before that activity launches.

Under GDPR, a Data Protection Impact Assessment (DPIA) is mandatory for certain high-risk processing activities. Under US state laws (California Consumer Privacy Act (CCPA)/California Privacy Rights Act (CPRA), Texas Data Privacy and Security Act (TDPSA), and others), similar requirements now exist, though they’re called “risk assessments” instead of DPIAs. The purpose is identical: document risk and mitigation before you process.

When Is a DPIA Legally Required Under GDPR?

General Data Protection Regulation (GDPR) Article 35 requires a DPIA when processing is “likely to result in a high risk to the rights and freedoms of natural persons.”

Three categories trigger a mandatory DPIA:

1. Systematic and Extensive Automated Profiling with Legal or Significant Effects

If you’re using AI or machine learning to make decisions about an individual that produce legal consequences (employment decisions, credit decisions, criminal justice) or similarly significant effects (social scoring, health insurance eligibility), a DPIA is required. The threshold is “systematic and extensive.” One-off automated decisions usually don’t trigger the requirement, but ongoing profiling programs do.

2. Large-Scale Processing of Special Category Data

If you’re processing special category data (health information, biometric data, racial/ethnic origin, political opinions, trade union membership, genetic data, etc.) at a large scale, a DPIA is required. “Large scale” isn’t precisely defined in the GDPR text or EDPB guidance, and no official numeric threshold exists. Regulators consider factors including the number of individuals affected, geographic scope, duration of processing, and types of data involved. Processing health records for 100 employees versus processing health data for your entire user base are different risk profiles, and both may require a DPIA. The determining factor is the risk profile of the processing, not a headcount cutoff.

3. Systematic Monitoring of Publicly Accessible Area at Large Scale

Mass surveillance, including video surveillance of public spaces, public CCTV networks, and facial recognition systems deployed broadly, triggers a DPIA. Most commercial companies don’t fall into this category unless you’re deploying security systems that monitor large public areas.

Beyond these three mandatory triggers, the GDPR’s Article 29 Working Party (now the EDPB) has identified additional high-risk scenarios where a DPIA is strongly advisable even if not strictly mandatory: processing data of vulnerable populations (children, elderly, disabled individuals), processing data for new purposes, linking datasets from multiple sources, using emerging technologies, or processing activities with potential to be discriminatory or manipulative.

When Is a DPIA Strongly Advisable Even If Not Required?

Regulators have made clear that “not legally required” isn’t the same as “not needed.” The EDPB guidance recommends DPIAs for:

• Processing data from vulnerable populations (children, elderly, people with disabilities)
• Combining data from multiple sources to create profiles or infer sensitive information
• Using algorithmic decision-making or automated profiling
• New processing activities not yet assessed
• Emerging technologies where risks aren’t fully understood
• Processing activities that could be discriminatory or result in exclusion
• Processing triggered by regulatory changes

The practical guidance: if you’re uncertain whether a DPIA is required, conduct one. A defensive DPIA is cheaper than defending your program without one during a regulator inquiry.

What’s Inside a DPIA: The Key Components

A defensible DPIA contains the following elements:

1. Description of the Processing Activity

What data is collected, from whom, where it comes from, who has access to it, how long it’s retained, and what systems are involved. This must be detailed enough that someone unfamiliar with the activity could understand it from reading this section.

2. Purpose and Necessity Assessment

Why is this processing activity necessary? Does the activity actually achieve its stated purpose, or is unnecessary data being collected? Is there a less privacy-intrusive way to achieve the same goal? This forces you to eliminate unnecessary processing before the activity launches.

3. Lawful Basis Identification

What legal basis do you rely on for this processing? Consent, legitimate interest, contractual necessity, legal obligation, vital interests, or public task. If the lawful basis is “legitimate interest,” you must conduct a balancing test: does your interest outweigh the individual’s privacy interest?

4. Risk Identification

What could go wrong? Unauthorized access, data breach, discriminatory outcomes, individuals unable to exercise their rights, loss of control over data, scale of impact if something fails. This is where you get systematic: brainstorm risks across confidentiality, integrity, availability, accountability, and fairness.

5. Mitigation Controls Assessment

What safeguards have you already implemented or will implement to mitigate each identified risk? Encryption, access controls, audit logging, vendor assessment, data minimization, anonymization, testing for bias, notice and choice mechanisms. For each significant risk, document what controls you’re deploying.

6. Residual Risk Conclusion

After mitigation, what risk remains? Some processing activities can be designed to have minimal risk. Others have inherent risks that can’t fully be eliminated. In those cases, document the residual risk clearly so your organization understands what you’re accepting.

7. DPO Consultation (if applicable)

If you have a Data Protection Officer, they must be consulted on the DPIA. Even if you don’t have a DPO, this section documents whether and how external experts or legal counsel were involved in the assessment.

Who Should Conduct a DPIA?

A DPIA should involve multiple perspectives:

• Data protection / privacy lead: drives the assessment and documents findings
• Business/product owner: explains the processing activity and business necessity
• Technical lead or engineer: describes technical implementation and security controls
• Legal counsel: assesses lawful basis and regulatory obligations
• Data Protection Officer (if applicable): validates the assessment

A DPIA conducted only by the privacy team will miss technical details. A DPIA driven only by engineering will lack privacy context. The assessment needs cross-functional ownership to be credible.

Common Mistakes That Undermine a DPIA

Several recurring mistakes render a DPIA unhelpful or even increase regulatory risk:

• Generic risk identification: a DPIA that lists risks like “data breach could occur” without being specific to the activity doesn’t actually advance the assessment. Risks should be specific: “third-party vendor X has access to customer location data; if compromised, 50,000 individuals affected; mitigation: vendor encryption and contractual DPA with insurance requirement.”
• No acknowledgment of residual risk: a DPIA that concludes “all risks mitigated” is unrealistic. Document residual risks clearly so your organization understands what they’re accepting.
• No involvement from technical teams: a DPIA written by lawyers alone misses how the system is actually built. If technical implementation doesn’t match the documented controls, the DPIA is worthless.
• Conducting the DPIA too late: a DPIA conducted after a system is already live and changes are expensive defeats the purpose. DPIAs are meant to inform design decisions. Conduct them in the design phase, not after launch.
• No follow-up on findings: if the DPIA identifies risks that require mitigation, assign ownership and timelines for addressing them. A DPIA with no remediation plan is incomplete.
• Not updating when processing changes: a DPIA from three years ago that hasn’t been revisited as your processing activity evolved is stale. Update DPIAs when you change data sources, retention periods, vendor relationships, or purposes.

DPIAs Under US State Laws (CCPA/CPRA, TDPSA, and Others)

GDPR has DPIAs. US state laws call them “risk assessments,” but they serve the same purpose.

CCPA/CPRA: requires documented risk assessments for processing activities presenting “heightened risk,” including processing sensitive personal information, large-scale automated profiling, and processing activities presenting reasonable risk of discrimination or manipulation. The California Privacy Protection Agency (CPPA)’s 2026 guidance clarified that these assessments must be written, specific to the processing activity, and regularly reviewed.

TDPSA: requires a data protection impact assessment for processing activities including targeted advertising, selling personal data, profiling that presents a foreseeable risk of harm, and processing sensitive personal data. The assessment must document privacy risks and the safeguards in place to address them.

Other state laws (Colorado CPA, Virginia CDPA, Connecticut CTDPA, Utah UCPA): all impose risk assessment requirements for sensitive data processing, algorithmic decision-making, or activities presenting heightened risk.

The bottom line: if you’re processing data in multiple US jurisdictions, each has some form of required risk assessment. The formats differ slightly, but the underlying purpose is identical to GDPR DPIAs.

Next Steps

DPIAs serve a purpose beyond compliance checkbox. They force you to think through risks and build safeguards before processing launches, not after. If you’re processing sensitive data, deploying automated decision-making, or scaling to new data sources, a DPIA is the right tool.