Privacy impact assessments are one of the most misunderstood compliance obligations in data protection law. Organizations routinely confuse the two terms, use them interchangeably in their internal documentation, or assume that completing one satisfies the requirements of the other. That confusion can be costly.
What Is a Privacy Impact Assessment (PIA)?
A Privacy Impact Assessment is a systematic process for identifying, evaluating, and addressing the privacy risks that a project, system, product, or data processing activity creates for the individuals whose information is involved. It asks a fundamental question: what could go wrong with this data, and what are we doing to prevent it?
PIAs are a general best-practice tool. They are not tied to any single law or regulation. Organizations in almost every sector — technology, healthcare, financial services, retail, government — use them to document their approach to privacy risk before launching new initiatives, adopting new vendors, or making significant changes to existing data processes.
A well-executed PIA looks at what personal data is collected and why, where it flows and who can access it, how it is secured and how long it is retained, what rights individuals have over it, and whether the collection is necessary and proportionate to the stated purpose. The output is typically a documented record that can be used internally to guide risk mitigation decisions, and externally as evidence of a good-faith compliance posture.
Importantly, PIAs are not a one-time exercise. The data processing landscape changes constantly — through new regulations, new technologies, new vendors, and evolving threat environments. A mature privacy program treats the PIA as a living document that is reviewed and updated regularly.
When Is a PIA Required?
The trigger conditions for a PIA vary by jurisdiction and sector. Here is a breakdown of the primary legal frameworks that impose PIA obligations.
U.S. Federal Law: The E-Government Act of 2002
U.S. federal government agencies are required to conduct PIAs under the E-Government Act of 2002 whenever they develop, procure, or significantly modify an information technology system that collects, maintains, or disseminates personal information. The requirement also applies when an agency issues a new or updated rule that affects how personal information is handled. The PIA must be completed before deployment and made publicly available.
U.S. State Privacy Laws
The majority of U.S. state comprehensive privacy laws now require some form of privacy risk assessment for “high-risk” processing activities. While the specific terminology varies — some laws call them “data protection assessments” rather than PIAs — the substantive obligation is the same. States with these requirements include:
- California (CPRA/CCPA): Data protection assessments required for targeted advertising, sale of personal information, profiling, sensitive data processing, and any processing presenting significant risk.
- Colorado: Required for processing that presents a heightened risk of harm, including targeted advertising, sale of data, profiling, and sensitive data.
- Connecticut, Delaware, Virginia, Texas, Indiana, Montana, New Hampshire, New Jersey, Oregon, Tennessee, and Florida all have similar requirements with jurisdiction-specific thresholds and definitions.
Compliance tip: If your organization operates across multiple U.S. states, you likely need a privacy risk assessment framework that can satisfy multiple state law triggers simultaneously. Captain Compliance’s DPIA solution is built to scale across jurisdictions.
Canada: PIPEDA and Provincial Laws
Under Canada’s federal private-sector privacy law (PIPEDA), organizations are not universally required to complete PIAs, but federal institutions must conduct them under the Privacy Act when implementing new programs or systems that involve personal information. Several provinces, including Alberta and British Columbia, have their own requirements for public bodies. Best-practice guidance from the Office of the Privacy Commissioner recommends PIAs for any private-sector initiative involving significant personal data processing.
Australia and New Zealand
Australia’s Privacy Act encourages PIAs for agencies and large private-sector organizations undertaking new projects with significant privacy impacts. New Zealand’s Privacy Act 2020 similarly recommends privacy impact assessments for high-risk projects, and completing one is considered a best-practice indicator of compliance readiness.
What Is a Data Protection Impact Assessment (DPIA)?
A Data Protection Impact Assessment is a specific, legally mandated type of privacy assessment required under Article 35 of the General Data Protection Regulation (GDPR). If a PIA is a general health check for any data-related initiative, a DPIA is the intensive clinical workup required when the initial screening signals serious risk.
The DPIA requirement reflects one of the GDPR’s foundational principles: data protection by design and by default. The regulation does not simply require organizations to fix privacy problems after they occur. It requires them to systematically identify and address those problems before processing begins. The DPIA is the mechanism through which that obligation is fulfilled for high-risk processing.
Unlike a PIA, which gives organizations substantial flexibility in format and depth, a DPIA has minimum legal requirements. It must include a systematic description of the processing, an assessment of its necessity and proportionality, an evaluation of the risks to data subjects’ rights and freedoms, and the measures envisaged to address those risks. If you have a Data Protection Officer (DPO), their consultation is mandatory and must be documented.
The UK GDPR, which applies in Great Britain post-Brexit, contains identical DPIA requirements under Article 35 of the UK GDPR, so organizations operating in both the EU and UK face parallel obligations.
When Is a DPIA Required?
GDPR Article 35(1) states that a DPIA is required when processing “is likely to result in a high risk to the rights and freedoms of natural persons.” The regulation then provides three specific scenarios that always require a DPIA, plus a general high-risk standard.
The Three Automatic Triggers Under GDPR Article 35(3)
- Systematic and extensive profiling with significant effects: Automated decision-making or profiling that significantly affects individuals — such as credit scoring, algorithmic hiring, automated insurance pricing, or behavioral advertising based on detailed profiles.
- Large-scale processing of special category data: Processing health data, biometric data, genetic data, data concerning sexual orientation, religious beliefs, racial or ethnic origin, political opinions, or criminal records at scale. “Large scale” is assessed based on the number of individuals, volume of data, geographic scope, and duration of processing.
- Systematic monitoring of publicly accessible areas: Large-scale CCTV networks, facial recognition systems, license plate recognition, or other surveillance technologies in public spaces.
Additional High-Risk Activities Identified by Supervisory Authorities
Beyond the three automatic triggers, data protection authorities have published lists of processing activities they consider likely to require a DPIA. These commonly include:
- Use of innovative technology (AI/ML systems, IoT devices, connected health devices).
- Processing data about vulnerable individuals, including children.
- Data matching or combining datasets across different controllers.
- Processing in contexts where individuals cannot reasonably anticipate how their data will be used (“invisible processing”).
- Tracking individuals’ location or behavior across digital platforms.
- Targeting children or other vulnerable populations in marketing.
Important: If you are unsure whether a DPIA is required for a specific processing activity, the safer default is to conduct one. The GDPR does not penalize organizations for conducting an unnecessary DPIA. It does penalize them for skipping a required one.
Pre-Consultation with the Supervisory Authority
When a DPIA reveals that high risks remain even after implementing mitigation measures, Article 36 of the GDPR requires the controller to consult with the relevant supervisory authority before beginning processing. The supervisory authority then has eight weeks to provide written advice (extendable to 14 weeks for complex cases). This prior consultation mechanism is one of the most significant procedural differences between a DPIA and a general PIA.
PIA vs DPIA: Key Differences at a Glance
| Feature | PIA (Privacy Impact Assessment) | DPIA (Data Protection Impact Assessment) |
|---|---|---|
| Legal basis | Voluntary best practice; required by some non-GDPR laws (U.S. E-Gov Act, state privacy laws, PIPEDA) | Mandatory under GDPR Article 35 for high-risk processing; also required under UK GDPR |
| Geographic scope | Applies across multiple jurisdictions and frameworks globally | Primarily GDPR/UK GDPR jurisdiction; U.S. state laws use similar “data protection assessment” requirements |
| When it’s required | Based on organizational policy, regulatory mandate, or risk-based judgment | Before any processing likely to result in high risk to individuals’ rights and freedoms |
| Format and content | Flexible; determined by the organization or applicable framework | Must meet minimum GDPR Art. 35 requirements: description, necessity/proportionality, risk assessment, mitigations |
| DPO involvement | Recommended but not legally required | Mandatory under GDPR Art. 35(2) if a DPO exists; input must be documented |
| Supervisory authority involvement | Generally internal; regulators may request during investigations | Required prior consultation under Art. 36 if residual risks remain high |
| Timing | Before or during project/system development | Must be completed before high-risk processing begins — not retrospectively |
| Documentation standards | Flexible; tailored to organizational needs | Must be sufficiently detailed to demonstrate GDPR compliance to a supervisory authority |
| Data subject consultation | Optional but recommended | Must be considered; “where appropriate,” data subjects or their representatives should be consulted |
| Legal consequences for non-compliance | Varies; may indicate poor governance; not directly a GDPR violation if GDPR doesn’t apply | Direct GDPR violation under Art. 83(4); fines up to €10M or 2% of global annual turnover |
| Relationship between the two | Broader category — all DPIAs are a form of PIA | A specialized, legally defined subset of the PIA concept |
What Each Assessment Must Include
PIA: Core Components
Because PIAs are flexible in format, the specific contents vary by jurisdiction and organizational context. However, every effective PIA should address the following areas:
- Scope and description: What project, system, or processing activity is being assessed? What personal data is involved and why?
- Data flow mapping: Where does the data come from? Where does it go? Who has access? How long is it retained?
- Legal basis and purpose limitation: What legal basis justifies the processing? Is the data being used only for the stated purpose?
- Necessity and proportionality: Is the processing limited to what is necessary? Could the same purpose be achieved with less data?
- Risk identification: What could go wrong? Consider unauthorized access, data breaches, discrimination, loss of control, and inability to exercise rights.
- Risk mitigation measures: What technical and organizational measures are in place or planned to reduce each identified risk?
- Stakeholder input: Has input been gathered from legal, IT, security, and affected business units?
- Sign-off and accountability: Who approved the assessment and takes responsibility for implementing its recommendations?
- Review schedule: When will the assessment be revisited and updated?
DPIA: Legally Required Components Under GDPR Article 35
The GDPR specifies minimum requirements that every DPIA must include. These are not aspirational guidelines — they are legal obligations:
- Systematic description of the processing operations: This includes the nature, scope, context, and purposes of processing, as well as a description of the legitimate interests pursued where applicable. Data flows, system architecture, retention periods, and third-party relationships must all be documented.
- Assessment of necessity and proportionality: An explicit evaluation demonstrating that the processing is necessary for the stated purpose and that less privacy-invasive alternatives were considered and rejected.
- Assessment of risks to the rights and freedoms of data subjects: A detailed analysis of specific risks to individuals — not merely to the organization. This includes risks of unauthorized access, discrimination from automated decisions, inability to exercise statutory rights, financial harm, reputational damage, and other concrete impacts.
- Measures to address the risks: For each identified risk, documented measures to eliminate or reduce it, including technical safeguards (encryption, access controls, pseudonymization), organizational measures (training, policies, vendor contracts), and transparency measures (notices, consent mechanisms, rights fulfillment processes).
- DPO consultation: If the organization has a DPO, the DPO’s advice must be sought and documented. The DPO must also be given the opportunity to review the final DPIA.
- Data subject consultation: A consideration of whether to seek the views of data subjects or their representatives. If consultation was not undertaken, the reasons should be documented.
Best practice: Even if your DPIA concludes that risks are adequately mitigated, keep the document updated. If your processing changes materially — new data categories, new third-party processors, new purposes — you should reassess whether the existing DPIA still covers the activity accurately.
How to Conduct a PIA or DPIA: Step-by-Step
While a DPIA has stricter legal requirements than a general PIA, the practical process for conducting either assessment follows a similar logic. The steps below apply to both, with DPIA-specific requirements called out where they differ.
Step 1: Identify the trigger and determine the type of assessment needed. Start by evaluating whether the activity involves personal data at a scale or sensitivity level that requires formal assessment. For GDPR-regulated organizations, apply the three automatic DPIA triggers from Article 35(3) and check your supervisory authority’s published list. For U.S. operations, identify whether any applicable state law triggers a data protection assessment requirement. Document your trigger analysis even if you conclude no formal DPIA is needed — this creates a defensible record.
Step 2: Assemble a cross-functional team. Neither PIAs nor DPIAs should be completed in isolation. You will need input from legal and compliance, IT and security, the business unit owning the processing activity, procurement or vendor management if third parties are involved, and HR if employee data is in scope. For DPIAs, the Data Protection Officer must be involved and their input formally documented. For complex AI or machine learning deployments, technical subject matter experts are essential.
Step 3: Map the data flows. Create a detailed picture of how personal data enters, moves through, and exits your systems. Identify every data element collected, every system that touches it, every team member with access, every third-party processor or sub-processor involved, and every jurisdiction to which data is transferred. Data flow mapping is not just a DPIA requirement — it is the analytical foundation that makes the rest of the assessment meaningful. An accurate Record of Processing Activities (RoPA) is invaluable at this stage.
Step 4: Assess necessity and proportionality. For each category of personal data in scope, ask whether you genuinely need it to achieve your stated purpose. Could you use less data, anonymized data, or aggregated data instead? Is the retention period the minimum necessary? Is any data being repurposed beyond the original collection context? Document your reasoning. For DPIAs, this analysis must be explicit and sufficient to demonstrate to a regulator that less privacy-invasive alternatives were genuinely evaluated.
Step 5: Identify and evaluate privacy risks. Think from the data subject’s perspective. Beyond security breaches, consider risks of discrimination from algorithmic decisions, financial harm, inability to exercise statutory rights, loss of control over personal information, psychological harm, and reputational damage. Rate each identified risk by likelihood and severity. For DPIAs, this analysis must be systematic and must consider risks to rights and freedoms specifically — not just organizational risks or regulatory exposure.
Step 6: Design and document mitigation measures. For each identified risk, determine the specific technical and organizational measures you will implement to eliminate or reduce it. Be concrete: “we will encrypt data in transit and at rest using AES-256,” not “we will improve security.” Document which residual risks remain after mitigation and assess whether those residual risks are acceptable. For DPIAs, if residual risks remain high and cannot be adequately addressed, you must consult the supervisory authority under GDPR Article 36 before beginning processing.
Step 7: Consult the DPO and relevant stakeholders. For DPIAs, DPO consultation is a legal requirement under Article 35(2). The DPO’s role is advisory — they do not conduct the DPIA themselves, and they are not responsible for its conclusions — but their advice must be sought, documented, and taken into account. Disagreements between the controller and the DPO should also be recorded. For PIAs, DPO or privacy counsel consultation is a best practice even when not legally required.
Step 8: Document, obtain sign-off, and implement. Compile the complete assessment into a formal record. Obtain sign-off from the responsible executive or decision-maker. Then ensure that the mitigation measures documented in the assessment are actually implemented — not just promised. A PIA or DPIA that identifies risks but leads to no action is worse than useless: it creates a paper trail demonstrating you knew about the problem and did nothing.
Step 9: Monitor, review, and update. Set a review schedule. Revisit the assessment whenever the processing activity changes materially, when new risks emerge, when the regulatory landscape shifts, or at minimum on an annual cycle. For DPIAs, Article 35(11) explicitly states that controllers must carry out a review to assess whether processing is performed in compliance with the DPIA, at least when there is a change in the risk represented by processing operations.
Need Help Running a PIA or DPIA?
Captain Compliance provides expert-backed tools and templates to make privacy assessments fast, consistent, and audit-ready. Our platform is built for compliance teams that need to scale across multiple jurisdictions without missing a step.
Which One Does Your Organization Need?
The answer depends on where you operate, what data you process, and what regulatory frameworks apply to your activities. Here is a practical decision framework.
You Need a DPIA If:
- Your organization processes personal data of EU or UK residents and your processing is likely to result in high risk (apply the three Article 35(3) triggers plus your supervisory authority’s list).
- You are deploying AI, machine learning, or automated decision-making that produces significant effects on individuals.
- You are processing health, biometric, genetic, or other special category data at any meaningful scale.
- You are implementing surveillance, tracking, or monitoring systems in public or semi-public spaces.
- You are building or deploying facial recognition, voice recognition, or other biometric identification technologies.
- Your supervisory authority has indicated that your type of processing is high risk through official guidance or a published list.
You Need a PIA If:
- You are a U.S. federal agency subject to the E-Government Act of 2002.
- Your processing activities trigger privacy risk assessment requirements under applicable U.S. state privacy laws (California, Colorado, Connecticut, Virginia, Texas, and others).
- Your organization is subject to PIPEDA, Canada’s Privacy Act, or provincial privacy legislation in Alberta, British Columbia, or Quebec.
- You want to demonstrate privacy by design and maintain a documented governance record even when no assessment is strictly required by law.
- You are onboarding a new vendor with significant access to personal data and want to document your due diligence.
- You are launching a new product, feature, or data-sharing initiative and want to identify privacy risks before they become problems.
You May Need Both If:
- You operate globally across multiple jurisdictions — a DPIA for GDPR-regulated activities and PIAs for everything else.
- You are a U.S. company that also serves EU or UK residents.
- You use PIAs as part of a broader privacy program that feeds into mandatory DPIAs for higher-risk activities.
Practical guidance: Many organizations benefit from building a tiered assessment program — a lightweight PIA (sometimes called a Privacy Threshold Analysis or PTA) as a first-pass screening for all new processing activities, with a full DPIA triggered automatically when the screening identifies high-risk signals. This approach embeds privacy review into the development lifecycle without creating unnecessary friction for lower-risk work.
Consequences of Skipping a Required Assessment
The consequences of failing to complete a required assessment depend on which framework applies, but they are uniformly serious.
Under the GDPR
Failure to conduct a required DPIA is a direct violation of GDPR Article 35. Under Article 83(4), this is subject to fines of up to €10 million or 2% of total worldwide annual turnover — whichever is higher. Importantly, this is the lower tier of GDPR fines. Supervisory authorities can also issue orders requiring processing to be suspended until a proper DPIA is completed, which can have significant operational impact for product teams and data-driven businesses.
Beyond the direct fine, a missing DPIA undermines the organization’s entire compliance posture. If a supervisory authority opens an investigation into a data breach or a data subject complaint and discovers that the relevant processing was never properly assessed, the absence of a DPIA becomes evidence of systemic non-compliance, not just a technical oversight.
Under U.S. State Laws
State privacy laws increasingly include privacy risk assessment requirements within their enforcement scope. Under the California CPRA, the California Privacy Protection Agency (CPPA) has rulemaking authority over risk assessment requirements, and non-compliance with those requirements falls within the CPPA’s enforcement mandate. Colorado, Connecticut, and Virginia all include data protection assessment obligations that can be audited by the relevant attorney general. Non-compliance with these requirements is increasingly being treated not as a procedural gap but as substantive evidence of inadequate privacy governance.
Reputational and Litigation Risk
Beyond regulatory enforcement, the absence of documented privacy assessments creates significant exposure in civil
