When Is a DPIA Required? Data Protection Impact Assessments and US State Rules

When is a DPIA required? Under Article 35 of the GDPR, a data protection impact assessment must precede any processing likely to result in a high risk for people's rights and freedoms. That means three named cases, most processing meeting two of the EU guidelines' nine criteria, and processing on an authority's DPIA list.

The question comes up when a feature, vendor, AI model, or ad campaign is about to launch. The GDPR sets a risk test instead of a full list, so the company running the processing makes the call, and skipping a required DPIA risks a fine. US companies that offer goods or services in the EU, or monitor people's behavior there, are covered by Article 3(2); Virginia, Colorado, and California require assessments of their own.

Key takeaways

• Screen each launch before it goes live. Article 35 asks for the assessment before processing starts, so the screen belongs in the design of any feature, vendor, or campaign that uses personal data.
• Two of the nine criteria will in most cases mean a DPIA. The EU guidelines count the criteria before any safeguards, so planned encryption or access controls do not change the answer.
• A decision not to run one needs a record. If the processing meets two or more criteria and you still conclude that high risk is unlikely, the EU guidelines ask you to document the reasons and your DPO's view.
• US state laws ask for their own assessments. Virginia and Colorado require them for activities such as targeted advertising, and California's CCPA regulations do the same for processing that presents significant risk.

What is a DPIA?

A data protection impact assessment (DPIA) is the GDPR's check on a planned use of personal data before it starts. The EU guidelines on DPIAs are WP248 rev.01, written by the Article 29 Working Party and endorsed by the EDPB. They call a DPIA "a process designed to describe the processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of natural persons". Under Article 35(7), every DPIA contains at least:

• a systematic description of the planned processing and its purposes;
• an assessment of its necessity and proportionality;
• an assessment of the risks to the people concerned;
• the measures planned to address those risks.

DPIA vs PIA vs US data protection assessments

WP248 notes that the term "privacy impact assessment" (PIA) "is often used in other contexts to refer to the same concept". DPIA is the GDPR's own term, tied to its high-risk test.

US state laws use other names: Virginia and Colorado require a "data protection assessment", and California's CCPA regulations a "risk assessment". These laws name the activities that need one, such as targeted advertising, and Virginia's and Colorado's statutes ask the controller to weigh the benefits of the processing against its risks to consumers, as mitigated by safeguards. The content of the three can overlap, while each law sets its own trigger and minimum contents.

The general rule: processing likely to result in a high risk

Under Article 35(1), where a type of processing, "in particular using new technologies", is likely to result in a high risk to individuals' rights and freedoms, the controller must assess it "prior to the processing". Three points decide how the rule applies:

• It is a screen for red flags. The UK regulator, the Information Commissioner's Office (ICO), describes it in its guidance on when a DPIA is needed as "a more high-level screening test: are there features which point to the potential for high risk?" Measuring the actual harm is the DPIA's own job. Where it is unclear whether one is needed, WP248 recommends doing it anyway.
• It reaches companies outside the EU. Under Article 3(2), the GDPR applies when your processing relates to offering goods or services to people in the EU or to monitoring their behavior there. The DPIA then joins the rest of the GDPR compliance checklist, from an inventory of processing activities to a legal basis for each one. Our GDPR compliance consulting starts with a gap analysis of how your existing practices measure up against GDPR requirements.
• Skipping it can bring a fine. Under Article 83(4), three failures can each bring a fine: skipping a required DPIA, carrying it out incorrectly, and not consulting the authority when required. The cap is €10 million or, for an undertaking, 2% of total worldwide annual turnover, whichever is higher.

Three cases where the GDPR always requires a DPIA

Article 35(3) names three types of processing that always require a DPIA, and the words "in particular" make that list non-exhaustive. The European Commission's guidance gives three examples of a required DPIA, shown here under the case each one matches:

