The Challenge of Early Notification
When France's tax authority (DGFiP) discovered a breach in its Vacant Successions Portal, it faced a tough decision: suspend the system immediately or wait until the full scope of the breach was understood. DGFiP chose to act quickly, suspending the service and notifying affected parties, even as the scope of the breach evolved. Initial reports suggested 678,000 affected parties, later revised to 600,000. Notifications included warnings about phishing and impersonation risks, despite incomplete information about the breach.
This situation highlights a key tension in incident response: should you communicate early with incomplete information, or wait for a complete picture? For compliance teams working under ISO/IEC 27001 Clause 5.2.2 (internal communication) and SOC 2's CC9.1 (incident response communication), this isn't just a PR issue. It's a control design decision affecting obligations under both frameworks.
Why Notify Early?
There are three main reasons to notify early: regulatory timelines, preventing secondary harm, and maintaining stakeholder trust.
Under GDPR Article 34, if a breach poses a high risk to individuals, you must notify them "without undue delay." ISO/IEC 27001:2022 Annex A.5.24 requires response procedures that minimize harm. Delaying communication can lead to violations of these standards.
Practically, early notification allows affected parties to protect themselves. DGFiP's warnings about phishing and CEO fraud enabled recipients to scrutinize messages before attackers could exploit the situation. For the 350,000 individuals whose tax details were exposed, early warnings were crucial. The 250 people whose message contents were compromised needed immediate information on potential risks.
From a controls perspective, your Incident Response Plan should treat notification as a preventive control. If your communication procedures align with ISO/IEC 27035, you're already documenting known and unknown details and your investigative actions. Sharing this framework with affected parties shows you're taking the incident seriously.
Trust is also a significant factor. If stakeholders hear about a breach from attackers rather than from you, the damage increases. In this case, the alleged cybercriminal "ZeroBytes" claimed to have stolen data from over 2 million people. DGFiP's notification, estimating 600,000, provided a more accurate picture, countering inflated claims.
The Argument for Waiting
On the other hand, premature notification can cause confusion, erode credibility, and trigger unnecessary panic.
DGFiP's initial report of 678,000 affected parties, later revised to 600,000, raised questions about the investigation's quality. If you can't accurately count affected parties, how confident are you about the breach's details? For 250,000 businesses whose exposure was limited to public information, early notification might have implied a more severe breach.
ISO/IEC 27001 Clause 10.1 requires evaluating incidents to determine appropriate responses, which takes time. Notifying before understanding the attack vector means you can't provide meaningful guidance. Generic phishing warnings are less useful than specific advice based on actual data exposure.
There's also a legal risk. Inaccurate notifications can be used against you in regulatory or legal proceedings. If you incorrectly state that someone's Social Security number was exposed, it undermines your credibility. It's better to wait for forensic confirmation.
Premature notification can also overwhelm your response capacity. Notifying 600,000 people without proper support channels can lead to an unmanageable influx of inquiries, compounding reputational damage and diverting resources from the investigation.
A Balanced Approach
Most incident response teams adopt a balanced approach with tiered notification protocols that prioritize both speed and accuracy.
The first notification acknowledges the incident, shares known details, and offers immediate protective guidance. This meets regulatory timelines and provides actionable steps (change passwords, monitor accounts, scrutinize messages). It also clarifies what's still under investigation.
Follow-up communications offer more details as the investigation progresses. If the scope changes, explain why. If new risks emerge, update your guidance. This approach treats notification as an ongoing process, not a one-time event.
Your controls documentation should reflect this. If mapping to SOC 2 CC9.1, document your notification triggers: What level of confirmed exposure requires immediate communication? What details must be verified before inclusion in a notification? Who approves the message? For ISO/IEC 27001 Annex A.5.26, specify communication timelines tied to incident severity, not perfect knowledge.
Setting stakeholder expectations correctly is key. DGFiP's notifications warned about specific attack types and clarified that sensitive information requests would never occur outside its secure portal. This is actionable guidance that doesn't depend on knowing every detail.
Our Recommendation
Notify early, but be honest about uncertainties.
The regulatory environment and nature of modern attacks favor speed over completeness. Waiting for perfect information means waiting too long. However, your notification must acknowledge uncertainty and outline a framework for updates.
Design your incident response procedures around progressive disclosure. Your first communication confirms the incident, describes immediate risks, and advises affected parties on immediate actions. Subsequent updates provide more details as your investigation continues. If the scope changes, explain why your initial estimate was off.
This approach satisfies both ISO/IEC 27001's requirement for timely incident response and SOC 2's emphasis on communication effectiveness. More importantly, it treats affected parties as partners in limiting harm, not as audiences to be managed.
The tradeoff is accepting some initial uncertainty in your public statements. That's uncomfortable, but it's better than staying silent while attackers exploit a window you could have closed.
