GDPR DPIA: When It’s Mandatory and How to Conduct a Data Protection Impact Assessment

  • A Data Protection Impact Assessment (DPIA) is a structured risk-assessment process required by Article 35 of the GDPR.
  • It is mandatory before any processing likely to result in a high risk to individuals’ rights and freedoms — especially involving AI, profiling, large-scale sensitive data, or public monitoring.
  • The data controller is responsible; processors must assist; the DPO advises. A compliant DPIA must describe the processing, justify its necessity and proportionality, assess risks, and document mitigations.
  • Skipping a required DPIA can lead to fines of up to €10 million or 2% of global annual turnover (whichever is higher) under Article 83(4), plus processing bans and reputational damage.

A Data Protection Impact Assessment, commonly called a DPIA, is a structured process under the EU’s General Data Protection Regulation (GDPR) that helps organizations identify and minimize privacy risks before they start a high-risk data processing activity. “Personal data” means any information relating to an identified or identifiable natural person — names, emails, location data, health information, and similar.

A DPIA puts the GDPR principle of “data protection by design and by default” (Article 25) into practice. Under Article 35(1) GDPR, where a type of processing — particularly using new technologies, and taking into account the nature, scope, context, and purposes of the processing — is likely to result in a high risk to the rights and freedoms of natural persons, the controller must, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.

In plain terms: if your project could meaningfully affect people’s privacy, run a DPIA first.

Primary responsibility for the DPIA lies with the data controller — the entity that determines the purpose and means of processing personal data (for example, a SaaS company that decides to deploy AI-driven user profiling).

Key responsibilities are split as follows:

  • Data controllers conduct the DPIA before starting high-risk processing.
  • Data Protection Officers (DPOs), where designated, must be consulted by the controller under Article 35(2) GDPR.
  • Data processors (e.g., cloud or analytics providers acting on behalf of the controller) must assist the controller and provide necessary information under Article 28(3)(f) GDPR.
  • Supervisory authorities publish lists of processing operations that require a DPIA (Article 35(4)) and may publish lists of those that do not (Article 35(5)). In Slovenia, the Informacijski pooblaščenec (Information Commissioner) maintains the local list.

Practical tips for SME controllers:

  • Appoint a DPO if you fall within the scope of Article 37 and involve them early.
  • Build a cross-functional DPIA team (legal, IT/security, product, operations).
  • Require processors to cooperate under your Data Processing Agreement.
  • Document every step — under Article 5(2), accountability requires evidence.

The earlier the DPIA enters your project planning, the cheaper and easier compliance becomes.

A DPIA is required where processing is likely to result in a high risk to the rights and freedoms of natural persons — including risks of discrimination, identity theft, financial loss, reputational damage, or loss of confidentiality.

Article 35(3) GDPR identifies three core triggers where a DPIA is, in particular, required:

  1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects concerning the individual or similarly significantly affect them. Examples: AI-driven credit scoring, automated loan or insurance approvals, AI hiring tools.
  2. Processing on a large scale of special categories of personal data (Article 9 GDPR — health, biometric data used for unique identification, genetic data, racial or ethnic origin, religious or philosophical beliefs, sexual orientation, etc.) or of personal data relating to criminal convictions and offences (Article 10 GDPR).
  3. Systematic monitoring of a publicly accessible area on a large scale — for example, extensive CCTV networks, smart-city sensors, or biometric access systems in public spaces.

A single project can hit more than one trigger. A facial-recognition CCTV deployment, for instance, independently triggers both large-scale public monitoring and large-scale processing of biometric data under Article 9.

EDPB Criteria for Identifying High-Risk Processing

Beyond Article 35(3), the European Data Protection Board (EDPB) has endorsed nine criteria (originally Article 29 Working Party Guidelines WP248) for identifying high-risk processing:

  1. Evaluation or scoring (including profiling).
  2. Automated decision-making with legal or similar significant effect.
  3. Systematic monitoring.
  4. Sensitive data or data of a highly personal nature.
  5. Data processed on a large scale.
  6. Matching or combining datasets.
  7. Data concerning vulnerable data subjects (children, employees, patients).
  8. Innovative use of new technological or organizational solutions (e.g., AI, IoT, biometrics, blockchain).
  9. Processing that prevents data subjects from exercising a right or using a service or contract.

Rule of thumb: if your processing meets two or more of these criteria, a DPIA is generally expected. For example, a Web3 KYC platform combining biometric checks with profiling and innovative blockchain technology would likely hit several criteria at once.

Article 35(7) GDPR sets the minimum required content of a DPIA. Your assessment must contain at least:

  • A systematic description of the envisaged processing operations and the purposes, including, where applicable, the legitimate interests pursued by the controller.
  • An assessment of the necessity and proportionality of the processing operations in relation to those purposes.
  • An assessment of the risks to the rights and freedoms of data subjects.
  • The measures envisaged to address those risks — including safeguards, security measures, and mechanisms to ensure the protection of personal data and to demonstrate GDPR compliance.

Under Article 35(9), the controller must, where appropriate, seek the views of data subjects or their representatives on the intended processing (without prejudice to commercial confidentiality or processing security).

