DPIA vs PIA: what's the difference?

Quick definitions

A DPIA is a structured assessment that identifies, evaluates, and documents the privacy risks of a specific processing activity, then sets out mitigations. The legal source is GDPR Article 35, which makes DPIAs mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons."

A PIA is the older, broader concept. The U.S. federal government has required PIAs for agency information systems since the E-Government Act of 2002. Outside the EU, the term "PIA" tends to describe any structured analysis of a processing activity's privacy implications — whether legally required or done as voluntary good practice.

Side-by-side

The state-privacy-law twist

Since 2023 the U.S. state privacy laws have been quietly mandating PIA-equivalents under different names:

• Virginia VCDPA — "Data protection assessments" required for targeted advertising, sale of personal data, processing of sensitive data, processing for profiling that presents reasonably foreseeable risk, and any processing involving heightened risk.
• Colorado CPA — Same triggers, very similar content requirements; Attorney General may request the assessment.
• Connecticut CTDPA, Texas TDPSA, Oregon OCPA, Tennessee TIPA — All require data protection assessments on substantially the same triggers as Virginia and Colorado.

If you operate in multiple U.S. states and in Europe, your DPIA template needs to satisfy GDPR Art. 35 and the state-law assessment requirements. The good news: the content overlap is roughly 90%. You write one document and label sections to cross-walk to whichever statute the auditor asks about.

When you have to do one

Always do a DPIA when…

• You're processing special categories of personal data (health, biometrics, ethnicity, etc.) at scale.
• You're doing systematic monitoring — CCTV at scale, employee monitoring, online behavioural tracking.
• You're using automated decision-making with legal effects — credit scoring, automated hiring decisions, eligibility determinations.
• You're processing data about vulnerable individuals — children, employees, asylum seekers, patients.
• You're using novel technology the organisation hasn't assessed before — LLMs in customer support, on-device biometric matching, federated learning.
• You're denying access to a service based on automated processing.

You should probably do one when…

• You're adding a new vendor / sub-processor that will access personal data — even routine ones. A short DPIA documents your basis for trusting the vendor and feeds your sub-processor list.
• You're launching a new feature that changes what data you collect or how you use it.
• A regulator has changed enforcement posture in your sector (e.g., the Italian Garante's pattern of investigating AI vendors).

What goes in one

Under GDPR Article 35(7), a DPIA must contain at least:

1. A systematic description of the processing — what data, whose data, why, how, where stored, retention period, recipients.
2. An assessment of necessity and proportionality — is this processing genuinely needed, is the data minimal, is the purpose specific.
3. An assessment of the risks to data subjects — likelihood × severity for each identified risk, scored.
4. The measures envisaged to address those risks — technical and organisational mitigations, mapped to each risk.

U.S. state law assessments require substantially the same. PIAs done under U.S. federal practice add fields specific to government systems (system of records notice, FISMA classification, Privacy Act SORN reference).

The practical workflow most teams use in 2026

1. Screen first. Use a short trigger checklist to decide whether a full DPIA is actually required. Most processing isn't high-risk; over-doing DPIAs is the single most common cause of privacy-team burnout. Our DSAR deadline calculator has a sibling we're shipping soon for DPIA threshold screening.
2. Draft from a template. Whether AI-assisted or not, use a structured template with the Art. 35(7) sections so nothing gets missed.
3. Score risks consistently. A 3×3 likelihood/severity grid (low/medium/high on each axis) gives you a defensible structure without false precision.
4. Map mitigations to risks. Every "high" or "medium" residual risk needs a named mitigation owner and a target date.
5. Review and approve. The DPO (where one exists) or the privacy lead signs off. For high residual risk, prior consultation with the supervisory authority is required.
6. Keep it live. Update when the processing changes, when a vendor changes, or when a regulator changes enforcement posture.

How Privacy Automated handles both

Privacy Automated treats DPIA and PIA as the same artefact under different labels. You describe the processing activity in plain language and the AI produces an Article 35-defensible draft — screening, scored risk register, mitigations, and a recommendation — in about 10 minutes. You review and approve. The approved assessment syncs into your Records of Processing register automatically, so the RoPA never falls out of sync with what you've actually assessed. See the DPIA section of our product tour for what the risk register looks like in practice.