What is a privacy impact assessment, and how do you run one?

A privacy impact assessment (PIA) is a formal analysis of how personal information is collected, used, shared, and protected, done before processing starts, not after something goes wrong.

In 2025, the ICO reviewed the 200 most-visited UK websites for cookie compliance and found issues with 134. Even large organizations with privacy teams and policies often got tracking wrong in practice. Their assessments existed but did not match what actually happened on their sites.

If you are a DPO, privacy counsel, or GRC lead at a company with a website that collects personal data, you need to know when a PIA is required, what makes it defensible, and how to base it on your site’s actual data flows, not just your inventory.

What is a privacy impact assessment?

A privacy impact assessment is a documented analysis of how personal information moves through a system, project, or process: what is collected, why, who receives it, what could go wrong for the people it describes, and what controls reduce privacy risks. Done during design, it fixes privacy problems before production.

The term has two lineages. In the United States, the PIA comes from the E-Government Act of 2002, which made it a formal obligation for federal agencies. OMB Memorandum M-03-22 defines it as an analysis of how information is handled: to ensure the handling conforms to privacy requirements, to determine the risks and effects of collecting and disseminating information in identifiable form, and to evaluate protections and alternatives that could mitigate those risks. 

The FTC’s own PIA page puts the purpose plainly: to show that program managers and system owners have “consciously incorporated privacy protections throughout the development life cycle of a system or program.”

In Europe, the same instrument grew into the GDPR’s data protection impact assessment. Either way, it does two jobs. It reduces risk by forcing the hard questions early, and it creates transparency: a record you can show a regulator, a court, or a board of what you knew and what you did about it.

A PIA is not a privacy incident review. An incident is something that already happened. The assessment exists so it doesn’t.

Is a PIA the same as a DPIA, or a CCPA risk assessment?

No. Same assessment family, same logic, but different legal weight, triggers, and prescribed content. The GDPR’s instrument is the data protection impact assessment (DPIA): the ICO notes that DPIAs were “previously known as privacy impact assessments.” In the US, “PIA” remains the broader and older term: the federal-agency instrument, the state-law data protection assessment, and general privacy practice.

For a US company whose website gets European visitors, several instruments can apply to the same processing at once: a DPIA under the GDPR, a data protection assessment under state law, and a risk assessment under California’s regulations. They share one spine: describe the processing, test its necessity, assess the risk to individuals, document the mitigations. That means you can adapt a well-built assessment rather than rebuild it. Our CCPA guide outlines the California rules in detail, including the opt-out rights for sale and secure data sharing, which sit outside the assessment itself.

The EU AI Act adds a fundamental rights impact assessment for certain deployers of high-risk AI systems, and Article 27(4), amended in July 2026, lets the deployer fold the GDPR DPIA into it: cross-referencing or incorporating the relevant sections of the DPIA where it already covers the same ground if a chatbot or AI feature is what prompted your question, that overlap matters.

When is a privacy impact assessment required?

A privacy impact assessment is required when data protection regulations apply to your organization and the processing falls into a category the law treats as high risk. If your website runs targeted-advertising pixels, profiles visitors, or processes sensitive data, several US state laws already require an assessment, and if you have European visitors, the GDPR’s high-risk test applies on top. The full map:

The GDPR’s test is not an activity checklist. Article 35(3) names three cases that “in particular” require a DPIA: systematic and extensive evaluation with significant effects, large-scale special-category data, and large-scale public-area monitoring. Regulators apply the broader “high risk” test through the Article 29 Working Party’s nine criteria:

1. Evaluation or scoring
2. Automated decisions with significant effects
3. Systematic monitoring
4. Sensitive or highly personal data
5. Large-scale processing
6. Combining datasets
7. Data concerning vulnerable people
8. Innovative technology
9. Processing that blocks someone from exercising a right or using a service

The WP248 guidelines state: “In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out,” and that a single criterion can be enough. For a company outside the EU, the GDPR reaches it only within Article 3’s territorial scope: offering goods or services to people in the EU, or monitoring their behavior there.

On the state side, the assessment duty is now the rule rather than the exception. As of September 2026, eighteen state laws require data protection assessments: every comprehensive state privacy law in force except Utah’s and Iowa’s, plus Florida’s narrower statute. Oklahoma, Louisiana, and Vermont have enacted assessment duties that take effect in 2027 and 2028. Alabama’s new law, like Utah’s and Iowa’s, requires none. The trigger lists are similar but not identical. Virginia’s § 59.1-580 names five categories, including a heightened-risk catch-all. Colorado’s § 6-1-1309 and Connecticut’s § 42-522 list four. Iowa and Utah require none (a counterexample check across guidance and amendments came back empty in September 2026). Connecticut has since added a separate profiling impact assessment for decisions with legal or similarly significant effects, applying to processing created on or after August 1, 2026. 

