Article 22 GDPR and Automated Decision-Making: the CJEU, the Italian Garante and the Risk-Based Approach Shared with ISO 31000 and 27001

A loan refused in seconds, a job application discarded before any human has read it, a platform worker’s account deactivated by a scoring system, an energy contract denied on the basis of a credit score. Automated decision-making is no longer a conference topic: it is the ordinary way many organisations select, rate, admit and exclude people. Article 22 of the GDPR was written in 2016, before generative AI existed, yet today it is one of the most consequential provisions of the entire Regulation: the Court of Justice of the EU has widened its reach, the Italian Data Protection Authority (the Garante) applies it with growing consistency, and the AI Act has grown up around it. It is worth understanding how the provision really works, because everything converges on one method: risk management, the same logic that underpins ISO 31000 and ISO/IEC 27001.

What Article 22 actually says

The provision is short and frequently misread. Paragraph 1 states that the data subject has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. The Article 29 Working Party guidelines on automated decision-making (WP251), endorsed by the European Data Protection Board, settled the decisive point: this is not a right the individual has to invoke, but a general prohibition that applies by default. If a decision falls within the scope of the provision, it is prohibited unless one of the three exceptions in paragraph 2 applies.

The scope is defined by two conditions. First, the decision must be based solely on automated processing. Practice has dismantled the most common workaround here, namely token human involvement: if a person merely rubber-stamps the algorithm’s output without the competence, the information and the actual authority to change it, the decision remains solely automated. Human involvement that takes a decision outside Article 22 must be meaningful: someone who can look at the data, understand the logic and overturn the result. Second, the decision must produce legal effects or similarly significant ones. Refusing credit, automatically rejecting a job candidate, blocking an account a person’s income depends on, and denying access to essential services all qualify.

The three exceptions in paragraph 2 are contractual necessity (the automated decision is necessary for entering into or performing a contract with the data subject), authorisation by Union or Member State law laying down suitable safeguards, and explicit consent. Even where an exception applies, paragraph 3 imposes the minimum safeguards that are the operational heart of the provision: the right to obtain human intervention on the part of the controller, to express one’s point of view and to contest the decision. Paragraph 4 closes the circle on special categories of data: automated decisions based on Article 9 data are allowed only with explicit consent or for reasons of substantial public interest, and always with specific protective measures.

Around Article 22 sits the transparency package: Articles 13(2)(f) and 14(2)(g) require privacy notices to disclose the existence of automated decision-making and to provide meaningful information about the logic involved, as well as the significance and the envisaged consequences for the data subject; Article 15(1)(h) makes the same information enforceable through an access request. This is the ground on which the most recent battle before the Court of Justice was fought.

The Court of Justice has widened the field

With the SCHUFA judgment (Case C-634/21, 7 December 2023) the Court resolved a problem that created a genuine protection gap in practice: the company calculating the score formally decided nothing, while the company deciding (the bank) argued it was not making a solely automated decision because the score came from outside. The Court cut the knot: the calculation of a creditworthiness score is itself a decision within the meaning of Article 22 where the recipient draws strongly on it to grant or refuse credit. The notion of a decision is broad and can include preparatory acts that in practice determine the final outcome. For anyone producing scores, ratings and rankings destined for third parties, this means falling squarely within Article 22, with everything that follows in terms of legal basis, notices and safeguards.

The second step is the Dun & Bradstreet Austria judgment (Case C-203/22, 27 February 2025), born of an almost trivial case: a mobile operator refuses a consumer a contract worth a few euros per month on the basis of an automated assessment, and the consumer asks to understand how that judgement was reached. The Court clarified what meaningful information about the logic involved means: not handing over the algorithm or the mathematical formula, which would be unintelligible to the average person, but a concise, transparent and intelligible explanation of the procedure and principles actually applied, enabling the data subject to understand which of their personal data was used and how it weighed on the result. And it added the point every business should note: trade secrets are not an absolute veto. Where the controller believes an explanation would expose protected know-how, it cannot simply refuse: the information must be provided to the supervisory authority or the court, which balance the rights at stake and determine what the data subject receives.