• Profiling with legal or similarly significant effects: a systematic and extensive evaluation of personal aspects, based on automated processing including profiling, that feeds decisions with legal or similarly significant effects on people. Example: a bank screening its customers against a credit reference database.
• Large-scale special-category or criminal-offense data: processing on a large scale of the special categories in Article 9(1), such as health data, genetic data, or biometric data that identifies a person, or of data on criminal convictions and offenses. Example: a hospital implementing a new health information database with patients' data.
• Large-scale monitoring of a publicly accessible area: systematic, large-scale monitoring of a place open to any member of the public, such as a shopping center, a street, or a train station, as WP248 describes it. Example: a bus operator installing on-board cameras to monitor drivers and passengers.

The nine EDPB criteria and the two-criteria rule

Outside the three cases, WP248 gives nine criteria that point to high risk, and processing that meets two of them will in most cases need a DPIA. The EDPB endorsed the criteria with the rest of the guidelines:

1. Evaluation or scoring, including profiling and predicting, such as building marketing profiles from use of a website or selling consumer genetic tests that predict disease risk.
2. Automated decision-making with legal or similar significant effect, such as processing that may lead to the exclusion of or discrimination against individuals.
3. Systematic monitoring, including through networks or of publicly accessible areas, where people may not know who collects their data or cannot avoid it.
4. Sensitive or highly personal data: the special categories and criminal-offense data, as when a private investigator keeps offenders' details, plus data such as location data, financial data, personal documents, emails, and diaries.
5. Large-scale processing, judged by the number of people concerned, the volume and range of data, the duration, and the geographic extent.
6. Matching or combining datasets from operations with different purposes or controllers, in a way that exceeds what people would reasonably expect.
7. Vulnerable data subjects, such as children, employees, or patients, where a power imbalance limits their ability to consent to the processing or object to it.
8. Innovative technology or organizational solutions, such as combining fingerprint and face recognition for physical access control, or certain Internet of Things applications.
9. Processing that blocks a right, a service, or a contract, including operations that allow, modify, or refuse people's access to a service or entry into a contract.

WP248 adds that the more criteria a processing meets, the likelier it needs a DPIA, "regardless of the measures which the controller envisages to adopt", so encryption does not lower the count. In some cases a single criterion is enough.

The ICO counts AI as innovative technology. Its list of high-risk processing requires a DPIA when AI is combined with another criterion, such as evaluation or scoring, or sensitive data. The ICO adds that a controller may decide AI alone requires one.

Table 1 shows the six examples WP248 marks as likely to need a DPIA, with the criteria it lists for each.

Table 1. Processing WP248 marks as likely to need a DPIA

Source: Article 29 Working Party, WP248 rev.01, section III.B.a; read October 2026.

National DPIA lists: the ICO, the Irish DPC, and other regulators

Under Article 35(4), each EU supervisory authority must publish a list of processing that requires a DPIA and send it to the EDPB. The ICO's UK GDPR list names ten types:

• innovative technology, combined with a criterion from the European guidelines;
• denial of service: decisions about access to a service or benefit that use automated decision-making or special category data, such as credit checks and mortgage or insurance applications;
• large-scale profiling;
• biometrics, combined with a criterion;
• genetic data, combined with a criterion;
• data matching;
• invisible processing, combined with a criterion;
• tracking, combined with a criterion;
• targeting children or other vulnerable people;
• risk of physical harm.

The ICO's list page, as of October 2026, states that the ICO requires a DPIA for these operations. A notice on the page says the guidance is under review after the UK's Data (Use and Access) Act and may change.

The Irish Data Protection Commission (DPC) lists ten types where a documented screening shows likely high risk, including large-scale use of data for a new purpose and systematic tracking of location or behavior. The EDPB approved that list for cross-border processing. We recommend reading the list of each authority whose residents your processing reaches.

Common EU tools are not final yet:

• A common DPIA template: the EDPB adopted a draft on March 10, 2026, and published it on April 14; using it is optional. Its public consultation closed on June 9, 2026; no final version had been published by October 12, 2026.
• Proposed EU-level lists: under the Commission's Digital Omnibus proposal of November 19, 2025, the EDPB would prepare common lists of processing that does and does not need a DPIA. The Commission would adopt them by implementing act, as the EDPB and EDPS joint opinion describes. On October 12, 2026, the European Parliament's procedure file showed it at first reading, with no vote taken.