What the assessment must contain varies less than the triggers: the state statutes all require weighing the processing’s benefits to you against the risks to consumers, accounting for context and consumer expectations. California’s regulation adds its own content list and an annual attestation, with the first filing due April 1, 2028.

The federal row matters only to agencies: unless you are one (or building systems for one), the E-Government Act is not your obligation. One piece of it is worth borrowing, though. OMB M-10-23 requires agencies to run an adapted PIA whenever they use third-party websites and applications that make personal information available to them. Third-party tools deserve their own assessment, exactly the discipline the private sector is now being asked to show.

Does your website trigger a Privacy Impact Assessment?

Probably more often than the legal team expects. The triggers above become clear once you map them to what a marketing stack actually does:

• Adding an advertising pixel (Meta, Google Ads, TikTok) is targeted advertising under the state laws. The state assessment duty attaches to the processing, not to a decision someone remembers making.
• Analytics with sharing enabled (a GA4-class setup that feeds audiences or ad features) can move ordinary measurement into profiling or targeted-advertising territory, and systematic monitoring is one of the WP248 criteria.
• Session replay captures everything a visitor types, including text never submitted, a sensitive-data and “invisible processing” risk that appears on the ICO’s own high-risk list. The litigation exposure is its own subject. The CIPA guide and the session replay guide cover it.
• A chatbot or AI feature engages the WP248 “innovative use of new technologies” criterion, and for some deployers, the AI Act’s impact assessment on top.
• Changing your consent banner or tag manager alters which scripts fire and when; the assessment question is not the tool change but the new data flows it creates.

The ICO’s Stephen Almond, after the regulator’s sweep of the UK’s top websites, described what is at stake: 

“Uncontrolled tracking intrudes on the most private parts of our lives and can lead to harm. For example, gambling addicts being targeted with more betting ads due to their browsing history or LGBTQ+ people altering their online behavior for fear of unintended disclosure of their sexuality.”

And if you work through the triggers and conclude none apply? Write the no down. A short screening record (what you considered, which criteria you tested, who decided, and when) is itself accountability evidence. Regulators ask for the reasoning, not just the result: a documented “not required” is a defensible position, an undocumented one a shrug.

What happens if you skip the Privacy Impact Assessment?

Skipping a privacy impact assessment weakens privacy compliance as well as legal defensibility. Two things, the carrot and the stick: you lose the record that protects you, and you risk the penalties that apply when the assessment was legally required.

• The audit trail. State attorneys general can compel your assessments. The state statutes build that in. When a regulator or an AG asks why you believed a processing was acceptable, the assessment is the answer. Without it, the answer is improvisation.
• GDPR fines. Failures sit in the GDPR’s lower fine tier: up to €10 million or 2% of worldwide annual turnover, whichever is higher (Article 83(4)).
• Enforcement is real, and small scale is no shield. Sweden’s first GDPR fine fell on a school board in Skellefteå that ran facial-recognition attendance tracking for 22 students over three weeks: IMY found the impact assessment did not meet Article 35 and the board never consulted the authority, and fined it SEK 200,000.
• An inadequate assessment is worse than none in court. When South Wales Police defended its facial-recognition deployment in Bridges, the Court of Appeal held that its impact assessment failed the DPA 2018 because it had been built on the wrong legal basis: it assumed the processing was lawful. As Megan Goulding, the claimant-side lawyer at Liberty, put it after the ruling: “The Court has agreed that this dystopian surveillance tool violates our rights and threatens our liberties.”
• Trackers specifically are an active enforcement front. In September 2025, the CNIL fined Shein €150 million after finding advertising trackers were deposited before any interaction with the consent banner and kept firing even after users refused.

One cost is quieter: an assessment that describes the system you intended rather than the one actually running fails as soon as anyone compares it to reality. Weak assessments also leave potential vulnerabilities undiscovered and increase the chance of data breaches. This is why the evidence problem below matters as much as the legal triggers.

Who runs a PIA, and what does it take?

The business owns it; the privacy function steers it. In practice:

• The initiative’s owner (the product, marketing, or IT lead launching the thing) drives the assessment.
• The data protection officer advises. The GDPR requires their input where one is designated.
• Sign-off sits with whoever can accept residual risk, typically the DPO plus a business owner.
• Remediation needs named owners and deadlines, or the mitigations stay theoretical.

Be honest about the cost. A serious assessment takes days of cross-functional work, not an afternoon, and requires both legal and architectural knowledge. This is why the screening step matters: it reserves the full instrument for the processing that genuinely needs it.

