When does a product change need an impact assessment?

Product teams often ask whether a feature “needs a DPIA” as if the answer depended on the technology. It rarely does. The real trigger in most laws is the risk to people: who is affected, what data is used and what happens to someone because of the result.

A new recommendation engine, a switch to a different vendor or a plan to use location data can change that risk overnight. So can a decision to let software reject applications without a person checking. The earlier you spot the change, the cheaper it is to design safeguards in rather than bolt them on.

This article compares the main types of assessment a growing company is likely to meet: the GDPR data protection impact assessment in the EU and UK, US state data protection and risk assessments, AI impact assessments and the equivalents in Asia. It ends with a practical way to run one process that serves several laws.

What an impact assessment actually is

An impact assessment is a structured, written review of a planned activity before it starts. It describes what you intend to do, asks what could go wrong for the people affected, and records what you will do about it. The output is a set of decisions, not just a document.

Different laws use different names. The GDPR calls it a data protection impact assessment, or DPIA. Most US state privacy laws call it a data protection assessment, and California calls it a risk assessment. AI frameworks talk about AI impact assessments or, in the EU AI Act, fundamental rights impact assessments. The core questions overlap far more than the labels suggest.

The GDPR DPIA: when it is mandatory

Under Article 35 of the GDPR, a controller must carry out a DPIA before processing that is likely to result in a high risk to people’s rights and freedoms. You consider the nature, scope, context and purposes of the processing. New technologies make high risk more likely, but they are not a trigger on their own.

Article 35 names three cases where a DPIA is always required. National regulators also publish lists of processing that needs one. European regulators’ guidance identifies nine criteria, including evaluation or scoring, sensitive data, large scale, vulnerable people and innovative technology, and suggests that processing meeting two or more will usually need a DPIA.

Systematic and extensive evaluation of people based on automated processing, including profiling, that leads to decisions with legal or similarly significant effects
Large-scale processing of special category data, such as health or biometric data, or data about criminal convictions
Systematic monitoring of a publicly accessible area on a large scale

What a DPIA must contain, and what happens if risk remains

Article 35(7) sets the minimum content. A DPIA must describe the processing and its purposes, assess whether it is necessary and proportionate, assess the risks to people, and set out the measures planned to address them. If you have a data protection officer, you must seek their advice.

If the DPIA shows a high risk that you cannot reduce, Article 36 requires you to consult the supervisory authority before you start. Failing to carry out a required DPIA can itself lead to a fine of up to €10 million or 2% of worldwide annual turnover, whichever is higher.

The UK: same test, separate regulator

The UK GDPR keeps the same DPIA requirement and the same prior consultation duty, with the Information Commissioner’s Office as the regulator. The Data (Use and Access) Act 2025 kept the core test: you still need a DPIA where processing is likely to result in a high risk. What it added is a power for the government to say, through regulations, when a DPIA is or is not required. Watch for those regulations if you rely on the UK position.

The ICO publishes its own list of processing likely to need a DPIA, and its guidance treats a DPIA as good practice for any major project involving personal data. Do not assume the EU and UK lists match exactly. If you serve both markets, check both.

US state assessments, including California

Most comprehensive US state privacy laws, modelled broadly on Virginia’s, require a data protection assessment before certain processing. The usual triggers are targeted advertising, selling personal data, processing sensitive data and profiling that creates a risk of unfair treatment or other harm. The assessment weighs the benefits of the processing against the risks to consumers, taking safeguards into account. A state attorney general can ask to see it.

California goes further. Its updated CCPA regulations took effect on 1 January 2026 and require a risk assessment for specified activities, including selling or sharing personal information, processing sensitive personal information and using automated decision-making technology for significant decisions. Processing that began before 2026 and continues must be assessed by 31 December 2027, and businesses must submit attestations and summaries to the regulator from April 2028.

US assessments look a lot like DPIAs, but the triggers and required content differ. A GDPR DPIA will not automatically satisfy California’s rules, and vice versa.

AI impact assessments

AI laws add a different lens. Privacy assessments focus on personal data. AI assessments also ask about accuracy, bias, explainability, human oversight and the effect of automated outputs on people’s lives, even where little personal data is involved.

In the EU, Article 27 of the AI Act requires certain deployers of high-risk AI systems to carry out a fundamental rights impact assessment before first use. It covers public bodies, private entities providing public services and deployers using AI for credit scoring or life and health insurance pricing. After the Digital Omnibus amendments, obligations for these stand-alone high-risk uses apply from 2 December 2027. Where a DPIA already covers some of the same ground, the AI assessment supplements it.

Elsewhere, assessments are more often voluntary or sector-specific. Colorado’s rewritten AI law dropped its earlier impact-assessment model. NYC Local Law 144 requires bias audits of automated hiring tools. International standards such as ISO/IEC 42005, published in 2025, and the NIST AI Risk Management Framework offer structures many buyers now expect to see.

Asia and other markets

Several Asian laws have their own assessment duties. China’s PIPL requires a personal information protection impact assessment before activities such as processing sensitive personal information, automated decision-making and transferring data abroad. In India, the DPDP Rules require Significant Data Fiduciaries, a category designated by the government, to carry out a DPIA and an audit every twelve months once the core duties apply.

Other markets rely more on guidance. Singapore’s data protection regulator publishes a guide to DPIAs, and Saudi Arabia, the UAE free zones and Brazil all have assessment expectations for higher-risk processing. Check each market’s requirements rather than treating a GDPR document as universal coverage.

Running one process for many laws

You do not need a separate project for each law. Add a short screening step to product intake that asks a few questions: does this change who is affected, what data is used, how decisions are made or which vendors are involved? If any answer is yes, escalate to a fuller assessment.

Build one core template that covers the questions all regimes share, then add jurisdiction-specific sections. Assign each action to an owner and a date. Revisit the assessment when the purpose, data, vendor, users or decision process changes, because an assessment that sits in a folder protects no one.

Checklist

Add a privacy and AI screening question to your product intake form.
List the markets where each feature will launch before choosing which assessments apply.
Check new features against the GDPR Article 35 triggers and your regulators’ lists.
Identify processing that triggers US state assessments, starting with California.
Flag any AI used for hiring, credit, insurance, education or access to essential services.
Use one core template with jurisdiction-specific add-ons.
Assign every mitigation to a named owner with a deadline.
Schedule a review whenever purpose, data, vendor, users or decision-making changes.
Backfill assessments for existing high-risk processing, starting with the riskiest.

FAQs

Does every AI feature need a DPIA?

No. A DPIA is required where processing is likely to result in high risk to people. Many AI features will meet that threshold because of profiling, scale or sensitive data, but some will not. Screen each one and record your reasoning either way.

Who should write the assessment?

The team that knows the product should draft it, with privacy or legal input on risks and safeguards. Under the GDPR you must seek your data protection officer’s advice if you have one. The decision to proceed belongs to the business.

Can one document satisfy GDPR and California?

It can if it is built for both. The two regimes share many questions, but California has its own triggers and content requirements, plus attestations to the regulator. Use a core template with a California-specific section.

Do we have to publish our DPIA?

The GDPR does not require publication, though some organisations publish a summary to build trust. Regulators can ask to see it. Under California’s rules, businesses submit attestations and summary information rather than the full assessment.

When should we update an assessment?

Whenever something material changes: the purpose, the data, the people affected, a key vendor or the way decisions are made. Some laws also set fixed review cycles, such as India’s annual duty for Significant Data Fiduciaries.

Primary sources

EUR-Lex · General Data Protection Regulation ICO · Data protection impact assessments

General information, not legal advice.