Read together, the two judgments say one thing: explainability of automated decisions is not good practice, it is an enforceable legal requirement. Organisations using scoring or automated assessment systems must be able, today, to explain in plain language how their systems reach their outcomes. Those that cannot have a problem no contractual clause will fix.

The Italian Garante: knowability, non-exclusivity, non-discrimination

The Italian supervisory authority did not arrive on this terrain after the Court: it had been working on it for years, and its enforcement record is one of the richest in Europe. Its line can be summarised in three principles the Authority has made explicit over time, in dialogue with Italian administrative case law on algorithmic decisions by public bodies: knowability (people are entitled to know that an automated decision-making process exists and to understand its logic), non-exclusivity (the process must include a human contribution capable of checking and overturning the outcome) and algorithmic non-discrimination (systems must be tested and corrected so they do not produce distorted effects on groups of people).

The best-known strand concerns platform work. With its June 2021 injunction against Foodinho (the Glovo group), fined 2.6 million euros, the Garante challenged a rider-management system based on scores and automated order assignment without adequate information, without guarantees of human intervention and without checks on the accuracy and fairness of results, with a resulting risk of discrimination. A few weeks later came the 2.5 million euro fine against Deliveroo, built on the same framework: the algorithm that allocates work cannot be an uncontestable black box. In November 2024 the Garante returned to Foodinho with a 5 million euro fine: rider accounts blocked or deactivated by automated systems, including facial recognition, with blocking messages that failed to mention the possibility of contesting the decision and obtaining human review. The corrective measures imposed read like a compact compliance lesson: rewrite the communications, guarantee human verification of algorithmic decisions, audit reputational mechanisms that can discriminate.

Outside platform work the line is the same. In the Mevaluate case, a reputational rating platform blocked by the Garante, the Italian Supreme Court (order no. 14381/2021) established a principle that applies to any consent-based system: consent is not valid if the functioning scheme of the algorithm is not knowable by the data subject. In September 2023 the Garante published its ten-point framework for national healthcare services built on artificial intelligence, elevating the three principles to design criteria: effective human supervision, transparency about system logic, prior impact assessment and specific attention to bias, in a sector where a wrong algorithmic decision weighs on people’s health.

The latest piece is very recent and concerns a thoroughly ordinary sector: energy supply. With its decision of 3 July 2026 the Garante fined Hera Comm 5.8 million euros over the creditworthiness verification system applied to around one million prospective customers: inadequate notices about the existence and logic of the scoring, incomplete replies to access requests, and data reused to refine the rating system beyond the declared purposes. The decision explicitly recalls the safeguards of Article 22(3): a person rejected on the basis of a score is entitled to human intervention and to contest the outcome. It is the SCHUFA logic applied domestically, to a mass market, at utility scale.

The risk-based approach: where the GDPR and ISO speak the same language

So much for the rules and their enforcement. For anyone running a company, the real question is different: how do you govern all of this without turning it into paperwork? The answer lies in the architecture of the GDPR itself, which is a risk-based regulation from top to bottom. Article 24 calibrates accountability measures to the nature, scope, context and purposes of processing and to the risks for individuals’ rights and freedoms. Article 25 brings the same logic into design. Article 32 requires security measures appropriate to the risk, not standard ones. And Article 35 mandates a data protection impact assessment where risk is high, listing explicitly, in paragraph 3(a), the very case at hand: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based. A decision caught by Article 22 carries, almost by definition, a DPIA obligation. Recitals 75 and 76 complete the picture: risk must be assessed objectively, by reference to the likelihood and severity of impacts on the data subject’s rights and freedoms.

Anyone who works with management systems will recognise this skeleton immediately. ISO 31000 defines risk as the effect of uncertainty on objectives and structures the process in stages that any well-executed DPIA retraces: establishing the context, risk identification, analysis, evaluation, treatment, monitoring and communication. ISO/IEC 27001 applies the same process to information security: clauses 6.1.2 and 6.1.3 require an assessment methodology with defined acceptance criteria, identification of risks, analysis of likelihood and impact, a treatment plan and the Statement of Applicability; clauses 8.2 and 8.3 require the cycle to be repeated at planned intervals and at significant change. The cycle is the same as the DPIA’s: what changes is the object, not the method.

