Last updated: 7 November 2026
Quick answer: A privacy impact assessment (PIA) is a broad, often voluntary review of how a project affects privacy. A data protection impact assessment (DPIA) is the specific assessment required by Article 35 GDPR and UK GDPR when processing is likely to result in high risk to individuals. Every DPIA is a type of PIA, but not every PIA meets DPIA requirements.
The privacy impact assessment vs DPIA question comes up in almost every multinational privacy programme. The terms are often used interchangeably, yet they come from different legal traditions and carry different obligations.
If you work across the EU, UK and US, the distinction matters. A PIA written to a US federal template or an internal standard may not satisfy a European regulator, and a DPIA built only for GDPR may miss what a US state law asks for. This guide explains the differences, when each is required and how to run one assessment process that covers both.
Privacy impact assessment vs DPIA: what is the difference?
The main difference is legal status. “PIA” is a general term for any structured assessment of privacy risk in a project, system or process. “DPIA” is a legal term under the GDPR, with a defined trigger, minimum content and consequences if you skip it.
In practice, a PIA tends to ask “what are the privacy implications of this project?”, while a DPIA asks “is this processing likely to result in a high risk to the rights and freedoms of individuals, and have we reduced that risk to an acceptable level?”
| Aspect | Privacy impact assessment (PIA) | Data protection impact assessment (DPIA) |
|---|---|---|
| Origin | Privacy practice, government programmes, standards such as ISO/IEC 29134 | Article 35 GDPR and UK GDPR |
| Legal status | Mandatory only where a specific law requires it | Mandatory when processing is likely to result in high risk |
| Focus | Privacy broadly, often including compliance and reputational risk | Risks to the rights and freedoms of natural persons |
| Trigger | Set by policy, contract or a sector law | High-risk processing, including the Article 35(3) cases and national lists |
| Minimum content | Varies by template | Defined in Article 35(7) |
| Regulator involvement | Rare | Prior consultation under Article 36 if high residual risk remains |
| Timing | Varies, ideally at design stage | Before the processing starts |
Common mistake: Renaming an existing PIA template as a “DPIA” without checking it against Article 35(7). If the template does not assess necessity and proportionality or risks to individuals, it is not a DPIA, whatever the title says.
What is a DPIA under the GDPR?
A DPIA is a process to identify and minimise the data protection risks of processing that is likely to result in a high risk to individuals. It is set out in Article 35 of the General Data Protection Regulation.
When is a DPIA required?
Article 35(1) requires a DPIA where a type of processing, in particular using new technologies, is likely to result in a high risk. Article 35(3) names three cases where a DPIA is always required:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects
- Large-scale processing of special category data or criminal offence data
- Systematic monitoring of a publicly accessible area on a large scale
Supervisory authorities also publish lists of processing that requires a DPIA under Article 35(4). The Article 29 Working Party guidelines, endorsed by the EDPB on 25 May 2018, set out nine criteria for high risk and suggest that processing meeting two of them will usually need a DPIA.
What must a DPIA contain?
Article 35(7) sets the minimum content:
- A systematic description of the processing and its purposes, including any legitimate interest pursued
- An assessment of the necessity and proportionality of the processing
- An assessment of the risks to the rights and freedoms of data subjects
- The measures envisaged to address those risks, including safeguards and security measures
The controller must seek the advice of the data protection officer, where one is designated, under Article 35(2). If the DPIA shows high risk that the controller cannot mitigate, Article 36 requires prior consultation with the supervisory authority before processing starts.
Failing to carry out a required DPIA is an infringement subject to fines under Article 83(4) of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Our step-by-step DPIA guide covers the process in detail.
What is a privacy impact assessment?
A PIA is any structured analysis of how a project collects, uses, shares and protects personal information, and how that affects privacy. The term predates the GDPR and is used in many jurisdictions and standards.
US federal agencies
In the US, Section 208 of the E-Government Act of 2002 requires federal agencies to conduct PIAs before developing or procuring IT that collects, maintains or disseminates information in identifiable form, or before initiating new collections. Agencies must generally make their PIAs publicly available, subject to security and sensitivity exceptions.
International standard
ISO/IEC 29134:2023 gives guidelines for a PIA process and for the structure and content of a PIA report. It is a practical reference if you want a structured, non-jurisdictional PIA method.
Internal privacy by design
Many organisations run lighter PIAs as a screening step for every new project, then escalate to a full DPIA only when high-risk indicators appear.
How do the EU, UK and US approaches compare?
The EU and UK use the DPIA as a legal requirement; the US has no general federal PIA duty for the private sector but a growing number of state-law risk assessment requirements.
| Jurisdiction | Term used | Legal basis | Key point |
|---|---|---|---|
| EU | DPIA | GDPR Article 35 | Mandatory for likely high-risk processing; national DPIA lists apply |
| UK | DPIA | UK GDPR Article 35 | Same core test; ICO guidance and screening checklists |
| US federal agencies | PIA | E-Government Act of 2002, Section 208 | Required for new IT systems handling identifiable information; published |
| US, California | Risk assessment | CCPA regulations effective 1 January 2026 | Required for processing that presents significant risk; attestation to the CPPA by 1 April 2028 |
| Other US states | Data protection assessment | State comprehensive privacy laws | Required for certain higher-risk activities under several laws |
In the UK, the ICO’s DPIA guidance walks through the process from screening to sign-off, and explains when you must consult the ICO.
In California, the privacy agency finalised regulations on 23 September 2025 that require risk assessments from 1 January 2026, with attestations and summaries due to the agency by 1 April 2028. See our CCPA framework page for scope.
In practice: If you operate in both regions, a DPIA that meets Article 35(7) will cover much of what a California risk assessment asks, but check the California-specific content and submission duties separately.
Can one assessment satisfy both PIA and DPIA requirements?
Yes, if you design it that way. The simplest approach is a tiered process: a short screening PIA for every project, which escalates to a full DPIA when high-risk criteria are met.
A tiered assessment template
- Screening (all projects). What personal data, whose data, which purpose, which systems and vendors, any cross-border transfers? Does any Article 35(3) case, national list item or two or more high-risk criteria apply? Does a US state risk assessment trigger apply?
- Description (full DPIA). Nature, scope, context and purposes of processing, data flows, retention, and a link to the relevant entry in your record of processing activities.
- Necessity and proportionality. Lawful basis, data minimisation, retention limits, transparency, rights handling and processor contracts.
- Risk assessment. Likelihood and severity of harm to individuals, such as discrimination, financial loss, loss of control or physical harm.
- Measures. Technical and organisational measures, with owners and deadlines, and the residual risk after each.
- Sign-off. DPO advice recorded, decision by the accountable owner, and prior consultation if high residual risk remains.
- Review. A review date and change triggers, such as a new vendor, new data category or new purpose.
Linking assessments to your enterprise risk register keeps privacy risks visible to the same people who own security and operational risk.
If you want to try this tiered approach in one workspace, you can start your 14-day free trial and run your first DPIA alongside your ROPA.
When should you run a PIA instead of a DPIA?
Run a lighter PIA when a project involves personal data but does not meet high-risk criteria, or when you operate outside GDPR scope and no law requires a specific assessment. Examples include:
- A new internal tool that processes limited employee contact data
- A minor change to an existing, already assessed system
- A US-only project with no state-law assessment trigger
- Vendor onboarding where only business contact data is shared
Record the screening result either way. Under GDPR accountability, documenting why a DPIA was not needed is as important as the DPIA itself.
Common mistake: Running the DPIA after launch. Article 35(1) requires the assessment prior to the processing. A retrospective DPIA can still reduce risk, but it will not cure the original failure.
Key takeaways
- A PIA is a general privacy assessment; a DPIA is the specific legal assessment under Article 35 GDPR and UK GDPR.
- A DPIA is mandatory for processing likely to result in high risk and must include the four elements in Article 35(7).
- US federal agencies must run PIAs under the E-Government Act, and California has required risk assessments since 1 January 2026.
- A tiered process, screening PIA then full DPIA, covers EU, UK and US requirements with one workflow.
- Always document the screening decision, even when no DPIA is needed.
Frequently asked questions
Is a PIA the same as a DPIA?
Not quite. A DPIA is a specific type of privacy impact assessment defined by Article 35 GDPR and UK GDPR, with mandatory triggers and minimum content. A PIA is a broader term for any structured privacy review. A PIA can meet DPIA requirements if it includes the Article 35(7) elements, but many PIA templates do not.
When is a DPIA mandatory?
A DPIA is mandatory when processing is likely to result in a high risk to individuals’ rights and freedoms. Article 35(3) names three cases: automated evaluation with significant effects, large-scale special category or criminal data, and large-scale systematic monitoring of public areas. National supervisory authority lists and the EDPB-endorsed criteria identify other cases.
Do US companies need to do PIAs?
There is no general federal PIA requirement for private companies. Federal agencies must conduct PIAs under Section 208 of the E-Government Act of 2002. Private companies may need risk assessments under state laws, such as the California regulations effective 1 January 2026, and data protection assessments under several other state privacy laws.
What happens if we skip a required DPIA?
Failing to carry out a required DPIA infringes Article 35 GDPR and can lead to fines under Article 83(4) of up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher. Regulators may also order you to stop processing until the risks have been properly assessed and mitigated.
Who should carry out a DPIA?
The controller is responsible, usually through the business or project owner, with input from IT, security and any processors involved. Where a data protection officer has been designated, the controller must seek their advice under Article 35(2). The DPO advises and monitors, while the decision to accept residual risk generally sits with the business owner.
Choosing the right assessment
The privacy impact assessment vs DPIA debate is mostly about terminology, but the legal consequences are real. Treat the DPIA as the European legal standard, use PIAs as a screening and governance tool, and build one tiered process that also captures US state-law triggers. Our GDPR ROPA guide explains how to connect assessments to your processing records.
Enactia’s AI-powered GRC platform links DPIAs, ROPA, vendor reviews and risks across GDPR, UK GDPR and US privacy laws. To see it with your own templates, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
