CNIL Fines EXTIA: The GDPR Risk Is the Process, Not the Case

300,000 EUR is the fine the CNIL imposed on EXTIA — but the number that should really worry compliance officers is a different one: of 265 erasure requests received in a single year, more than three quarters went unanswered or were poorly handled. This is not the story of one refusal. It's the story of a process that couldn't handle the load.

What happened

On 21 July 2026, the restricted committee of the CNIL, France's data protection authority, fined EXTIA, an IT and engineering recruitment firm, 300,000 EUR. The decision, published by the European Data Protection Board on 11 September 2026, followed an investigation opened in 2025 as part of the Coordinated Enforcement Framework action on the "right to erasure", after several former employees and candidates had complained to the CNIL about difficulties exercising that right.

An audit carried out in April 2025 uncovered the case's central figure: in 2024, EXTIA received 265 erasure requests, mostly from candidates and occasionally from former employees. Of these, 12 were never processed at all; another 166 people were never informed of the outcome of their request; a further 27 received a response, but late, with delays of up to several months against the one-month legal deadline. In total, more than 205 of 265 requests — over three quarters — went without a proper outcome or without adequate information. The CNIL framed the case around two distinct breaches: failure to process requests (Article 17 GDPR) and failure to inform data subjects of the outcome (Article 12 GDPR).

Why it matters: the process, not the single case

The failure rate

A single denied erasure request is a mistake. A 77% failure rate across an entire year of requests is a symptom: the process meant to intake, review and close data subject requests simply couldn't handle the volume it received. The 193 people affected by the Article 12 breach alone — nearly three requesters out of four — show that the weak point isn't only "deleting the data", but communicating that it was done. That detail matters twice over: for the data subject, left without an answer, and for the company, which loses the evidence that it acted correctly even when it did.

From isolated error to systemic risk

When a process fails at this scale, the cause is rarely bad faith: it is almost always the absence of a tracked workflow, with clear owners, SLAs and periodic checks. The CNIL noted that EXTIA had already been reminded twice of these same obligations before the sanction — a detail that weighed on the fine amount and confirms that an unmeasured risk tends to repeat, year after year, until it becomes a public case.

The link to ISO 27001, control A.5.34

What the control requires in practice

Control A.5.34 of Annex A in ISO/IEC 27001:2022 ("Privacy and protection of PII") requires organisations to identify and comply with legal obligations on privacy and personal data protection, including handling data subject requests. A written policy is not enough: the control is verified by measuring whether requests are actually received, logged, reviewed within deadlines, and closed with proper communication to the data subject.

Where the process typically breaks

In practice, the most common breaking points are four: intake (the request isn't recognised as such and lands in a generic inbox), SLA (no formal deadline that triggers escalation), traceability (no log proving who did what and when), and escalation (no second-level owner when the first one doesn't respond). Judging by the numbers, the EXTIA case appears to touch at least the first three.

For organisations certifying ISO 42001: traceability extended to training data

Why an erasure request can also reach training datasets

For organisations that develop or use AI systems, the scope of erasure requests doesn't stop at classic operational systems (CRM, ATS, HR). If a data subject's personal data ended up in a training dataset, an erasure request can, in principle, also concern that dataset and any derived models — a risk extension many organisations haven't mapped yet.

What to check today in your AI register

Without citing a specific control not yet consistently established for this scenario, the practical recommendation is to check whether your AI processing register (also required under ISO/IEC 42001) traces training data provenance back to the individual, where applicable, and whether a procedure exists to honour an erasure request that also touches these datasets.

Practical checklist

To measure — not just declare — the effectiveness of your data subject rights controls:

• Tracked SLA for every request, with a one-month deadline and an automatic alert before it expires.
• Audit trail recording intake, review, decision and communication to the data subject.
• Periodic testing with simulated requests, to verify that the process — not just the policy — actually works.
• Regular reporting to the DPO on the volume and outcome of requests received.
• A clear escalation path for when the first owner doesn't respond within internal deadlines.

Conclusion

The EXTIA case isn't a warning about one careless company: it's proof that a data subject rights process can look fine on paper and fail in practice — and it's that gap, not the policy, that costs 300,000 EUR. Better to find that out with an internal audit than an external one.

Sources

• EDPB, "Failure to respect the rights of individuals: The CNIL fined EXTIA 300 000 EUR", 11 September 2026.
• CNIL, "Failure to respect the rights of individuals: EXTIA fined 300,000 euros".
• Regulation (EU) 2016/679 (GDPR), Articles 12 and 17.
• ISO/IEC 27001:2022, Annex A, control A.5.34 — Privacy and protection of PII.