There is, however, a conceptual difference that must be kept firmly in view, because it is where many integrations between privacy and management systems fail. In ISO 31000 and ISO 27001, risk is measured against the organisation’s objectives: business continuity, confidentiality of assets, compliance, reputation. In the GDPR, risk is measured against the rights and freedoms of natural persons: the risk bearer is not the company but the individual. The practical consequence is sharp: a residual risk the company could comfortably accept for itself (a percentage of false positives in a fraud-prevention system, say) may be unacceptable when it is borne by the person wrongly excluded from a service. Acceptance criteria do not transfer: you cannot accept other people’s risks with the ease with which you accept your own. This is why a certified ISO 27001 ISMS does not absorb the DPIA on its own, and why a DPIA does not replace the ISMS risk assessment.

The good news is that the two worlds integrate well once the difference is clear. In practice it looks like this: a single risk register with two distinct impact dimensions (impact on the organisation and impact on data subjects), the DPIA hooked into the ISMS risk assessment process as the mandatory deep-dive whenever processing falls under Article 35, ISO/IEC 27701 as the privacy extension of the 27001 system, and, for organisations deploying artificial intelligence, ISO/IEC 42001, which brings the impact assessment on individuals into the management system itself. Within this architecture Article 22 stops being an exotic provision and becomes a control to operate: an inventory of automated decisions, their legal qualification, DPIAs, human-intervention measures, explainability, discrimination testing, logging and periodic review.

What the AI Act adds, and what the Digital Omnibus might change

The AI Act does not replace Article 22: it stands beside it. The Regulation classifies as high-risk many of the systems that generate decisions caught by Article 22, from credit scoring to worker management and recruitment, and imposes on their life cycle a risk management system, transparency requirements and effective human oversight. The logic is complementary: the GDPR protects the individual decision about the individual person, while the AI Act regulates the system that produces it. For companies this means the measures converge: the human oversight required by the AI Act and the human intervention required by Article 22(3) should be designed together, once.

Moving in the opposite direction is the Digital Omnibus package presented by the European Commission on 19 November 2025, which among its proposed GDPR amendments also touches the contractual exception in Article 22, clarifying it in a direction more permissive for controllers. The proposal is at the start of the legislative process, the EDPB and the EDPS have already voiced significant reservations on the package in their Joint Opinion 1/2026, and the final text may change substantially. The operational point is simple: none of this is in force today. Decisions must be taken on the current framework, which is the one described above, and organisations that loosen safeguards now, betting on the outcome of a legislative negotiation, are taking a regulatory risk rather than managing one.

Where to start in practice

• map your automated decisions, including those bought from vendors: scoring, automated screening filters, fraud-prevention systems, automatic account or service blocks;
• qualify them: are they solely automated? do they produce legal or similarly significant effects? if so, identify the applicable exception and document it;
• run a DPIA where processing falls under Article 35(3)(a), integrating it into the corporate risk assessment process with the double impact dimension;
• update privacy notices: existence of automated decision-making, logic involved, significance and envisaged consequences, as Articles 13 and 14 require;
• design real human intervention: people with competence, access to the data and actual authority to change the outcome, with reviews properly logged;
• prepare for explainability: be able to tell a data subject, in plain language, how the system reaches its result, without hiding behind trade secrets;
• test outcomes periodically for accuracy and discrimination, and record the tests: it is the accountability evidence supervisory authorities ask for first.

Seen up close, the rules on automated decision-making are not a cage: they are a test of organisational maturity. The companies that can explain their algorithms, correct them and put a competent person at the right point of the process are also the ones that trust those algorithms most, because they know them. PL Consulting supports organisations with impact assessments and the governance of automated processing: see our DPIA service and get in touch to build a framework that holds the GDPR, the AI Act and your management systems together.

Note: every automated decision-making system requires a specific assessment of its context, legal bases and risks. This article is for general information purposes and does not replace professional advice on a specific case. Article updated August 2026.