Data Protection Impact Assessment: The Article 35 Guide
A data protection impact assessment is what GDPR requires before you launch processing that is likely to be high risk for the people whose data you are handling. Most guidance on it is written by and for European regulators, which leaves a gap for the US SaaS company that has EU customers and now faces state-level risk assessment duties at home too.
This guide covers the screening test, what Article 35 actually requires in the document, and the Article 36 step that most competitor guidance skips entirely.
DPIA vs PIA: Get the Terms Straight First
These get used interchangeably and they are not the same thing.
DPIA (data protection impact assessment) is the GDPR Article 35 instrument. It is legally mandatory once a high-risk trigger is met. Not conducting one when required is an infringement in its own right, separate from anything that later goes wrong with the processing.
PIA (privacy impact assessment) is the older and broader term, most common in the US. For private companies it is generally voluntary, a good governance practice rather than a legal obligation. US federal agencies have their own statutory requirements under the E-Government Act, which is where the term originates.
Vendor marketing blurs the two constantly. If your processing touches EU or UK personal data, you need the DPIA answer, and "we do privacy impact assessments" is not a substitute for the Article 35 process.
The Screening Test: Is a DPIA Required?
Article 35(1) sets the general rule: a DPIA is required where processing is likely to result in a high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context, and purposes of the processing.
Article 35(3) then names three cases where one is always required.
The three statutory triggers
1. Systematic and extensive evaluation based on automated processing, including profiling, where decisions produce legal effects or similarly significantly affect the person.
Credit decisioning, automated hiring screens, insurance pricing, fraud scoring that blocks accounts. If a model's output changes what a person can access or obtain, this trigger is live.
2. Large-scale processing of special category data (Article 9) or criminal offence data (Article 10).
Special category data covers health, biometrics used for identification, genetic data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, and sex life or orientation. Health data at scale is the common one for SaaS.
3. Systematic monitoring of a publicly accessible area on a large scale.
CCTV, but also location tracking and anything that observes people in public spaces continuously.
Beyond the three
Supervisory authorities publish their own lists of operations requiring a DPIA, and those lists vary by country. Common additions include large-scale profiling, innovative use of new technology, data matching across sources, and processing involving vulnerable data subjects such as children or employees.
The European Data Protection Board's criteria are the practical working tool: where processing meets two or more of nine listed criteria, a DPIA is generally expected.
The practical rule
Where the answer is genuinely borderline, run the assessment and document why you concluded what you did.
A short DPIA on processing that turns out to be low risk costs a few hours. Explaining to a supervisory authority why you skipped one on processing they consider high risk costs considerably more, and the reasoning record is itself the defense.
What Article 35(7) Requires in the Document
The regulation sets a minimum content standard. Four elements, and a DPIA missing any of them is incomplete.
1. A systematic description of the processing
What data, about whom, why, how, for how long, and who receives it. Include the lawful basis under Article 6, and for special category data the additional Article 9 condition.
This section should draw from your record of processing activities rather than being written from scratch. If your RoPA is current, most of this is a copy.
Include the legitimate interest pursued by the controller where that is your basis. Article 35(7)(a) names it specifically.
2. An assessment of necessity and proportionality
This is the section that gets skipped, and it is the one regulators scrutinize.
Necessity asks whether you could achieve the same purpose with less data, less intrusion, or shorter retention. Proportionality asks whether the intrusion is justified by the benefit.
Answering honestly sometimes means changing the plan. That is the point of doing the assessment before you build, rather than documenting a decision already made.
Cover your data minimization, retention periods, how you will honor data subject rights, and your international transfer mechanism if relevant.
3. An assessment of the risks to the rights and freedoms of data subjects
The crucial word is their rights, not your risks. This is not a business risk register.
Risks to individuals include discrimination, identity theft, financial loss, reputational damage, loss of confidentiality, being denied a service or opportunity, loss of control over their own data, and chilling effects on their behavior.
Rate each by likelihood and severity. Use whatever scale your organization already uses for risk so the outputs are comparable.
4. The measures addressing the risks
For each identified risk, what you will do about it: safeguards, security measures, and mechanisms that protect personal data and demonstrate compliance.
Then record the residual risk that remains after those measures. This number drives the Article 36 decision below, so do not leave it implicit.
Two procedural requirements
Consult your DPO. Article 35(2) requires you to seek the DPO's advice where one is designated. Record the advice and what you did with it. If you are unsure whether you need a DPO at all, see when a SaaS company needs a data protection officer.
Seek data subjects' views where appropriate. Article 35(9) requires seeking the views of data subjects or their representatives where appropriate, unless it would prejudice commercial interests or security. For employee monitoring, this usually means consulting a works council or employee representatives.
Article 36: The Step Most Guidance Skips
Here is the part that competitor content routinely omits, and it is the one with the hard legal consequence.
If your DPIA concludes that the processing would result in a high risk in the absence of measures taken to mitigate it, and you cannot bring the residual risk down, Article 36 requires you to consult your supervisory authority before you start processing.
This is prior consultation, and it works like this:
- You submit the DPIA and supporting information to the authority
- The authority has a statutory response window, extendable for complex cases
- If it considers the processing would infringe GDPR, it provides written advice and may use its corrective powers, up to banning the processing
The practical consequence for a product team is a schedule risk. If you hit this threshold and only discover it a week before launch, launch moves. The way to avoid that is to run the DPIA early enough that a prior consultation would still fit in the timeline.
Most DPIAs never reach this point, because mitigation brings residual risk below the threshold. But the decision has to be made explicitly and recorded, not assumed away.
Running One Assessment for GDPR and US State Requirements
This is the section that matters for a US company, and almost nothing in the regulator-dominated guidance addresses it.
US state privacy law has converged on a documented risk assessment duty for certain processing, and California's regulations add their own, with real filing deadlines attached. That creates a choice: run two assessment programs, or build one that satisfies both.
Build one. The analytical core is genuinely shared:
- Describe the processing activity and the data involved
- Identify who is affected and how
- Weigh the benefits of the processing against the risks to individuals
- Document safeguards that reduce those risks
- Record what remains
The differences are real but they are at the edges: which processing triggers an assessment, precisely what content is mandated, how long records are kept, and critically whether anything must be submitted to a regulator rather than just retained. GDPR's Article 36 consultation is exception-driven. California's regime includes affirmative filing obligations on a schedule.
The practical build: one template carrying the union of required fields, with jurisdiction-specific sections that activate based on where the data subjects are. One process, one owner, one review cadence. The alternative is two teams writing overlapping documents about the same product feature, which is how assessments go stale.
For the California requirements specifically, including what has to be filed and when, see CPRA regulations and the 2026 CCPA rules.
Common Failure Modes
Treating it as a security review. A DPIA that only discusses encryption and access control has not addressed Article 35(7)(c) at all. Security is one category of mitigation, not the assessment.
Running it after the build. A DPIA is a design instrument. Run after launch, it documents decisions instead of shaping them, and if it surfaces an Article 36 trigger you are already processing.
Assessing company risk instead of individual risk. Regulatory fines and reputational damage to you are not the subject. Harm to the individual is.
Writing it once and filing it. Article 35(11) requires review where the risk changes. Material changes to the processing mean revisiting the assessment.
No named owner. DPIAs with no owner do not get reviewed. Assign one, with the review cadence written into the document.
For the wider GDPR program this sits inside, see the GDPR compliance checklist and the GDPR service page. The DPIA draws directly on your record of processing activities, and your vendor arrangements should already be covered by a GDPR data processing agreement. For the California analog and its filing deadlines, see CPRA regulations.
Frequently Asked Questions
What is a data protection impact assessment? A documented process for identifying and reducing the privacy risks of a processing activity before you start it. GDPR Article 35 requires one when processing is likely to result in a high risk to individuals. It is not a security review: it asks what the processing does to people, whether it is necessary and proportionate, and what you will change to lower the risk.
How do I know if a DPIA is required? Run the Article 35(3) test: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale special category or criminal offence data, or large-scale systematic monitoring of a public area. Supervisory authorities publish additional lists. When it is borderline, do the assessment and document the reasoning.
How do you perform a data protection impact assessment? Work through the Article 35(7) content in order: describe the processing, assess necessity and proportionality, identify risks to individuals, and record the measures and residual risk. Consult your DPO and, where appropriate, data subjects. If high risk remains after mitigation, Article 36 requires consulting your supervisory authority before starting.
Is a PIA legally required? Depends which term is meant. A privacy impact assessment is the older US term and is generally voluntary for private companies. A DPIA under GDPR Article 35 is mandatory once a high-risk trigger is met, and failing to conduct one is itself an infringement.
Does a GDPR DPIA satisfy US state risk assessment requirements? Not automatically, but one process can serve both. The analytical core is shared. The differences are in trigger conditions, mandated content, retention, and whether anything must be filed with a regulator. Build one template with the union of required fields rather than two programs.
Need a DPIA Process That Works for Both Regimes?
ShieldKey Solutions builds privacy assessment programs for US SaaS companies with EU exposure: one screening test, one template, one review cadence covering GDPR Article 35 and the US state risk assessment duties. We start with the processing you already run and tell you which activities actually trigger an assessment.