Art. 35 GDPR – Data protection impact assessment
| Art. 35(1) | Where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. | high-risk trigger |
| Art. 35(2) | The controller shall seek the advice of the data protection officer, where one is designated, when carrying out a data protection impact assessment. | DPO consulted |
| Art. 35(3) | An assessment is required in particular for: a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects; large-scale processing of special category or criminal offence data; or systematic monitoring of a publicly accessible area on a large scale. | mandatory cases |
| Art. 35(7) | The assessment shall contain at least: a systematic description of the envisaged processing and its purposes; an assessment of necessity and proportionality; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks. | minimum content |
| Art. 35(9) | Where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of the processing. | consultation |
| Art. 35(11) | Where necessary, the controller shall carry out a review to assess whether processing is performed in accordance with the assessment, at least when there is a change in the risk represented by the processing. | kept current |
Article 35 doesn’t prohibit anything. It is the discipline that has to happen before a high-risk processing operation goes live: a documented assessment of what the processing is, whether it’s necessary and proportionate, what could go wrong for the people affected, and what will be done about it. Article 35(1) requires this prior to the processing, not as a document written up afterwards to answer a regulator’s question.
The practical consequence is that an organisation can have a privacy policy, signed contracts with every vendor, and a folder of paperwork labelled “DPIA,” and still be in breach of Article 35 if none of it actually assessed the risk of the specific high-risk processing it deployed. Every fine below turns on exactly that gap: a system went live before its risk was ever genuinely assessed, or the document on file wasn’t a real assessment.
Key Facts
| Chapter | Chapter 4 – Controller and processor (Art. 24–43), Section 3 – Data protection impact assessment and prior consultation (Art. 35–36) |
|---|---|
| Applies to | Every controller, before starting a type of processing likely to result in a high risk to individuals’ rights and freedoms |
| Maximum fine | €10.000.000 or 2% of worldwide annual turnover, whichever is higher, for the Article 35 obligation on its own (Art. 83(4)(a)). Where the same processing also breaches a higher-tier provision such as Art. 6 or 9, the total fine is capped at the amount for the gravest infringement, which can run well above the Article 35 ceiling alone |
| In force since | 25 May 2018 |
| Explained by recitals | 84, 90, 91, 92 |
| Depends on | Art. 24 for the controller’s general accountability duty, Art. 39(1)(c) for the DPO’s role in a DPIA, Art. 36 for consulting the supervisory authority where residual risk stays high |
| Who else publishes triggers | National supervisory authorities publish their own list of processing types requiring a DPIA under Art. 35(4); both the Garante and the AEPD have issued one |
| Closest UK equivalent | UK GDPR Art. 35, identical wording; the ICO maintains a separate Art. 35(4) list |
Does This Processing Actually Need a DPIA?
Article 35(3) names three cases where an assessment is mandatory, but the language is abstract enough that real deployments slip past it. This is where each of the fines below actually started.
| Trigger | What’s typically missed | Governing provision |
|---|---|---|
| Systematic, automated evaluation of a person, including profiling, that produces legal or similarly significant effects | A scoring or shift-assignment algorithm is treated as an operational rollout rather than as processing that decides who gets work | Art. 35(3)(a) |
| Large-scale processing of special category data (Art. 9) or criminal offence data (Art. 10) | Biometric identifiers such as a face or voice template are treated as a convenience feature rather than as special category data in their own right | Art. 35(3)(b) |
| Systematic monitoring of a publicly accessible area on a large scale | Camera or location-based monitoring is assumed to be low-risk because the area itself is public | Art. 35(3)(c) |
| Any criteria on the supervisory authority’s own published DPIA list | The national list under Art. 35(4) is never checked because Art. 35(3) is read as the complete test | Art. 35(4) |
| A new technology deployed at scale, even where the underlying data type is familiar | “We’ve always processed this kind of data” is used to skip a fresh assessment of the new method of processing it | Art. 35(1), Recital 91 |
Who Carries the Art. 35 Burden When a Vendor or Platform Built the System?
This is the judgment call that catches every organisation that buys rather than builds its algorithm, its biometric kiosk, or its platform. The Article 35 obligation sits with the controller deploying the system, whoever engineered it.
| Arrangement | Who must carry out the DPIA | What that means in practice |
|---|---|---|
| You build and run the automated system in-house | You, as controller | Run the assessment before launch, and again whenever you retrain the model or change the scoring logic |
| A vendor supplies the platform or algorithm and you deploy it to manage people | Still you, as controller of that processing | A vendor’s own “DPIA-ready” documentation is an input, not a substitute; it has to be adapted to your actual data subjects and your actual deployment |
| You and the platform provider jointly determine purposes and means | Both, under an Art. 26 arrangement | Allocate in the arrangement who runs and updates the DPIA, and who informs data subjects |
| A processor operates the system on your documented instructions | You, as controller | The Art. 28 contract governs the processing, but the Art. 35 assessment burden stays with you |
GDPR Article 35 Fines: Enforcement Cases and Amounts
Article 35 rarely appears alone in a decision, but two of the cases below rest on it almost entirely: no other provision does the real work of explaining the fine. Aena and Foodinho each deployed technology that was high-risk by its nature, facial recognition and algorithmic worker management, without an assessment on file that could show the risk had genuinely been thought through first. Deliveroo and FC Barcelona are listed because their Article 35 findings sit alongside other, better-known infringements and are each documented at their own source below the table.
| Organisation | Authority | Decision date | Fine |
|---|---|---|---|
| Aena, S.M.E., S.A. | AEPD (Spain) | 25 Nov 2025 | €10.043.002 |
| Foodinho S.r.l. | Garante (Italy) | 10 Jun 2021, further decision 22 Nov 2024 | €2.600.000 + €5.000.000 |
| Deliveroo Italy s.r.l. | Garante (Italy) | 22 Jul 2021 | €2.500.000 |
| Fútbol Club Barcelona | AEPD (Spain) | Mar 2026 | €500.000 |
The Deliveroo Italy decision is documented in full in the Garante’s own registry; its Article 35 finding is one of eight infringements in a single order and turns on the same point as Foodinho’s, that the algorithmic management of riders was rolled out without ever assessing its risk. The FC Barcelona decision turns on a DPIA that existed in form but not in substance, a distinction worth reading given how many organisations treat a completed template as compliance.
Recitals That Explain Article 35
Article 35 Compliance Checklist
Every fine on this page traces back to a DPIA that was never done, done too late, or done as a template rather than a genuine assessment. Secure Privacy’s consent and data governance platform keeps a live record of which processing activities need one and when they were last reviewed, so the answer to “do we have a DPIA for this” isn’t a scramble the day a regulator asks.