Free preliminary assessment
FRENES
← The journal / Data & GDPR

Data breaches France 2026 – February report | LEGALPROTECH

Publication from our firm · published on February 28, 2026

Data breaches in France 2026 - Cybersecurity and GDPR protection
France faces an unprecedented cyber crisis at the start of 2026 – © LEGALPROTECH-Avocats

DATA BREACHES IN FRANCE

February 2026 review — What every organization should remember

By Christelle REYNO — Lawyer at the Bar of Guadeloupe, Saint-Martin and Saint-Barthélemy

DPO certified CNIL-AFNOR • LEGALPROTECH-AVOCATS • Baie-Mahault, Guadeloupe

What the law requires, and what these violations reveal

France is going through an unprecedented cyber crisis at the start of 2026. More than a hundred incidents reported, 60 million lines of data compromised in four weeks, and public organizations among the first victims: the picture is alarming. But beyond the numbers, what strikes us, as DPOs, is the recurrence of the same root causes – causes that the GDPR, precisely, is designed to prevent.

This article reviews the most notable violations of the period, identifying for each what could — and should — have been done. It is not a question of burdening victims but of reminding us that GDPR compliance is not an administrative constraint: it is a protection system whose effectiveness depends entirely on the rigor of its implementation.

The fundamental principles that these violations have in common

The GDPR sets out several clear requirements that each data controller and processor is required to respect. The violations analyzed below reveal that these principles were, in most cases, either ignored or insufficiently applied:

  • Article 5 — Principles relating to processing
  • Data minimization: collect only what is strictly necessary for the declared purpose
  • Accuracy, integrity and confidentiality: protect data from unauthorized access
  • Retention limitation: do not keep data beyond its useful life
  • Article 25 — Data protection by design
  • Design systems by integrating data protection from the development phase, not in response to an incident
  • Article 32 — Security of processing
  • Implement technical and organizational measures adapted to the level of risk: encryption, strong authentication, access control, regular penetration tests
  • Article 28 — Subcontractors and co-responsible parties
  • Contractually ensure that partners, service providers and co-responsibles offer equivalent security guarantees

Three systemic errors to be corrected urgently

  1. “It’s the State, it’s national, therefore it’s secure” — A dangerous presumption

One of the most widespread illusions is to consider that a national or interministerial platform is, by nature, protected. The violations of FICOBA, DINUM, France Travail and OFB demonstrate the opposite. The “nationality” of a service provider or platform does not constitute any guarantee of security. The GDPR makes no distinction: whether the data controller is public or private, French or European, its obligations are identical. Working with a State platform does not exempt from a risk analysis, a contractual security clause, nor a verification of the measures put in place.

  1. Have a DPO — and “really listen”

Several of the victim organizations had a DPO or GDPR referents. In certain documented cases — notably France Travail — the impact analyzes (AIPD) had correctly identified the risks and recommended corrective measures. It seems that measures have not always been deployed. The CNIL also considers it an aggravating circumstance.

A DPO is not a display function. Its role is to alert, advise and support. When its recommendations are ignored by management or IT departments, the organization is exposed not only to a violation, but to an aggravated sanction. Appointing a DPO is not enough: you must give them the means to act and commit to following their recommendations.

  1. Each institution must have an internal Information Systems Security Manager (CISO)

The violations of this period highlight a critical blind spot: the absence, in many public institutions and companies processing sensitive data, of a dedicated CISO with real authority and their own budget. Cybersecurity cannot be managed as a peripheral function entrusted to an external service provider or absorbed by an already overloaded IT department.

An internal CISO allows early detection of abnormal behavior, rapid response to incidents, continuous implementation of security policies and permanent dialogue with the DPO. This function is no longer optional — it is strategic.

 

Below is an analysis of certain violations from February 2026.

 

CEGEDIM SANTÉ — The betrayal of the comment field

🔗 Source: Ministry of Health confirms — franceinfo.fr

🔗 Source: CNIL 2024 decision — cnil.fr

The facts

Revealed on February 26, 2026 during the 8 p.m. news on France 2, this violation is one of the most serious ever documented in the health sector in France. Via an intrusion into the MLM software (MonLogicielMedical.com) used by 3,800 doctors, the dumpsec cybercriminal group is said to have exfiltrated the data of millions of patients.

The administrative data exposed includes first and last names, dates of birth, postal and electronic addresses, telephone numbers. For several thousand patients, it was the free annotations entered by doctors in the comment fields that were exfiltrated: extremely private information.

The central point: the free comment areas

