Data protection impact assessment (DPIA)
A Data Protection Impact Assessment (DPIA) is a structured analysis the GDPR requires before processing that is likely to result in a high risk to people's rights — for example large-scale profiling or systematic monitoring. Some analytics and tracking setups meet that bar. This page explains when a DPIA is required and what it documents.
When a DPIA is required
Article 35 of the GDPR mandates a DPIA when processing is likely to result in a high risk to individuals, and specifically calls out systematic and extensive profiling with significant effects, large-scale processing of special-category data, and large-scale systematic monitoring of a public area. Supervisory authorities publish lists of operations that always require one.
Profiling-heavy tracking, cross-site monitoring, or combining analytics with sensitive data can cross into high-risk territory.
What it must cover
A DPIA describes the processing and its purposes, assesses necessity and proportionality, identifies risks to data subjects, and sets out mitigations. The output should shape design — and for analytics, the cheapest mitigation is often to minimise: drop identifiers, aggregate, shorten retention, and avoid cross-site monitoring, which can lower the risk below the threshold.
- Triggered by likely high-risk processing
- Profiling, sensitive data, systematic monitoring are flags
- Must document risks and mitigations, not just describe processing
How it appears in analytics and logs
Plans involving systematic monitoring or large-scale profiling are DPIA candidates; choosing aggregate, minimised analytics often keeps a project below the high-risk threshold.
Diagnostic use case
Decide whether your measurement plan is high-risk enough to need a DPIA, and use the assessment to design lower-risk, minimised analytics instead.
What WebmasterID can help detect
WebmasterID's minimised, aggregate model is the kind of lower-risk design a DPIA is meant to encourage, often avoiding the high-risk triggers entirely.
Common mistakes
- Skipping a DPIA for large-scale monitoring or profiling.
- Treating a DPIA as paperwork rather than a design input.
- Ignoring the supervisory authority's mandatory-DPIA list.
Privacy and accuracy notes
This page is educational and not legal advice. Whether a DPIA is mandatory depends on the processing and supervisory-authority lists; consult those lists and counsel.
Related pages
- Privacy by design and by default
Privacy by design and by default, codified in GDPR Article 25, requires data protection to be built into systems from the outset and the most privacy-protective settings to be the default. For analytics this points to minimised collection, cookieless and anonymised defaults, and short retention out of the box — protection that does not depend on the user opting in. This is an educational overview, not legal advice.
- Data minimisation in analytics
Data minimisation is the principle that personal data should be adequate, relevant, and limited to what is necessary for the purpose. In analytics it translates to: do not collect identifiers you will not use, prefer aggregates over per-person rows, and avoid storing precise values like full IPs. Minimising at collection beats trying to protect data you never needed. This is educational, not legal advice.
- Lawful basis for analytics processing
The GDPR requires a lawful basis for processing personal data. For analytics the realistic candidates are consent and legitimate interests, each with conditions: consent must be valid and is often required where ePrivacy applies to cookies, while legitimate interests demands a balancing test and grants the visitor a right to object. Picking and documenting the basis is the operator's job. This is educational, not legal advice.
- Privacy-first analytics
Lower-risk measurement that eases DPIA outcomes.
Sources and verification notes
- EUR-Lex — GDPR Article 35 (Data protection impact assessment)Statutory DPIA requirement.
- Article 29 Working Party — DPIA guidelines (WP248 rev.01)Criteria for likely-high-risk processing.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.