Data Protection

GDPR Article 22 Automated Decisions: The Documentation Standard Courts Apply

Published 30 June 2026  ·  KairoNull  ·  8 min read

GDPR Article 22 grants data subjects the right not to be subject to decisions based solely on automated processing when those decisions produce significant legal effects or similarly affect them. For financial services, insurance, healthcare, and employment, this is not an edge case. It is standard operating practice.

The compliance challenge is not the right itself. Most organisations have designed manual review procedures and have Article 22 cited in their privacy notices. The challenge is documentation. When a data subject exercises their Article 22 rights, or when a regulator investigates, organisations must produce evidence of the logic used to make the specific decision in question. This is where the gaps appear.

What Article 22 Documentation Actually Requires

Article 22, read alongside Recital 71, requires that data subjects be provided with:

The word "meaningful" is doing significant work here. Supervisory authorities and courts have consistently held that meaningful does not mean a general description of the model type or the data categories used. It means decision-specific logic: what factors applied to this individual, with what weights, producing this output, at this time.

The documentation must be specific, not generic. A privacy notice that says "we use machine learning models to assess creditworthiness using financial history and behavioural data" does not satisfy Article 22 when a specific applicant has been declined and requests the logic of their individual decision.

How Courts Have Interpreted the Documentation Standard

European courts and supervisory authorities have progressively raised the bar on Article 22 documentation through a series of decisions since 2020.

The Austrian data protection authority ruled in 2021 that a general description of model architecture was insufficient to satisfy the meaningful information requirement. The ruling required that organisations be able to identify which input variables were most influential for the specific decision being contested.

The Dutch supervisory authority's 2022 investigation into automated benefit decisions found that the inability to reconstruct the specific logic applied to an individual, as distinct from the general model logic, constituted a systematic violation of Article 22.

The pattern across European decisions is consistent: regulators and courts expect organisations to have captured the decision-specific context at the time of the decision. After-the-fact reconstruction, even from intact model weights and historical data, is not accepted as equivalent to contemporaneous record capture.

Documentation that fails courts

  • General model description
  • List of input data categories used
  • Post-hoc model re-run to reconstruct output
  • Vendor attestation of system behaviour
  • Privacy notice language about automated processing
  • Reconstructed timestamps from application logs

Documentation that satisfies courts

  • Decision-specific input values at time of processing
  • Model version identifier and parameters in effect
  • Output value and confidence metrics captured at generation
  • RFC3161 timestamp proving when decision was made
  • Tamper-evident record that cannot have been altered
  • Chain-of-custody from decision event to evidence record

The Timestamp Problem

One of the most common failures in Article 22 proceedings is the inability to demonstrate when an automated decision was made. Organisations can typically show that a decision was made, and usually at approximately what time, but they cannot produce a timestamp that an independent court would accept as authoritative.

Application-generated timestamps are self-reported. The application writes the timestamp at the moment of decision, but the application could have been configured with an incorrect clock, could have been restarted, or the timestamp field could have been subsequently altered by a database administrator. None of these failure modes are hypothetical. All have arisen in actual proceedings.

RFC3161 timestamps are issued by trusted third-party time authorities and are cryptographically bound to the exact content of the record at the moment of issuance. Altering any element of the record invalidates the timestamp. This is the timestamp standard that courts accept without challenge, because the mathematics cannot be argued with.

Retention Duration Under Article 22

GDPR does not specify a minimum retention period for Article 22 documentation. This is frequently misunderstood as meaning that organisations can retain records for short periods. The principle of storage limitation (Article 5(1)(e)) applies, but so does the principle of accountability (Article 5(2)): organisations must be able to demonstrate compliance.

In practice, Article 22 documentation should be retained for at least the duration of any applicable limitation period for legal claims arising from the decision. For credit decisions in most European jurisdictions, this means a minimum of five to seven years. For employment decisions, it may be longer. For healthcare decisions, longer still.

Short retention is a liability, not a protection. Organisations that delete Article 22 records before a claim arises lose the ability to demonstrate that the decision was made lawfully. Courts draw adverse inferences from missing documentation. The absence of evidence is not evidence of absence in regulatory proceedings.

The AI Act Intersection

From 2 August 2026, many automated decision systems that previously needed to satisfy only Article 22 will also be subject to the EU AI Act's Article 12 logging requirements. The two frameworks overlap significantly in their documentation requirements but are not identical.

Building evidence infrastructure that satisfies both frameworks from a single capture event is more efficient than maintaining parallel documentation systems. The technical requirements of Article 12 (tamper-evident, timestamped, automatically generated) are a superset of what Article 22 proceedings require.

Sectors With the Highest Article 22 Exposure

Article 22 applies wherever automated processing produces significant effects. The sectors with the highest volume of complaints and enforcement actions are:

What a Compliant Article 22 Evidence Record Contains

Based on supervisory authority guidance and court decisions, a compliant Article 22 evidence record should include:

  1. Unique identifier for the specific decision event
  2. Exact input data used in the decision (not categories, but values)
  3. Model version identifier, including any fine-tuning or configuration parameters
  4. Policy gates or threshold checks that were applied
  5. Output value and any confidence or probability metrics
  6. RFC3161 timestamp from a trusted time authority
  7. SHA-256 hash of the record, chained to the preceding record
  8. Identifier of the natural person whose data was processed

Items 6 and 7 are what elevates the record from a log to evidence. Without them, the record can be challenged on the grounds that it could have been created, altered, or backdated after the fact. With them, the record is mathematically self-proving.

Article 22 evidence that survives regulatory challenge

KairoNull captures decision-specific records at the moment of automated processing, applies RFC3161 timestamping, and chains them with SHA-256 into a tamper-evident ledger. Records are independently verifiable by courts, regulators, and data subjects without requiring access to KairoNull systems.

Book a 30-min scoping call