A practical DPIA checklist for SMEs:

  • Map the data flows — collection, storage, transfers, sharing, retention, deletion.
  • Justify the lawful basis under Article 6 (and Article 9 for special categories).
  • Apply data minimization — collect only what you genuinely need.
  • Rate risks by likelihood and severity.
  • Define mitigations — encryption, pseudonymization, access controls, retention limits, staff training, vendor due diligence.
  • Embed outcomes into the product or project before go-live.

Done well, a DPIA converts abstract privacy risks into concrete, auditable safeguards.

A DPIA must be carried out before processing begins — ideally at the design phase, when changes are still inexpensive.

It is mandatory whenever the processing is likely to result in a high risk to individuals’ rights and freedoms, particularly in the three Article 35(3) scenarios discussed above.

Under Article 35(11) GDPR, the controller must review the DPIA where necessary, at least when there is a change in the risk represented by the processing. The GDPR does not impose a fixed interval, but supervisory authorities — including Slovenia’s Informacijski pooblaščenec — commonly recommend periodic reviews (often every two to three years, or whenever the processing or technology changes materially).

If your DPIA shows that the processing would result in a high residual risk even after mitigations, Article 36 GDPR requires the controller to consult the supervisory authority before processing starts.

Exemptions are narrow. Under Article 35(10) GDPR, a DPIA is not required where all of the following apply:

  1. The processing has a legal basis under Article 6(1)(c) (legal obligation) or Article 6(1)(e) (public interest / official authority);
  2. EU or Member State law regulates the specific processing operation; and
  3. A DPIA has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis.

Outside of this narrow carve-out, where processing simply doesn’t meet any high-risk trigger, no DPIA is required — but it is still good practice (and good accountability evidence) to document the reasoning for that conclusion.

Failing to conduct a required DPIA, performing it inadequately, or failing to consult the supervisory authority when triggered carries significant consequences.

Administrative fines. Under Article 83(4)(a) GDPR, infringements of Articles 25 to 39 — which include the DPIA obligation (Article 35) and the prior consultation duty (Article 36) — are subject to fines of up to €10 million, or, in the case of an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.

Corrective powers. Under Article 58 GDPR, supervisory authorities can issue warnings and reprimands, order the controller to bring processing into compliance, and impose a temporary or definitive limitation, including a ban, on the processing.

Civil liability. Under Article 82 GDPR, individuals who suffer material or non-material damage as a result of a GDPR infringement have the right to claim compensation from the controller or processor.

Operational and reputational damage. Beyond regulators, projects often have to be re-engineered after launch, partnerships and B2B contracts can be jeopardized by failed audits, and customer trust is difficult to rebuild after a public privacy incident.

A well-documented DPIA is, by contrast, powerful evidence of accountability under Article 5(2) GDPR and your best defense if a regulator comes knocking.

A DPIA is not paperwork for paperwork’s sake — it is a practical risk-management tool that lets modern businesses, especially those building AI, SaaS, Web3, and data-driven products, innovate with confidence. Run early, reviewed when things change, and properly documented, the DPIA turns potential privacy pitfalls into competitive advantages built on trust.

Compliance with the law prevents the flaw — and in the digital economy, that is simply smart business.

At Kiroptera Consulting, we are your legal sidekick for the digital economy — helping SMEs, SaaS companies, AI startups, and Web3 ventures navigate GDPR compliance, DPIAs, EU AI Act obligations, and international data protection without the stuffy law-firm vibes.

Book a free 30-minute “no strings” consultation and let’s check whether your project triggers a DPIA — before the regulators do.

1. What does DPIA stand for in GDPR? DPIA stands for Data Protection Impact Assessment. It is a structured assessment required by Article 35 GDPR to evaluate and mitigate privacy risks before starting high-risk processing of personal data.

2. When is a GDPR DPIA mandatory? A DPIA is mandatory whenever processing is likely to result in a high risk to individuals’ rights and freedoms. Article 35(3) GDPR specifically requires one for systematic profiling with legal/significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of public areas.

3. Who is responsible for conducting a DPIA? The data controller is responsible. The Data Protection Officer (DPO), if appointed, must be consulted. Data processors must assist the controller under Article 28(3)(f) GDPR.

4. Is a DPIA required for AI systems? Often, yes. AI systems frequently involve profiling, automated decision-making with significant effects, innovative technology, or large-scale data processing — any of which can trigger a mandatory DPIA under Article 35 GDPR. The EU AI Act introduces additional risk-assessment obligations on top of the GDPR.

5. What are the fines for not doing a DPIA? Under Article 83(4) GDPR, fines for breaches of Article 35 can reach €10 million or 2% of total worldwide annual turnover, whichever is higher, plus potential processing bans under Article 58 and civil compensation claims under Article 82.

6. How often should a DPIA be reviewed? Under Article 35(11) GDPR, the controller must review the DPIA at least when the risk represented by the processing changes. Supervisory authorities commonly recommend periodic reviews every 2–3 years, or sooner upon material changes.

7. Does a small business need a DPIA? The DPIA obligation does not depend on company size. If your processing meets the high-risk criteria — for example, an SME using AI-based profiling or processing health data on a meaningful scale — you must conduct a DPIA regardless of headcount or revenue.

Have specific questions?

Not ready for a call

No worries! In the meantime, subscribe to our Knowledge center to stay updated on the latest legal developments.

And don't worry, it's free!

Share the Post:

Related Posts

Related Posts
Loading related posts…
Scroll to Top