And the work does not end at sign-off. Privacy engineering leader Nishant Bhajaria, who built privacy programs at Google, Netflix, and Uber, describes the operating model:

“Continuously classify the data based on risk. Tag the data based on your understanding of the risk. And enforce policies on an ongoing basis. Because if you do those things, then just as the data and the risk accumulate on an ongoing basis, your ability to understand that risk and protect your customer from that risk also happens on an ongoing basis.”

Start from what your site actually sends

Every process guide, regulator template, and consulting framework eventually arrives at the same step: describe the processing and its data flows. Each assumes you can. For a website, that assumption is where PIAs quietly fail and where the question of how often to redo the assessment finds its answer.

The data flows of a modern website are not designed. They accumulate. Tag managers let marketing add scripts without deployment. Vendors update their tags, and their tags call their own vendors. A consent-banner misconfiguration fires trackers before anyone opts in. Princeton’s Web Census measured over 81,000 distinct third parties operating across the top million websites. Researchers replaying twenty years of the web found tracking intensity quadrupled between 1996 and 2016, noting their archive-based numbers undercount what live sites actually send. The composition of your site’s third parties this quarter is not what it was last quarter, and nobody emailed you the diff.

So the interview-and-inventory PIA describes the site someone intended: the vendors procurement approved, the tags someone remembers adding, the policy as written. The processing the GDPR asks you to describe is the one that runs. Regulators know the difference. Princeton’s team describes its own method as “a largely automated monthly ‘census’ of the top 1 million websites, in effect ‘tracking the trackers’,” and the ICO’s sweep used the same logic: observe what the site does, then compare it to what the site claims.

This also answers “how often should we redo the assessment?” The GDPR’s review duty is change-based: review “at least when there is a change of the risk represented by processing operations.” The WP248 guidelines are blunt: “Carrying out a DPIA is a continual process, not a one-time exercise.” For a system that changes weekly, the only workable reading is continuous: observe what the site sends on a recurring basis and let changes in observed behavior (a new recipient, a new identifier, a script firing before consent) trigger the review. Change-control for data practices, not an annual archaeology project.

What goes in a Privacy Impact Assessment, and how do you run one?

The GDPR’s minimum content list is the best canonical structure, because the other regimes map onto it. Article 35(7) requires at least four elements. Practice adds the rows that make the document operational:

Run it as a process, not a document:

1. Screen: Test the processing against the triggers and record the outcome, including when the answer is no.
2. Describe: Document the processing and its data flows as they actually are; the evidence discipline from the previous section is what makes this step true rather than aspirational.
3. Consult: Take the DPO’s advice, and where appropriate seek the views of the people whose data it is (Article 35(9)). Processors are obliged to assist you under Article 28(3)(f).
4. Test necessity and proportionality: Purpose, minimization, retention, alternatives.
5. Assess the risks to individuals: CNIL’s methodology structures this well: for each of three feared events (illegitimate access, unwanted change, and disappearance of personal data), estimate severity and likelihood, then map controls (data-level, system-level, organizational).
6. Mitigate potential privacy risks and re-score: Controls in, residual risk recorded.
7. Document, decide, and sign off: Proceed, proceed with conditions, or stop.
8. Escalate if the residual risk stays high: If you cannot mitigate the risk away, Article 36 requires prior consultation with the supervisory authority before processing, which then has up to eight weeks to respond, extendable by six.
9. Review: Re-run the assessment when the risk changes, which, for a website, means when the observed behavior changes.

You do not have to invent the paperwork. The ICO publishes a sample DPIA template, CNIL maintains free, open-source PIA software, the US Department of Commerce has a federal template, and ISO/IEC 29134:2023 standardizes the process and report structure for a vendor-neutral methodology. 

How MELURNA Supports Privacy Impact Assessments

MELURNA takes the guesswork out of the description step by showing what your site is really doing, not just what your vendor list claims. The description step is often the weakest link, since an assessment is only as good as the data flows it uses. MELURNA monitors browser and application traffic. Its regular scans collect requests, responses, cookies, headers, destinations, timing, and interaction context, all without needing access to your internal systems. It also finds every recipient, including third and fourth parties that might not show up in your inventory.

When it comes to assessments, MELURNA gives you two advantages over paperwork. First, it highlights the gaps between your stated policies and what actually happens on your site, so you can see where your disclosures and consent practices don’t match your site’s actual behavior. Second, the Journey Change Monitor tracks changes in recipients over time, making GDPR’s change-based reviews much easier. After you make a fix, another analysis checks if the recipient, value, or control has really changed, giving you the before-and-after proof that reviewers need.

Book a review slot to find out exactly what your site is sending.

FAQs

DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.