A DPIA (data protection impact assessment) is a documented check of the privacy risks of a planned processing activity and the measures that reduce them. Under Article 35 of the GDPR, you need one before you start any processing that is likely to result in a high risk to people's rights and freedoms. In practice that means one of the three cases in Article 35(3), an activity on your national authority's list, or processing that meets two or more of the nine EDPB criteria. The assessment must happen before you begin processing, not after.
Most of the difficulty lies in the phrase "likely to result in a high risk". The GDPR does not define it precisely, and regulators have spent years clarifying what it means in practice: through the legal triggers, the criteria endorsed by the European Data Protection Board (EDPB), and national lists.
What a DPIA contains at minimum
A DPIA is a documented risk assessment. It describes the processing you intend to carry out, evaluates whether it is necessary and proportionate, identifies risks to individuals, and sets out the measures you will take to address those risks. Article 35(7) of the GDPR lists the minimum contents:
- A systematic description of the processing operations and their purposes
- An assessment of necessity and proportionality
- An assessment of the risks to the rights and freedoms of data subjects
- The safeguards and security measures planned to mitigate those risks
A DPIA is not a one-off checkbox. The ICO describes it as a "living process" - something you revisit whenever circumstances change, new risks emerge, or you alter the scope of your processing. If a new security flaw is discovered, or you expand the data you collect, you should review and update the assessment.
The three automatic triggers in Article 35(3)
Article 35(3) of the GDPR lists three scenarios where a DPIA is always required. If your processing falls into one of these categories, you must carry out an assessment.
Systematic and extensive profiling with significant effects. If you evaluate personal aspects of individuals based on automated processing (including profiling), and those evaluations produce legal effects or similarly significant consequences, a DPIA is mandatory. Credit scoring, automated insurance underwriting, and algorithmic hiring decisions all fall squarely into this category.
Large-scale processing of special category data. Special category data includes information about racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data, health data, and data about sex life or sexual orientation. Processing any of these at scale - or criminal conviction data - triggers the DPIA requirement automatically. A hospital implementing a new patient database, for instance, would need one.
Systematic monitoring of publicly accessible areas on a large scale. CCTV systems in shopping centres, public transport hubs, or city streets are the classic example. If you are recording individuals in public spaces in a systematic way, you need a DPIA before switching the cameras on.
These three scenarios are explicitly called out in the regulation. But they are not exhaustive. Article 35(1) makes clear that any processing likely to result in high risk requires a DPIA, whether or not it matches one of these three examples.
Do you need a DPIA? Three questions
The EDPB nine criteria for high-risk processing
To help controllers decide when processing crosses the "high risk" threshold, the EDPB endorsed the Article 29 Working Party guidelines (WP248 rev.01), which set out nine criteria. Meeting two or more of these criteria generally means a DPIA is required, though meeting even one criterion may be sufficient depending on the context.
| Criterion | Description | Example |
|---|---|---|
| 1. Evaluation or scoring | Profiling or predicting behaviour, performance, preferences, or interests | Credit reference checks, behavioural advertising |
| 2. Automated decision-making with legal or similar effects | Processing that leads to decisions affecting access to services, employment, or credit | Automated loan approvals, algorithmic recruitment |
| 3. Systematic monitoring | Observing, monitoring, or controlling data subjects | Employee location tracking, website behaviour monitoring at scale |
| 4. Sensitive or highly personal data | Special categories under Article 9, criminal data under Article 10, or data considered highly personal (financial records, location data) | Health apps, biometric access systems |
| 5. Large-scale processing | Processing that affects a significant number of data subjects | National loyalty programmes, large e-commerce platforms |
| 6. Matching or combining datasets | Combining data from multiple sources in ways that exceed individual expectations | Merging CRM data with third-party advertising profiles |
| 7. Vulnerable data subjects | Processing data of children, employees, patients, or others with a power imbalance | EdTech platforms, employee monitoring systems |
| 8. Innovative technological or organisational solutions | Using new or emerging technology where the privacy impact is not yet fully understood | Fingerprint access combined with facial recognition, IoT devices |
| 9. Processing that prevents data subjects from exercising a right or using a service | Blocking or restricting individuals based on data processing | A bank denying services based on automated screening |
The EDPB advises that the more criteria your processing meets, the more likely it is to present a high risk. Two criteria is the general threshold, but one criterion alone - particularly involving innovative technology or vulnerable data subjects - can be enough.
National DPA lists add extra triggers
Article 35(4) of the GDPR requires each national supervisory authority to publish its own list of processing operations that mandate a DPIA. These lists supplement the EDPB criteria and vary between member states. The EDPB issued opinions on the national lists to promote consistency, starting with 22 of them in September 2018, but differences remain.
The Irish Data Protection Commission (DPC), for example, specifically calls out processing that involves systematically monitoring or tracking individuals' location or behaviour on a large scale, and processing that combines or cross-references datasets to profile or analyse user behaviour. Both of these are directly relevant to websites using advertising cookies, remarketing pixels, or cross-device tracking.
The French CNIL has taken a particularly active stance on DPIAs in the context of artificial intelligence. In its 2024 guidance, the CNIL stated that the development of foundation models or general-purpose AI systems requires a DPIA when it involves processing personal data, even where those models are not classified as high-risk under the EU AI Act. The reasoning: the wide range of potential future uses makes it impossible to assess all risks upfront.
When does a website owner need a DPIA?
Most small business websites - a company blog, a brochure site, a simple online shop - do not process personal data at a scale or intensity that triggers the DPIA requirement. Setting a handful of functional cookies and running basic server-side analytics is unlikely to qualify as high-risk processing.
That changes quickly once you introduce more complex tracking. Consider these scenarios where a DPIA becomes necessary or strongly advisable:
Cross-site tracking and behavioural advertising. If you use third-party cookies or tracking pixels (such as _fbp from Meta or advertising cookies from programmatic networks) to build profiles of visitors across multiple websites, you are matching datasets and engaging in systematic monitoring. Two EDPB criteria are met, so a DPIA is warranted.
Combining analytics with registration data. If you link analytics cookie data with user account information to identify which pages specific individuals have read, you are profiling individuals. That processing requires both consent and a DPIA.
Large-scale e-commerce with personalisation. A site with hundreds of thousands of users that processes purchase history, browsing behaviour, and location data to serve personalised product recommendations is processing at scale, using evaluation/scoring techniques, and potentially combining datasets. Multiple criteria apply.
Health, financial, or children's data. Any website collecting special category data or data from minors triggers additional scrutiny. An online pharmacy, a mental health app, or a children's educational platform should treat a DPIA as a baseline requirement.
Not sure which cookies and trackers your site actually sets? That is the right starting point. A cookie scan lists the first-party and third-party cookies, local storage items and pixels on your site. Without this cookie audit, you cannot meaningfully assess whether your processing is high-risk. Kukie.io's cookie scanner detects and categorises these automatically, giving you the raw data a DPIA needs.
The EU AI Act and DPIAs overlap
The EU AI Act entered into force in August 2024 and applies in stages. As of October 2026, after the 2026 AI Omnibus (Regulation (EU) 2026/1744), the obligations for high-risk systems listed in Annex III apply from 2 December 2027, and those for AI in products covered by Annex I from 2 August 2028. While the AI Act introduces its own conformity assessment framework for high-risk AI systems, it does not replace the GDPR's DPIA requirement. If your AI system processes personal data - and most do - you may need to complete both a DPIA under the GDPR and a conformity assessment under the AI Act.
Article 26(9) of the AI Act explicitly requires deployers of high-risk AI systems to use the information provided by the AI system's provider to carry out a DPIA under Article 35 GDPR. The two frameworks are designed to coexist, not to duplicate effort. The CNIL has noted that the documentation prepared for AI Act compliance can feed into the DPIA, provided the GDPR's own requirements under Article 35(7) are all addressed.
For website owners, this matters if you deploy AI-powered tools - chatbots that process visitor queries, recommendation engines that profile users, or automated content moderation systems. Each of these could qualify as both a high-risk AI system and a high-risk data processing operation under the GDPR.
What happens if you skip the DPIA
Failing to carry out a DPIA when one is required is itself a GDPR infringement, regardless of whether any data breach occurs. Under Article 83(4)(a), supervisory authorities can impose fines of up to 10 million euros or 2% of global annual turnover for DPIA-related failures.
The ICO puts the UK-specific figure at up to 8.7 million pounds or 2% of global turnover, whichever is higher. And since the UK's Data (Use and Access) Act 2025 retained the existing DPIA requirements - an earlier proposal under the DPDI Bill to introduce more flexible "high-risk processing assessments" was dropped - the obligation remains firmly in place for UK-based controllers.
Enforcement has been tangible. When the Irish DPC fined Meta's Instagram 405 million euros in 2022 for mishandling children's data, one of the findings was that Instagram had failed to conduct proper DPIAs for its business account feature, which made teenagers' contact information publicly visible. The absence of a DPIA was not the headline violation, but it formed part of the regulatory finding and contributed to the penalty.
Beyond fines, the practical risk is significant. Without a DPIA, you have no documented evidence that you considered the privacy impact of your processing. If a complaint is filed or a breach occurs, regulators will ask for your DPIA. If it does not exist, the conversation becomes substantially more difficult.
A checklist to decide whether you need a DPIA
Run through these questions. If you answer "yes" to two or more, you should carry out a DPIA. If you answer "yes" to even one - particularly questions 4, 7, or 8 - you should seriously consider it.
| # | Question | EDPB criterion |
|---|---|---|
| 1 | Does your processing evaluate, score, or profile individuals? | Evaluation/scoring |
| 2 | Do automated decisions affect individuals' access to services, contracts, or rights? | Automated decision-making |
| 3 | Do you systematically monitor individuals (including online behaviour tracking at scale)? | Systematic monitoring |
| 4 | Do you process special category data, criminal data, or highly personal data like financial or location records? | Sensitive data |
| 5 | Is the processing carried out on a large scale (affecting many individuals or involving large volumes of data)? | Large-scale processing |
| 6 | Do you combine, match, or cross-reference datasets from different sources? | Matching/combining datasets |
| 7 | Does the processing involve vulnerable individuals (children, employees, patients)? | Vulnerable data subjects |
| 8 | Are you using new or innovative technology where the privacy impact is not yet well understood? | Innovative technology |
| 9 | Could the processing prevent someone from exercising a right or accessing a service? | Preventing rights/services |
Even if none of these apply strictly, a voluntary DPIA is good practice, and many organisations carry one out as standard whenever they launch a project that touches personal data.
What a good DPIA includes
The GDPR sets minimum requirements, but most supervisory authorities recommend a more detailed approach. A well-structured DPIA typically includes these elements:
Scope and description. What data are you collecting? From whom? Through what means? Where is it stored and who has access? Include technical details - cookie names, tracking scripts, database structures, third-party processors. If your site sets _ga, _ga_<container-id> and _fbp cookies, name them explicitly.
Necessity and proportionality. Why do you need this specific processing? Could you achieve the same purpose with less data or less intrusive methods? This is where data minimisation principles bite hardest. If you are collecting location data to serve regional content, do you actually need precise GPS coordinates, or would a country-level lookup from the IP address suffice?
Risk identification. What could go wrong for the individuals whose data you process? Risks commonly flagged in DPIA reviews include:
- unauthorised access and data breaches
- function creep: using data for purposes beyond what individuals expected
- data shared with more third parties than people realise
- algorithmic bias in automated decisions
- loss of autonomy through invasive profiling
Mitigation measures. For each identified risk, document the safeguard you will put in place. Encryption at rest and in transit, access controls, pseudonymisation, retention limits, consent mechanisms, and regular security audits all count. If your website uses a consent management platform to block non-essential cookies until the visitor actively opts in, that is a mitigation measure worth documenting.
Residual risk assessment. After applying your safeguards, is there still a high risk? If so, Article 36 of the GDPR requires you to consult your supervisory authority before you start the processing.
The ICO publishes DPIA guidance with a downloadable template that many organisations use as a starting point.
Where DPIAs and cookie consent overlap
Cookie consent and DPIAs serve different purposes but intersect in practice. Cookie consent - governed by Article 5(3) of the ePrivacy Directive - addresses the act of placing or reading information on a user's device. The DPIA addresses the wider processing that happens with the data those cookies collect.
A website that sets advertising and functional cookies is performing two legally distinct actions: storing data on the device (ePrivacy) and processing personal data derived from that storage (GDPR). The DPIA covers the second part. But the information you gather during a cookie audit - which cookies exist, what data they collect, which third parties receive that data, how long the cookies persist - feeds directly into the DPIA's description of processing operations.
This is where a consent tool helps beyond the banner. Kukie.io's scanner lists the cookies and trackers on your site, sorts them by purpose and names the third parties behind them. That audit output maps neatly onto the "systematic description of processing" that Article 35(7)(a) requires in every DPIA.
Questions about DPIAs
Is a DPIA mandatory for every website that uses cookies?
No. A DPIA is only mandatory when your processing is likely to result in a high risk to individuals. A small website with a few strictly necessary and basic analytics cookies is unlikely to meet that threshold. The requirement kicks in when you track behaviour at scale, combine datasets for profiling, or process special category data.
How many EDPB criteria must apply before a DPIA is needed?
The EDPB guidelines (WP248 rev.01) state that meeting two or more of the nine criteria generally triggers the DPIA requirement. However, meeting a single criterion can be sufficient depending on context - particularly if it involves innovative technology, vulnerable data subjects, or large-scale sensitive data processing.
Can I be fined for not conducting a DPIA even if no data breach occurs?
Yes. Failing to carry out a DPIA when one is required is a standalone GDPR infringement under Article 83(4)(a). Supervisory authorities can impose fines of up to 10 million euros or 2% of global annual turnover, regardless of whether any actual harm or breach has occurred.
Do I need a separate DPIA for each cookie or tracking technology?
Not necessarily. A DPIA covers a processing operation, not a single cookie. If multiple cookies and trackers serve the same purpose - for example, behavioural advertising - you can assess them together in a single DPIA. If you have separate processing activities with different purposes and risks, each should have its own assessment.
Does the UK still require DPIAs after the Data Use and Access Act 2025?
Yes. The UK's Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025, retained the existing DPIA requirements under the UK GDPR. An earlier proposal under the DPDI Bill to introduce more flexible "high-risk processing assessments" was not carried forward. The obligation remains: if your processing is likely to result in high risk, a DPIA is mandatory.
What happens if the DPIA reveals a high residual risk?
If you cannot reduce the risk to an acceptable level through safeguards and mitigation measures, Article 36 of the GDPR requires you to consult your supervisory authority before starting the processing. The authority has up to eight weeks to give written advice, extendable by six weeks for complex processing, and it must tell you within one month if it extends.
Does the EU AI Act create additional DPIA obligations?
The EU AI Act does not replace the GDPR's DPIA requirement - it adds to it. If you deploy a high-risk AI system that processes personal data, Article 26(9) of the AI Act requires you to use the provider's documentation to carry out a DPIA under Article 35 GDPR. For systems listed in Annex III, those AI Act duties apply from 2 December 2027.
Start with a full picture of your data processing
If you are uncertain whether your website's data processing requires a DPIA, the first step is understanding exactly what data you collect. A cookie audit gives you that foundation - every cookie, every tracker, every third-party data flow mapped and categorised. Kukie.io scans your site, identifies first-party and third-party cookies and gives you an inventory you can use in the DPIA's description of processing.