What makes this violation particularly serious is not so much the volume of administrative data exposed – certainly considerable – as the content of the free comment fields. These areas have been used by some doctors to record extremely sensitive information:

  • Serological status (particularly HIV)
  • Sexual orientation
  • History of sexual violence, incest, rape
  • Criminal record
  • Intimate family situations
  • Political, religious data

Prominent political figures appear in this database. This “administrative comment” field, left in free text at the discretion of each practitioner, has become the vector of a violation of unprecedented scale and intimacy.

Points of vigilance and recommendations

Essential Measure — Organizational and Behavioral

The most decisive measure is not technical: it is behavioral. You should never enter sensitive data — within the meaning of Article 9 of the GDPR — in free text fields.

This rule, which should be taught during the initial training of healthcare professionals and recalled in any policy for the use of medical software, would have been enough to neutralize most of the harm. Software can be compromised: what is not entered cannot be stolen.

Comment fields are functional spaces, not medical files. They often benefit from no differentiated encryption, no specific access restrictions, and no content control. Entering data relating to health, sexuality or religion therefore amounts to a violation of the GDPR.

Additional technical measures for the software publisher

  • Encryption of free fields at rest: text annotations must be encrypted individually, distinctly from structured administrative data
  • Multi-factor authentication (MFA) required for all physician access
  • Logging and anomaly detection: abnormal requests on doctor accounts can trigger an immediate alert

It should be remembered that on September 5, 2024, the CNIL imposed a fine of 800,000 euros against the company for having processed health data without authorization, as part of a “medical observatory”. In this case the data should have been anonymized and not pseudonymized.

 

💡 Advice from your CNIL-AFNOR certified DPO

→ Train user doctors to NEVER enter sensitive information (health, sexuality, religion, legal data) in the comments or notes fields of any software.

→ Check, in contracts with medical software publishers, the security, encryption and liability clauses in the event of a violation — this is an obligation under Article 28 GDPR.

→ Require documentation from your publisher on the security measures applied to unstructured fields: if this documentation does not exist, this is already a red flag.

→ Remind healthcare professionals: what should not be circulated should not be seized. Technical prevention cannot compensate for poor data entry practice.

CAF / DINUM — RSA data exposed by the inter-administration chain

🔗 Source: FrenchBreaches — Analysis of the CAF/DINUM incident

🔗 Source: Official CNAF declaration — caf.fr

The facts

Revealed on February 25, 2026, this violation concerns beneficiaries of Active Solidarity Income (RSA). The intrusion did not occur in the systems of the CNAF itself, but in those of the DINUM – ​​the Interministerial Digital Directorate – which constitutes the data transmission channel between the CAF and the departmental councils as part of the RSA instruction.

The compromised data is particularly sensitive: beneficiary number, social security number (NIR), first and last names, contact details, dates linked to rights and duties. No banking data or password was compromised, but the combination of identity + NIR + contact details constitutes a sufficient basis for ultra-targeted phishing campaigns and identity theft attempts.

Points of vigilance and recommendations

A preliminary observation: the receiving communities have no choice

It must be said clearly: a departmental council which receives RSA data via DINUM has no alternative. DINUM is state-mandated infrastructure — no one chooses to use it, we connect to it because that’s how the system is designed. Recommending a community to ‘prefer a more secure platform’ would be as unrealistic as advising it to choose another state.

The real problem revealed by this incident is that the interministerial chain itself was not sufficiently secure. This is a responsibility that falls to the State – to DINUM and the ministries concerned – and not to the organizations receiving the data. That said, certain obligations are imposed on all actors in the chain, whatever their position.

What is the responsibility of DINUM and the State — technical measures

  • End-to-end encryption of inter-administration flows: data in transit between the DINUM and the departmental councils should have been systematically encrypted — this is a security obligation incumbent on the chain operator
  • Partitioning of transmission environments: compromised access to a transit node should not allow the extraction of clear data
  • Strong authentication (MFA) mandatory on all access to interministerial channels — measure falling under DINUM governance
  • Monitoring of abnormal flows in real time: an unusually high volume of requests or exports should trigger an automatic alert

What each link in the chain can still control

  • Precisely map the flows received and transmitted: even without controlling the platform, each organization must know what data it receives, from whom, and what it does with it — this is an obligation of the processing register
  • Never retransmit data from the DINUM chain by standard electronic messaging: an email is an insecure channel — even internally, even within the administration
  • Formally question the State on the security guarantees of the chain: a receiving community can and must request, within the framework of the agreement which binds it to the CAF or the DINUM, documentation on the security measures applied

What ANSSI imposes — for the record

