Privacy Impact Assessment Guide: What to Include and When a DPIA Is Required

Every new system, vendor, AI use case, analytics tool, or data-sharing project can change how personal data is collected, used, stored, or shared. A Privacy Impact Assessment (PIA) helps organizations identify those privacy risks before the project goes live, when the risks are still easier and cheaper to fix.

A Data Protection Impact Assessment (DPIA) is the formal version required under GDPR Article 35 when processing is likely to result in a high risk to individuals’ rights and freedoms. In simple terms, a PIA is a privacy risk review; a DPIA is the legally required version for high-risk processing.

This compressed guide covers only the mandatory information: what a PIA is, how it differs from a DPIA, when a DPIA is required, what it must include, who should be involved, and the practical steps to complete one.

What Is a Privacy Impact Assessment?

A Privacy Impact Assessment is a structured process used to identify, assess, and reduce privacy risks in a project that involves personal data. It should be completed before processing starts or before a major change is introduced.

1. What personal data is processed? This includes data categories, sources, volume, retention, access, and sharing.
   
2. What risks could affect individuals? This includes loss of control, unfair profiling, discrimination, financial harm, reputational harm, or security exposure.
   
3. How will those risks be reduced? This includes data minimization, access controls, encryption, shorter retention, contractual safeguards, or alternative designs.
   

The purpose of a PIA is not to stop projects. It is to make privacy risks visible early, document decisions, and prove that the organization considered privacy by design before launch.

In practice, many organizations use one assessment workflow for both PIAs and DPIAs, then apply stricter DPIA requirements whenever the processing is high risk.

PIA vs DPIA: The Mandatory Difference

A PIA is a broad privacy risk assessment used as good practice across many jurisdictions.

A DPIA is required by GDPR Article 35 when processing is likely to result in high risk. The key difference is legal obligation: a PIA may be optional depending on the context, but a DPIA is mandatory when GDPR high-risk triggers apply.

When Is a DPIA Required?

Under GDPR Article 35, a DPIA is required when the planned processing is likely to result in a high risk to individuals’ rights and freedoms. This assessment must happen before the processing begins.

A DPIA is always required for three major categories: systematic and extensive automated profiling with legal or similarly significant effects; large-scale processing of special category data or criminal offence data; and systematic monitoring of a publicly accessible area on a large scale.

Regulator guidance also treats several processing activities as high risk, including innovative technology, large-scale profiling, biometric data, genetic data, data matching, invisible processing, behavioural or location tracking, children’s or vulnerable people’s data, and processing that could create physical harm.

If the DPIA shows that high residual risks remain even after mitigation, GDPR Article 36 requires prior consultation with the supervisory authority before processing starts.

Skipping a required DPIA can expose the organization to regulatory action and fines of up to €10 million or 2% of global annual turnover, whichever is higher.

What Must a DPIA Include?

Required area	What to document
Description of processing	Purpose, data categories, data subjects, source, recipients, systems, retention, access, transfers, and data flow.
Necessity and proportionality	Why the processing is needed, whether less data could be used, legal basis, retention limits, and alignment with privacy principles.
Risk assessment	Risks to individuals, likelihood, severity, affected groups, and possible harms.
Mitigation measures	Safeguards such as encryption, access controls, minimization, pseudonymization, deletion rules, contracts, training, and monitoring.
Outcome and sign-off	Residual risk, DPO advice, business owner approval, decision to proceed, and review date.

How to Conduct a PIA or DPIA

A practical PIA/DPIA does not need to be complex, but it must be complete. Use the following process as the core workflow.

1. Screen the Project

Start with a short privacy threshold assessment. Confirm whether the project uses personal data, whether the processing is new or materially changed, and whether any high-risk trigger applies. The outcome should be one of three decisions: no assessment needed, PIA needed, or full DPIA required.

2. Describe the Processing

Document what the project does, what personal data it uses, who the data subjects are, where the data comes from, where it goes, who can access it, how long it is kept, and whether any processors or third parties are involved. If the data flow cannot be clearly explained, the assessment is not ready.

3. Assess Necessity and Proportionality

Check whether the project really needs the data it plans to use. Ask whether the same goal can be achieved with less data, fewer people, shorter retention, anonymized or pseudonymized data, or a less intrusive method.

4. Identify Privacy Risks

Assess the risk from the individual’s perspective, not only the organization’s perspective. Common risks include unauthorized access, excessive collection, unfair profiling, inaccurate decisions, data being used for new purposes, excessive retention, re-identification, or loss of control over personal data.

5. Define Mitigation Measures

For each risk, document the safeguards that reduce likelihood or impact. Examples include encryption, role-based access, data minimization, retention limits, vendor contracts, audit logs, staff training, user notices, consent flows, or design changes.

6. Record the Decision and Sign Off

Record the residual risk after mitigation, the DPO’s advice where applicable, the project owner’s approval, and the final decision. If high residual risk remains, consult the supervisory authority before launch.

7. Review and Update

A PIA or DPIA is not a one-time document. Review it when the project changes, when new data sources are added, when vendors change, when risks increase, or on a regular review cycle.

Who Should Be Involved?

A good assessment needs input from both privacy and business teams. The project owner explains the purpose and processing. The DPO or privacy lead reviews the privacy risks. Legal confirms obligations. Security reviews technical controls. IT or product teams explain systems and data flows. Procurement or vendor risk teams review processors and third-party safeguards.

For DPIAs, DPO consultation is mandatory where a DPO is designated. Where appropriate, organizations should also seek views from affected individuals or their representatives, unless doing so would be disproportionate or undermine the purpose of the processing.

Practical PIA/DPIA Checklist

Use this checklist before approving a project that involves personal data:

1. Confirm whether the project processes personal data.
   
2. Run a privacy threshold assessment for new or materially changed processing.
   
3. Check whether any GDPR high-risk trigger applies.
   
4. If high-risk processing applies, complete a DPIA before launch.
   
5. Describe the processing, data flow, data subjects, systems, recipients, and retention.
   
6. Assess necessity, proportionality, and data minimization.
   
7. Identify risks to individuals and rate likelihood and severity.
   
8. Document mitigation measures and residual risk.
   
9. Consult the DPO where required.
   
10. Escalate to the supervisory authority if high residual risk remains.
    
11. Record sign-off, ownership, and review date.
    

A PIA, done well, is one of the cheapest privacy controls an organization has. It catches problems at design time, creates evidence of accountability, and helps teams avoid privacy risks becoming regulatory, operational, or reputational issues after launch.