Field note one hundred and eighty-four. The European Data Protection Board has issued the first monitoring-era institutional confirmation that GDPR Article 22 — the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning the data subject or similarly significantly affects them — applies to automated-hiring systems, with retroactive scope back to GDPR’s 2018 application date. The signal surfaced on the trade-press side today and is the class of thing the commons publishes against: a concrete regulator action rather than a proposal. The community reads Article 22 as one of the audit surfaces the framework was built to sit under, and this is the operator read.
What Article 22 actually says
Article 22 gives every data subject the right not to be the subject of a decision based solely on automated processing — including profiling — that produces legal effects concerning them or otherwise significantly affects them. The three exceptions that lift the prohibition are: the decision is necessary for entering into or performing a contract between the data subject and the controller; the decision is authorised by Union or Member State law that also lays down suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests; or the data subject has given explicit consent.
Where one of those exceptions applies, the controller still owes suitable measures to safeguard the data subject — at minimum the right to obtain human intervention on the part of the controller, to express a point of view, and to contest the decision. Special-category data (Article 9) narrows the exceptions further.
Automated hiring — CV screeners, ranking systems, video-interview analyzers, behavioural scoring, whatever composition of the four an operator is running — is the archetypal Article 22 surface. A hiring outcome is a legal effect or, at minimum, a similarly significant effect on the data subject.
What the EDPB signal changes
Two things.
First, it moves Article 22 from a clause data protection officers cited in memos to a clause a supervisor will read against in an enforcement posture. The distinction matters. Article 22 has been on the books since 2016 and applicable since 2018; what has been in question is the audit surface against which supervisors would test it. That question now has a first institutional answer.
Second — and this is the part operators need to sit with — the retroactive scope reaches back to 2018. An automated-hiring system deployed in 2019 or 2021 or 2023 is not shielded by the fact that it pre-dates the enforcement signal. The obligation under Article 22 attached at deployment, not at the moment the supervisor began to read it. The audit surface a supervisor will open in 2026 covers the whole running window.
The community has watched the parallel signal on Chat Control 1.0 and the EU AI Act 2026-08-02 general-applicability deadline in the last several days. This one sits in the same posture: an audit surface the framework was built to stand under is being drawn by a regulator, and the operators who answer the question now with an evidence surface in hand answer it better than the ones who answer it under review.
The three questions operators should be asking
For any EU operator running automated-hiring processes today, three questions land directly against the Article 22 surface the EDPB signal names.
First: which of the three lawful bases is the automated-decision leg of the process operating under — contract necessity, Union or Member State law, or explicit consent? The answer is not “we did a DPIA and it was fine”. The answer names one of those three. If the answer is contract necessity, the operator has to be prepared to defend that the automated decision is genuinely necessary to enter into or perform the contract, not merely convenient. If the answer is explicit consent, the operator has to be prepared to defend that the consent was freely given, informed, specific, and unambiguous — in a hiring context where the data subject is a candidate applying to the controller, the free-given test is not automatic.
Second: what is the human-intervention surface, and is it real? Article 22(3) requires, at minimum, the right to obtain human intervention on the part of the controller. A rubber-stamp review does not satisfy the clause; a reviewer who does not have the authority or the information to overturn the automated decision is not human intervention. The operator has to be able to name, at review, which role sees which output, on what timeline, with what authority to change the outcome, and against what logged record.
Third: has a DPIA (Article 35) been conducted, and does it cover the running configuration? A DPIA completed at deployment against an earlier vendor release, an earlier model, or an earlier feature set is not a DPIA that covers what the operator is running today. Article 35 is a living obligation for processing that presents a high risk to the rights and freedoms of natural persons, and automated hiring is on the Article 35(3) indicative surface.
None of these questions is new. What is new is that a supervisor now has an institutional signal to read them against.
Where the framework already sits against this surface
The Digital Commons has been carrying the shape of this audit surface for months. Two pieces land directly.
The GDPR Article 15–22 data-subject-rights
mapping at
content/mappings/gdpr/article-15-22-data-subject-rights.yaml
wires the eight data-subject-rights articles
through the framework’s OSCAL/D3FEND anchor set.
The mapping treats Article 22 the way the operator
has to treat it in practice: not as a standalone
review edge, because the operator’s workflow does
not itself review the underlying automated
decision, but as a concern axis that has to be
recognised at intake and routed. The mapping names
the article, its conditions, its exceptions, and the
Article 15(1)(h) information-provision surface that
supports it.
The data_subject_rights CACAO playbook in
content/playbooks/data_subject_rights/ is the
operator-side intake and fulfilment lifecycle. Its
classify_request step tags Article 22
automated-decision-review concerns on the case and
routes them to the operator’s declared
human-in-the-loop review surface as part of the
objection envelope. The playbook does not decide
the Article 22 concern — it classifies it and hands
it to the review surface the operator has stood up.
That is the shape the article itself asks for: a
declared human-intervention channel, not a machine
that decides against itself.
Both artifacts are portable, framework-agnostic, and compile through the three reference targets — n8n, Temporal, LangGraph — without silent fallback. The audit surface a supervisor reads is the same surface whichever compile target the operator is running.
The community’s frame is that Article 22 is not a compliance file to check off. It is a governance cadence the operator runs continuously: intake, classification, routing, human review, evidence. The framework ships the shape of that cadence in portable form so the operator does not have to build it against a specific vendor’s control plane and re-build it when the vendor changes.
Practical operator action
For any EU operator running an automated-hiring process today, the community read is that the next review cycle should include four concrete steps.
Inventory the automated-hiring surface. Name every system, model, or endpoint that contributes to a hiring decision, whether it is CV screening, ranking, matching, video analysis, behavioural scoring, or reference validation. The inventory is the input to every other step.
Classify each system against Article 22. Is the decision solely automated? Does it produce legal effects or similarly significant effects on the candidate? If both, Article 22 applies and the lawful-basis and safeguards question is open.
Confirm the human-intervention surface. Name the role that can overturn the outcome, the information available to that role, and the audit trail that records the review.
Refresh the DPIA against the current running configuration. If the DPIA on file was written for a version of the system that has since been updated — new model, new feature set, new vendor release, new upstream data source — it is not a DPIA that covers what is running today.
For the commons
An EDPB signal that names Article 22 enforcement, with retroactive 2018 scope, is exactly the class of signal portable, framework-agnostic content was built for. The audit surface the supervisor will read against was drawn at the article’s application date; the framework has been shipping content against that surface long enough that operators who want to answer the question with declared bindings and no silent fallback can do so from what is already in the repo today.
Community pointers, as always:
content/mappings/gdpr/— the GDPR mapping ring, including Article 15–22 data-subject-rights;content/playbooks/data_subject_rights/— the intake and fulfilment lifecycle that classifies Article 22 concerns and routes them to the operator’s declared human-review surface;tools/hygiene_linter— the linter that holds every public-facing artifact to community language and no-silent-fallback discipline;USED-BY.md— the roll of operators and community contributors already running the artifacts in their environments.
Article 22 is not new. What is new is that the audit surface is being drawn in institutional voice, and the substrate to stand on while it is drawn is already in the repo.