For organizations that have control over the choice of their exchange platform — outside the imposed interministerial chain — the minimum security requirements to check are as follows:

  • End-to-end encryption of data in transit and at rest
  • Two-factor authentication for all users
  • Complete traceability of access: who, what, when, from where
  • Isolating environments by data sensitivity level
  • For particularly sensitive data: hosting on qualified SecNumCloud infrastructure (ANSSI)
  • Subcontracting contract compliant with article 28 GDPR with the platform operator
  • Annual penetration tests carried out by a qualified service provider

These criteria apply to private platforms as well as to state digital tools. Public qualification of an infrastructure does not constitute a guarantee of conformity – this incident demonstrates it.

 

💡 Advice from your CNIL-AFNOR certified DPO

→ Never retransmit data from inter-administration flows internally by standard electronic messaging. Even received from a state body, this data remains sensitive personal data subject to all your GDPR obligations.

→ Map the data you receive via the DINUM/CAF chain in your processing register: you are responsible for processing as soon as you use this data — including if you have not chosen the platform that sends it to you.

FICOBA / DGFiP — The compromised national banking file

🔗 Source: IT Social — DGFiP confirms FICOBA exfiltration

The facts

On February 18, 2026, the Directorate General of Public Finances (DGFiP) revealed that a malicious actor had illegitimately accessed FICOBA — the National Bank Account File — by usurping the identifiers of an official with inter-ministerial access. The intrusion, active since the end of January 2026, allowed the consultation and extraction of data relating to 1.2 million bank accounts, including full bank details (RIB and IBAN), identity of the holder, postal address and, in certain cases, tax identifier.

FICOBA is one of the most sensitive administrative files of the State: it lists all accounts opened in France. An IBAN alone does not allow direct debit, but combined with complete identity data, it constitutes a formidable basis for transfer fraud, personalized bank phishing or documentary identity theft.

The CNIL was notified, a complaint was filed and the ANSSI was mobilized.

Point of vigilance and recommendations

Technical measures

  • Mandatory multi-factor authentication (MFA): any access to a file of such sensitivity must be protected by a second authentication factor — a password alone is not enough
  • Real-time behavioral monitoring: anomaly detection tools (unusual access volumes, atypical time slots, massive data export) should have triggered an alert well before the intrusion reached 1.2 million accounts
  • Encryption of extracted data: even in the event of illegitimate access, data encrypted at the source is unusable without the key

Organizational measures

  • Principle of least privilege: a civil servant should only access data strictly necessary for their missions — broad and permanent access to FICOBA should never be granted without documented operational justification
  • Regular review of access rights: rarely used inter-ministerial accounts are preferred targets; a quarterly review of active authorizations would make it possible to detect and revoke dormant or oversized access
  • Segregation of duties policy: no single agent should have the capacity to massively access and extract data from such a sensitive file
  • Incident response exercises: regularly simulate credential theft scenarios to test detection and team response

💡 Advice from your CNIL-AFNOR certified DPO

→ Check for each processing of financial or banking data that access rights are strictly limited to operational needs — and document this in the processing register.

→ Ensure that your organization has a procedure for immediately revoking access in the event of suspected account compromise.

→ Integrate into employment contracts and IT charters an explicit clause on confidentiality obligations linked to access to sensitive files.

→ For organizations processing sensitive financial data: an annual audit of access rights is not an option — it is a basic security measure within the meaning of Article 32 GDPR.

IDMERIT — The KYC leak which exposes 53 million French people

🔗 Source: Futura Sciences — IDMerit: 53 million French people affected

The facts

Discovered by Cybernews, this global leak is particularly worrying for France. The terabyte database owned by IDMerit, a company specializing in Know Your Customer (KYC) solutions, exposes a billion sensitive records including names, addresses, dates of birth, national identification numbers, telephone numbers and email addresses.

France is among the most affected countries with 53 million registrations. This data is used by companies to verify the identity of their customers in the banking, fintech, insurance, healthcare and customs sectors. The irony is cruel: a platform designed to prevent fraud itself becomes the vector of potential fraud on a large scale.

Points of vigilance and recommendations

What this incident reveals above all: a systemic risk

Before making recommendations, we must ask a question that many people avoid: do we really have a choice of our KYC provider?

The honest answer is: often no. The identity verification market is dominated by a handful of global players and a few others. In many cases, the service provider is not freely chosen by the company: it is imposed by the partner bank, integrated into a payment processor (Stripe, Adyen, etc.) or embedded in a business SaaS. The client organization may not even know that IDMerit is somewhere in their processing chain.

This market concentration creates massive dependence on players whose security no one – neither direct customers nor national regulators – really controls. It is therefore not so much a problem of individual data controllers as a problem of sectoral structure. The IDMerit leak is revealing: when a single actor aggregates the identities of 53 million French people, a single breach is enough to potentially expose all adults in a country.