When is a DPIA not required?

WP248 lists these cases where a DPIA is not required:

• The processing is unlikely to be high risk. No automatic case or authority's list applies, and the criteria do not point to high risk; the general duty to manage risk still applies.
• A very similar processing already has a DPIA. Its results can be reused when the nature, scope, context, and purposes match, as when a railway operator covers all its stations' video surveillance with one DPIA.
• A law already assessed it. Article 35(10) exempts processing based on a legal obligation or a public task when an EU or member-state law regulates that specific processing and a DPIA was carried out when that law was adopted, unless the member state requires one. A company's own product or marketing falls outside it.
• An authority lists it as exempt. Under Article 35(5), an authority may publish a no-DPIA list, valid only while processing stays strictly within its conditions; the ICO has not issued one.

Examples regulators give of processing that does not need a DPIA

Recital 91 says processing patients' or clients' data "by an individual physician, other health care professional or lawyer" should not be considered large scale, and that a DPIA should not be mandatory for it. WP248 counts two criteria for that case, sensitive data and vulnerable data subjects, and still marks a DPIA as unlikely to be required. Its two commercial examples meet one criterion each:

• An online magazine sending a generic daily digest to its subscribers (large scale).
• An e-commerce website showing ads for vintage car parts based on limited profiling of items viewed or bought on its own site (evaluation or scoring).

Recording a decision not to run a DPIA

When processing meets two or more of the nine criteria and the controller still concludes it is unlikely to be high risk, the decision not to run a DPIA needs a written record. The three Article 35(3) cases always need a DPIA, and so does processing that meets the conditions of an authority's DPIA list. WP248 says the controller "should justify and document the reasons for not carrying out a DPIA, and include/record the views of the data protection officer". We recommend a screening record with five questions:

• Does one of the three Article 35(3) cases apply?
• Is the processing on the list of an authority whose residents you serve?
• Which of the nine criteria does it meet?
• Which exception applies, if any?
• Who decided, when, and what did the DPO advise?

Who decides whether a DPIA is required

The controller decides, and it stays accountable even when someone else does the work. Under WP248, the DPIA may be carried out by someone "inside or outside the organization, but the controller remains ultimately accountable for that task". Article 35(2) requires the controller to seek its DPO's advice where one is designated, and WP248 asks for that advice to be documented in the DPIA.

Our guide to when the GDPR requires a DPO covers whether you need one. Without a DPO, a virtual data protection officer can act as the primary liaison between your organization and regulators. Other parties have set roles too:

• Processors must help the controller with DPIAs and prior consultation, under Article 28(3)(f).
• Product providers can share their own DPIA, but under WP248 a customer deploying the product "remains obliged to carry out its own DPIA" for its implementation.
• The people affected, or their representatives, are asked for their views where appropriate, under Article 35(9).

When to run a DPIA, and when processing you already run needs one

Run the DPIA before processing starts. WP248 says it "should be started as early as is practicable in the design of the processing operation even if some of the processing operations are still unknown", and that a possible later update is no reason to postpone it.

Processing you already run needs a DPIA when a change in its risks makes it likely to result in a high risk. Article 35(11) requires a review at least when the risk changes, and WP248 names changes that can make a DPIA newly required:

• A new technology comes into use in the processing.
• A new purpose applies to the personal data.
• A changed context, such as automated decisions whose effects become more significant, or new groups of people becoming vulnerable to discrimination.

Changes can also lower the risk. WP248's examples are decisions that are no longer automated and monitoring that is no longer systematic, after which a review can show that the DPIA requirement has fallen away. Our GDPR audit tests whether a DPIA exists for every high-risk processing activity Article 35 covers and whether each one has been updated since the processing changed.

What happens when a DPIA finds a high risk you cannot reduce

If the DPIA shows a high risk that your own measures cannot reduce, Article 36(1) requires you to consult the supervisory authority before processing starts. WP248 gives two kinds of residual risk it treats as unacceptable:

