What a DPIA is, and why cookies sometimes need one

A data protection impact assessment (DPIA) is a written risk assessment you have to complete before you start processing that's likely to result in a high risk to people's rights. It's set out in Article 35 of the GDPR. Most cookie banners on most websites don't require one. A brochure site with privacy-friendly analytics is nowhere near the threshold. But some tracking setups sit squarely inside it, and a DPIA you were required to do and didn't is a breach on its own, separate from whatever the tracking itself did wrong.

The reason cookies come up at all is that Article 35 was written with profiling and monitoring in mind, and modern web tracking does exactly those two things. So the question isn't "do cookies need a DPIA" in the abstract. It's whether your tracking crosses the high-risk line.

The three cases that always require one

Article 35(3) names three types of processing that always trigger a DPIA:

Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects.
Large-scale processing of special categories of data (health, ethnicity, political opinions, and the rest) or data on criminal convictions.
Systematic monitoring of a publicly accessible area on a large scale.

Behavioral advertising that builds detailed profiles and drives automated targeting can land in the first category. Large-scale tracking that follows people across sites edges toward the third. But the three named cases aren't the whole test. The real working tool is the list of criteria the regulators published.

The nine criteria, and the rule of thumb

The Article 29 Working Party guidance on DPIAs (WP248 rev.01, endorsed by the EDPB) lists nine criteria. The more that apply, the more likely your processing is high risk:

Evaluation or scoring, including building a behavioral or marketing profile of a website user.
Automated decision-making with legal or significant effect.
Systematic monitoring.
Sensitive data or data of a highly personal nature.
Data processed on a large scale.
Matching or combining datasets.
Data about vulnerable subjects, such as children or employees.
Innovative use of new technology, such as fingerprinting.
Processing that prevents people from exercising a right or using a service.

The guidance offers a practical rule: a processing operation that meets two or more of these criteria will usually require a DPIA. Now map that to cookies. Cross-site behavioral advertising hits criterion 1 (scoring), criterion 3 (systematic monitoring), and criterion 5 (large scale) on its own. Combine your pixel data with a CRM and you add criterion 6. Track children and you add criterion 7. It stacks up fast for adtech-heavy sites and stays comfortably below the line for basic first-party analytics.

A DPIA is done before processing, not after the regulator calls

Article 35 requires the assessment prior to the processing. Writing one up after launch, or after a supervisory authority starts asking questions, doesn't cure the omission. Failing to carry out a required DPIA is itself an infringement in the fine tier that reaches up to 10 million euros or 2% of total worldwide annual turnover, whichever is higher. Treat the DPIA as a gate before you deploy the tracking, not a document you backfill.

What a cookie DPIA actually contains

Article 35(7) sets the minimum content, and it's less intimidating than it sounds. A workable cookie DPIA covers four things:

A description of the processing and its purposes: which cookies and tags run, what vendors receive data, what profiles get built, and how long data is kept. This is where a current cookie inventory does most of the work.
An assessment of necessity and proportionality: do you actually need this tracking for the stated purpose, or would something less intrusive do the job?
The risks to data subjects: profiling they didn't expect, data shared with third parties, cross-site linkage, re-identification.
The measures to reduce those risks: consent before non-essential cookies fire, data minimization, retention limits, IP truncation, and honoring withdrawal.

If real high risk remains after your mitigations, Article 36 requires you to consult your supervisory authority before you go ahead. That's the exception, not the norm, but it's the reason you want the assessment done early.

Signs your tracking needs a DPIA

You build behavioral or marketing profiles of visitors
Criterion 1 (evaluation and scoring) applies to profiling website users.
You track people across sites or over long periods
Systematic monitoring at scale stacks criteria 3 and 5.
You combine pixel or analytics data with other datasets
Matching datasets is criterion 6.
Your audience includes children or other vulnerable groups
Criterion 7 raises the risk level on its own.
You use fingerprinting or other novel identification
Innovative technology is criterion 8.
Two or more of these apply
That's the WP248 threshold for carrying out a DPIA before you start.

Where CookieBeam fits

CookieBeam doesn't write your DPIA, that's a judgment call your team and, where you have one, your data protection officer own. What it gives you is the raw material the assessment needs. The cookie scanner produces the inventory of what cookies, scripts, and third-party connections actually run on your site, grouped by category and vendor, which is the "description of the processing" the DPIA asks for and the thing most teams struggle to compile by hand. See how to audit your website's cookies.

On the mitigation side, blocking non-essential cookies until consent and logging each consent decision per purpose are concrete measures you can point to in the DPIA and evidence later. Pair this guide with your records of processing for cookies and the wider accountability principle applied to cookies, since a DPIA is one document in a set that has to hang together.