France’s tax authority spotted an intruder inside its systems the same day it happened, in late June. The public did not find out until mid-August, six weeks later, and only after the attacker went public first. That gap, not the intrusion itself, is the part every security leader running a large public-facing system should study.
What happened at the DGFiP
France’s Directorate General of Public Finances (DGFiP), the agency that administers the country’s tax system, confirmed on August 13 that an intruder had gained illegitimate access to its information system using a stolen identity. According to the Ministry of Economy and Public Accounts, the access occurred in June and July 2026 and was detected and cut off quickly once staff noticed it.
The statement did not stay ahead of events for long. On August 12, a person using the alias ZeroBytes claimed on a criminal forum to have pulled 678,438 rows of data out of DGFiP systems. The Ministry’s confirmation followed the next day, and it did not dispute the scale: investigations since established that the access had been used to view and extract data on roughly 678,000 individuals and businesses, including reference taxable income, family quotient, and withholding tax rates, plus company names and SIREN registration numbers for businesses. Cadastral data covering property addresses and surface areas was also consulted.
Media Partner
The Ministry said in its release that “un acteur malveillant a revendiqué des accès illégitimes au système d’information de la Direction générale des Finances publiques” (“a malicious actor claimed illegitimate access to the information system of the Directorate General of Public Finances”), and confirmed it had notified France’s data protection authority, the CNIL, as soon as the extraction was identified. The agency said it would file a criminal complaint and begin direct notifications to affected taxpayers the week of August 18, roughly seven weeks after the intrusion window closed. The Paris prosecutor’s office opened its own investigation on August 15, the same week Washington moved in the opposite direction on government cyber posture, authorizing private firms to take part in offensive cyber operations rather than focusing federal resources on shoring up the kind of defensive and disclosure gaps DGFiP just exposed.
Detection speed and disclosure speed are not the same metric
DGFiP’s own account is that its staff caught the unauthorized access quickly and shut it down. That is the outcome every incident response program is built to produce, and on its own terms it worked. What took far longer was determining the scope of what had actually been taken, notifying the regulator, and telling the public. Six weeks separated containment from disclosure, and the disclosure itself was forced by the attacker’s own forum post rather than the agency’s own timeline.
That sequence is not unique to Paris this month. CyberTech reported on August 15 that Scotland’s Crown Office and Procurator Fiscal Service disclosed a breach of staff data that reached it through a third-party supplier, another case where a government body’s own defenses were not the point of failure and the delay sat in scoping and notifying rather than in stopping the initial access. Two government bodies, two different entry vectors, one shared symptom: the interval between “we found it and stopped it” and “here is what was actually taken, and who needs to know” is where these incidents are actually being lost.
Why identity-based access is hard to scope quickly
DGFiP’s intrusion started with a stolen identity rather than a software exploit, which is precisely why it took weeks to size. A vulnerability has a patch date and a blast radius that maps to a CVE and an affected version list. A credential or identity compromise maps to whatever that identity was authorized to touch, and proving the negative, that nothing beyond the logged access occurred, requires reconstructing a user’s full activity across the access window rather than checking a single exploited endpoint. That reconstruction work is what consumed DGFiP’s six weeks, and it is the same work that consumes the weeks after any identity-based intrusion into a system holding regulated personal data.
What it means for the security leader
The lesson is not that DGFiP responded badly. Cutting off illegitimate access within the same access window it started is a genuine result. The lesson is that a fast-containment story and a fast-disclosure story are two separate programs, and an organization that has invested in the first has not automatically built the second. For a CISO or a data protection officer, that means:
- Treat scoping and notification as their own workstream with their own service-level target, distinct from the detection and containment SLA. A breach response plan that ends at “access revoked” has not actually ended.
- For identity-based intrusions specifically, pre-build the query paths that let the team reconstruct what a compromised identity touched, rather than designing that process for the first time under pressure during an active incident.
- Assume the attacker may disclose before you do. DGFiP’s timeline was set by ZeroBytes’ forum post, not by DGFiP’s own readiness. A communications plan that only activates after legal sign-off on a company-paced timeline will lose that race again.
The regulatory clock is not waiting
France operates under the EU’s GDPR, which sets a 72-hour window for notifying a supervisory authority once an organization is aware a personal data breach has occurred, not once it has fully scoped the breach. DGFiP says it notified the CNIL as soon as the extraction was identified in mid-August, which addresses the regulator-facing clock. The taxpayer-facing clock is separate, and that is the one that ran six to seven weeks past the original intrusion. Any organization handling regulated personal data should be able to answer, before an incident happens, which of those two clocks starts first and what triggers each one, because the answer under GDPR is “awareness,” not “certainty.”
For defenders, the actionable takeaway from DGFiP is not a patch or a configuration change. It is a rehearsal question: if your team detected and shut down unauthorized access today, how many weeks would it take to tell the regulator what was taken, and how many more to tell the people it belongs to. If that answer is measured in weeks rather than days, the gap DGFiP just lived through in public is one your own incident response plan should be tested against now, not during the next identity-based intrusion.
