On 12 August 2026, an actor using the name ZeroBytes posted a claim on a criminal forum: unauthorised access to systems of the Direction Générale des Finances Publiques (DGFiP), France’s tax authority, obtained in late June 2026 following an identity theft.
Over the following days the French Finance Ministry confirmed the incident. By 17 August the figure had settled at 678,000 individuals and businesses affected. The data taken included, for individuals, reference tax income (revenu fiscal de référence), family quotient (quotient familial), and withholding tax rate (taux de prélèvement à la source); for businesses, company name and SIREN number.
The detail that should hold a compliance team’s attention is not the record count. It is the timeline. The unauthorised access was detected and cut off in late June during routine security checks. DGFiP notified CNIL at that point, as Article 33 requires. And then it said nothing publicly for approximately six weeks, until a criminal forum post made silence untenable.
That gap — between notifying the supervisory authority and communicating to data subjects — is the whole of this case.
Article 33 and Article 34 are different obligations with different triggers
This distinction is routinely collapsed in practice, and the DGFiP incident is a clean illustration of why it should not be.
Article 33 requires the controller to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The threshold is risk.
Article 34 requires the controller to communicate the breach to the data subject without undue delay when the breach is likely to result in a high risk to the rights and freedoms of natural persons. The threshold is high risk.
Article 34(3) then provides three exemptions from the communication duty:
- the controller had applied appropriate technical and organisational protection measures — in particular encryption — rendering the data unintelligible;
- the controller has taken subsequent measures ensuring the high risk is no longer likely to materialise; or
- communication would involve disproportionate effort, in which case a public communication or similar measure is required instead.
DGFiP appears to have satisfied Article 33. The question is what happened to Article 34 between late June and mid-August.
The three defensible readings, and their problems
There are only a few positions a controller in DGFiP’s situation could take, and each has a difficulty.
“There was no high risk.” The data comprised tax reference income, family quotient, withholding rate, company name and SIREN. No passwords, no bank details, no national identity numbers reported. A controller could argue this does not clear the “high risk” bar.
The problem is that this argument understates the data. Reference tax income and family quotient together are a precise financial and household composition profile. Withholding tax rate is a direct income signal. In combination these are close to ideal inputs for targeted fraud: an attacker can construct a convincing tax-authority impersonation that quotes the victim’s actual income figures. Tax-themed phishing against French taxpayers is a well-established, high-volume criminal activity, and this dataset makes it substantially more effective. CNIL has previously treated financial profiling data as high-risk in less compelling circumstances.
“Risk was no longer likely to materialise.” Access was cut off in late June. If the controller concluded the threat was contained, Article 34(3)(b) is available.
The problem is that Article 34(3)(b) concerns the risk to data subjects, not the risk of continued intrusion. Closing the door does not retrieve what has already left. Data exfiltrated in June remained exfiltrated in July, and the eventual criminal forum posting demonstrated exactly the materialisation the exemption requires to be no longer likely.
“Communication would involve disproportionate effort.” With 678,000 affected parties, this is arguable — and it is the exemption most likely to be relied upon.
The problem is that Article 34(3)(c) does not permit silence. It permits substitution: a public communication or similar measure by which data subjects are informed in an equally effective manner. A tax authority with an established online portal used by essentially every affected person, a press office, and national media reach cannot easily claim it lacked an effective public communication channel. It had one. It used it in August, not in June.
A fourth explanation, unavailable as a legal defence: operational and reputational judgement — a decision to withhold while investigation and remediation proceeded. This is understandable and it is common. It is also not a ground in Article 34, and CNIL has been consistent that ongoing investigation does not suspend the communication duty. The GDPR contemplates communicating with incomplete information and updating, not waiting for certainty.
Why “we notified the regulator” is not a defence
The most common structural error in breach response is treating supervisory authority notification as the compliance event and data subject communication as a downstream communications decision, owned by public affairs, subject to reputational weighing.
They are separate legal obligations with separate triggers, separate clocks, and separate liabilities. Notifying CNIL within 72 hours discharges Article 33. It does nothing whatsoever for Article 34.
Worse, the notification you file under Article 33 becomes evidence. Article 33(3) requires the notification to describe the likely consequences of the breach and the nature of the data. A controller who tells CNIL in June that the breach involves tax income data for hundreds of thousands of taxpayers has created a contemporaneous record establishing exactly the risk profile that would trigger Article 34. Whatever internal reasoning supported delay must then withstand comparison against the controller’s own filing.
The public sector question
CNIL’s approach to public bodies is a live issue in this case.
Article 83(7) GDPR permits Member States to determine whether and to what extent administrative fines may be imposed on public authorities. France exercised that option: under the Loi Informatique et Libertés, CNIL may impose sanctions on public bodies but administrative fines against the State and public authorities are capped, and CNIL has historically preferred injunctions, formal notices (mises en demeure) and public reprimands over financial penalties for state actors.
This creates an accountability asymmetry that has drawn increasing criticism. A private processor that held tax data for 678,000 people, detected an intrusion in June, and disclosed in August after a criminal forum post would face a substantial Article 83 exposure. A state directorate faces a considerably lighter instrument set.
CNIL has, however, been moving. The Commission has become notably more willing to publicly sanction state bodies, and the political salience of a tax authority breach — where the data subjects are, by definition, every taxpayer, and where the controller is the body that demands their data by law — makes a visible response likely. The realistic outcomes are a public mise en demeure on notification practice, a formal reprimand, and possibly binding remediation requirements on DGFiP’s detection and disclosure processes.
For compliance teams outside government, the more useful observation is this: the precedent CNIL sets on the Article 33/34 gap here will be cited against private controllers. Regulators do not maintain separate bodies of interpretive doctrine for public and private sector controllers. Whatever CNIL says about how long a controller may sit between regulator notification and data subject communication becomes the standard.
Detection worked; disclosure did not
There is a genuinely positive fact in this incident that deserves acknowledgement. The unauthorised access was detected and cut off during routine security checks. Not by a ransom note. Not by a customer complaint. Not, initially, by a dark web listing. By the controller’s own monitoring, in the course of ordinary work.
That is better than the majority of the incidents we cover. The industry median time to detect an intrusion is measured in months; the Ceva Logistics processor incident and the CareCloud notification gap we examined earlier this month both involved detection failures of a kind DGFiP avoided.
Which sharpens the lesson rather than softening it. DGFiP’s security function performed. Its disclosure governance did not. The organisation invested successfully in detection and containment and then failed at the comparatively trivial task of telling affected people. The eventual disclosure was not a decision; it was a reaction to a criminal forum post. That is the opposite of controlled communication, and it converted a defensible security story into an accountability story.
Organisations reviewing their own posture should note that these are separately funded, separately owned, separately tested capabilities — and that the second one is almost never exercised.
What to fix
Separate the two clocks, formally
- Your incident response plan must contain two distinct decision points: the Article 33 supervisory authority notification, and the Article 34 data subject communication.
- Each needs its own named decision-maker, its own documented risk assessment, and its own clock.
- The Article 34 assessment must be re-run as facts develop. A “no high risk” conclusion reached on day two, when exfiltration was unconfirmed, is not valid on day thirty once exfiltration is established.
Document the Article 34 reasoning contemporaneously
- If you conclude no communication is required, record which exemption you are relying on and the evidence supporting it. “We are still investigating” is not an exemption.
- If you rely on 34(3)(c) disproportionate effort, execute the substitute public communication. The exemption converts individual notice into public notice; it does not remove notice.
- Diary a review date. An exemption relied upon in week one must be revisited in week four.
Pre-build the communication capability
- Draft holding notices, portal banners, and press statements in advance for your top breach scenarios.
- Establish who can authorise publication, and ensure that authority does not require a full executive quorum.
- Test it. Run a tabletop exercise that ends not at containment but at publication.
Assume the data will surface
- Build your disclosure decision on the assumption that exfiltrated data will eventually appear on a criminal forum, a leak site, or a journalist’s desk.
- The controlled disclosure you make on your own timeline is always better than the reactive one you make after someone else’s post. DGFiP had six weeks of the former available and took none of it.
Watch the combination risk in your own data
- DGFiP’s dataset contained no passwords and no bank details, and it is still a serious exposure because of what the fields mean together.
- Run your breach risk assessments on combinations, not on field-by-field sensitivity classifications. Income plus household composition plus a government relationship is a fraud kit regardless of whether any individual field is flagged sensitive.
Closing
The DGFiP breach will be remembered for the 678,000 figure. The part worth carrying into your own programme is the six-week silence and what produced it.
There is no evidence of bad faith here. There is every sign of an organisation that detected an intrusion, contained it competently, notified its regulator correctly, and then let the question of telling the public drift — because no one owned it, no clock was running on it, and every week that passed made the disclosure harder rather than easier.
That failure mode is not French, and it is not public sector. It is the default outcome anywhere the Article 34 decision has not been given an owner, a deadline, and a pre-drafted communication. Six weeks is not a long time inside an incident. It is a very long time in front of a supervisory authority explaining why the affected people learned it from a criminal forum.
This article is provided for informational purposes only and does not constitute legal advice. Organisations should consult qualified counsel regarding their specific obligations under the GDPR, the Loi Informatique et Libertés, and applicable national law.