• Consequences people may not overcome: illegitimate access to data that leads to a threat to people's lives, a layoff, or financial jeopardy.
• A risk that will obviously occur: for example, a well-known vulnerability that is not patched.

Where the authority considers that the processing would infringe the GDPR, it gives written advice within eight weeks of the request, and it can extend that period by six weeks for complex processing. Plan the launch date with that window in mind.

US state laws that require a data protection assessment

Virginia, Colorado, and California each require their own assessment for listed activities, separately from the GDPR screen. Two points come first:

• One assessment can serve several laws if it is topped up. Virginia accepts one made for other laws if reasonably comparable in scope and effect, Colorado's rules accept one that is reasonably similar or supplemented, and the CCPA regulations accept one that adds whatever the CCPA requires. Our data privacy consulting provides compliance assessments and support for the CCPA and CPRA.
• The same activity can get different answers. For a controller covered by Virginia's or Colorado's law, processing sensitive data needs an assessment at any scale, while Article 35(3)(b) makes a DPIA automatic only for special-category data processed on a large scale.

Table 2 sets the GDPR and the three state regimes side by side.

Table 2. DPIA under the GDPR against US state assessments

Sources: GDPR Articles 35, 36; Va. Code § 59.1-580; C.R.S. § 6-1-1309, CPA Rules, 2025 statement of basis; CCPA regulations Article 10; read October 2026.

Virginia and Colorado data protection assessments

Virginia's and Colorado's general duties bind only businesses that meet a consumer threshold:

• Virginia: § 59.1-576 covers businesses that operate in Virginia or target its residents and that control or process the personal data of at least 100,000 Virginia consumers in a calendar year. Businesses that derive over 50 percent of gross revenue from selling personal data are covered from 25,000 consumers.
• Colorado: § 6-1-1304 uses the same 100,000 test and a 25,000 test for businesses that derive revenue or a discount from selling personal data. Colorado's 2024 duty for online services offered to known minors, including its assessment, applies regardless of these thresholds.
• Both states: a consumer is a resident acting in an individual or household context; the definition leaves out people acting in a commercial or employment context.

Virginia's § 59.1-580 lists five activities that need a documented data protection assessment, among them targeted advertising and processing sensitive data. It also covers online services directed to known children. The Attorney General can demand an assessment in an investigation, and assessments stay confidential. Our overview of the Virginia CDPA covers the rest of the law.

Colorado's § 6-1-1309 bars processing that presents a heightened risk of harm without a documented assessment, naming the same core activities as Virginia. Amendments in 2024 and 2025 added precise geolocation to sensitive data and an assessment duty for online services offered to consumers the controller knows, or willfully disregards, are minors, where minors face a heightened risk of harm. The Attorney General's CPA Rules require the assessment before the processing begins. More in our Colorado Privacy Act update.

California's CCPA risk-assessment regulations

California's CCPA regulations, in effect since January 1, 2026, require a risk assessment before processing that presents significant risk to consumers' privacy. Six activities qualify:

• selling or sharing personal information;
• processing sensitive personal information, except employee and contractor data used solely for listed HR purposes such as pay and benefits;
• using automated decision-making technology (ADMT) for a significant decision about a consumer;
• making automated inferences about applicants, students, employees, or contractors from systematic observation of them;
• making automated inferences from a consumer's presence in a sensitive location;
• using personal information to train ADMT for significant decisions, or to train facial-recognition, emotion-recognition, or other identification technology.

Processing that began before January 1, 2026, and continues must be assessed by December 31, 2027, and information on assessments conducted in 2026 and 2027 goes to the California Privacy Protection Agency (CPPA) by April 1, 2028.

Conclusion

A DPIA is due before any processing that is likely to be high risk, so screen each launch while its design can still change. Check the three automatic cases first, then the nine criteria and the lists of the authorities whose residents you serve. Record the result either way, with your DPO's view, and revisit it when the technology, purpose, or context changes. For the same activity, check whether Virginia, Colorado, or California asks for an assessment of its own.