What is the responsibility of the regulator and the legislator

  • Strengthen security obligations imposed on KYC providers in regulated sectors (banking, insurance, health) via sectoral authorities — ACPR, AMF — in addition to the GDPR
  • Require regular independent security audits on KYC platforms operating on the European market, the results of which would be communicated to the supervisory authorities

What the KYC provider must guarantee — technical measures

  • Strict control of access to the database: a database aggregating the national identities of billions of people must never be accessible without robust network segmentation, whitelisting of authorized IP addresses and strong authentication
  • Differentiated encryption by data category: national identification numbers and passport data deserve a higher level of protection than contact details
  • Automatic detection and shutdown in case of mass access or extraction: abnormal behavior on a database of this size should trigger an immediate alert and interruption
  • Regular and rigorous penetration tests, carried out by qualified independent service providers

What data controllers can still control

  • Precisely map the data transmitted in each KYC chain: even without controlling the service provider, we control what we send to them — only transmit the data strictly necessary for verification
  • Identify if an actor like IDMerit appears as a second-tier subcontractor to its main service provider and include it in the register of processing activities — this is a GDPR obligation, not an option
  • Ensure at a minimum that the contract with the direct KYC provider contains an obligation to notify in the event of a violation, even if the right to audit remains theoretical in the face of major players
  • Prepare a crisis management plan anticipating a breach with a third-party service provider: when you do not have a choice of service provider, you can at least have a choice of response

💡 Advice from your CNIL-AFNOR certified DPO

→ For companies in the financial sectors: check if your business tool includes a KYC service provider and which one — this information must appear in your processing register and in your information notices to the people concerned.

 

CNRS — Data from former agents in the wild

🔗 Source: Official press release from the CNRS — cnrs.fr

🔗 Source: KultureGeek — Detailed breach analysis

The facts

On February 16, 2026, the CNRS announced that it had identified unauthorized downloads of files containing personal and professional data of people paid by the organization before January 1, 2007. The data exposed is particularly sensitive: names, first names, dates of birth, postal addresses, social security numbers and bank identity statements (RIB).

The compromised server was immediately isolated and shut down. The CNIL and ANSSI were notified, and a complaint was filed with the Paris public prosecutor’s office. The incident did not spread to the rest of the infrastructure. What raises the question above all: why was data sometimes almost twenty years old still accessible on a connected server?

Point of vigilance and recommendations

Technical measures

  • Strict separation of active and archive environments: former staff data has no reason to reside in the same connected systems as current staff data — it must be stored in offline or strictly segregated environments
  • Encryption of HR archives at rest: files kept for legal purposes must be encrypted, making their exfiltration unusable without the decryption key
  • Control and traceability of access to historical data: all access to archives must be nominative, justified and logged, with automatic alert in the event of abnormal behavior

Organizational measures

  • Documented and effectively applied retention and purge policy: each category of HR data must have a defined retention period, known to the teams, and implemented — data from former agents cannot be kept indefinitely
  • Register of up-to-date processing activities: the mapping of historical HR data must appear there with the associated retention periods and be subject to an annual review
  • Periodic review of servers and databases: regularly identify residual, forgotten or orphan data that continues to exist without operational or legal justification
  • Raising awareness among HR and IT teams: an archive is no less exposed than an active database — its protection deserves the same level of requirement

💡 Advice from your CNIL-AFNOR certified DPO

→ Audit your HR databases now: do you know precisely which data from which former agents is still stored, where, and for how long?

→ Data of former personnel retained without a defined retention period constitutes a double violation: the principle of limitation of retention (art. 5 GDPR) is ignored, and an unnecessary attack surface is kept open.

 

CONCLUSION — GDPR compliance is not an option

The violations analyzed in this article are not inevitable. They are, for the vast majority, the consequence of predictable, documented and avoidable breaches. Insufficient authentication, free fields used to enter sensitive information, unsecured inter-administration flows, data archiving without a limited duration, insufficiently verified subcontractors: these flaws come back like a leitmotif.

The GDPR does not require perfection. It imposes proportionality: measures adapted to the level of risk. For organizations that process health, financial or vulnerable population data – such as RSA beneficiaries – this level of risk is high, and measures must be taken accordingly.

France is now paying the price for years of insufficient investment in cybersecurity and compliance. The CNIL is intensifying its controls and sanctions. Victims are beginning to exercise their rights in court. Organizations that fail to act in time are exposed to a triple risk: financial, reputational and criminal.

There is still time to act…

 

Article published on February 28, 2026. Its content reflects the context of its publication.

A question about your situation? Contact the firm ↗