The website is unresponsive, orders are stalled, and a screenshot is circulating on social media. In the customer service inbox, one question keeps coming up: “Has my data been stolen?” The company does not yet know. This is precisely where its communication work begins. Informing customers without compromising the investigation means neither revealing everything nor waiting until everything is known. The company must publish information that helps customers understand the situation and protect themselves, without exposing technical operations. Looking ahead to September 2026, this balance is likely to remain a key measure of trust.
The first message does not have to resolve the entire incident
A cyberattack creates two simultaneous crises: one affecting IT systems and another affecting information. Technical teams work with incomplete logs, isolated machines, and competing hypotheses. Customers want to know whether they can make payments, log in, or continue operating. Forcing them to wait for technical analysis to run its course means letting others tell the story of the incident in the company’s place.
The initial statement can therefore be brief. It should specify the problem observed, the services affected, the protective measures already taken, and when the next update will be provided. If malicious activity has not been confirmed, describe it as an IT incident, without presenting that provisional classification as a reassuring certainty. If an intrusion has been established, it is better to name it than to hide behind “technical difficulties.”
An illustrative statement might read: “We have detected unauthorized access to an IT environment. Some services have been suspended as a precaution. We are currently checking whether customer data has been accessed or copied. We will publish a further update tomorrow at noon.” This wording promises neither immediate restoration nor the absence of a leak. It provides verifiable reference points.
Three categories to prevent contradictions
Before each publication, the crisis management team should classify information into three categories: confirmed facts, matters still unknown, and information that cannot be disclosed at this stage. This simple framework prevents a technical hypothesis from becoming a claim made by the sales team after a few forwarded emails.
- Confirmed: an outage, established unauthorized access, a category of data known to have been compromised.
- Unknown: the full scope, exactly how long the attacker was present, or whether a copy of the data exists.
- Withheld: accounts being monitored, traces being analyzed, or details of a vulnerability that could still be exploited.
Sometimes, the crucial distinction comes down to a few words. “We have found no evidence of exfiltration” describes the state of the investigation; “no data has been stolen” asserts an outcome. The first statement itself warrants clarification about the scope examined. An absence of traces is not proof of absence, particularly when logs are incomplete.
Protect the investigation, not the company’s short-term reputation
There are good reasons to withhold certain details. Publishing a technical address under surveillance could alert the intruder. Describing an unpatched vulnerability could encourage further attacks. Exposing investigative methods could compromise evidence collection. Public information should therefore be reviewed by incident response teams and, where necessary, coordinated with investigators.
But “the investigation is ongoing” is not a blanket exemption from providing explanations. A company can describe the consequences for its customers without revealing its architecture. It can announce that an access route has been blocked without detailing how. It can explain that a particular point remains confidential to protect the investigation, while stating what it already knows.
The attack on the British Library in 2023 offers a useful lesson. Its review, published in 2024, demonstrated the value of extensive transparency once the right conditions were in place. That level of detail does not necessarily belong in a day-one statement: transparency is built over time, from operational updates to a documented review.
Legal deadlines do not wait for the final report
In France and the European Union, the GDPR requires organizations to notify the supervisory authority of a personal data breach likely to pose a risk to people’s rights and freedoms. Where possible, notification must be made within 72 hours of becoming aware of the breach. The clock therefore does not automatically start with the first observed malfunction. A notification can be supplemented in stages when not all information is yet available.
When a breach is likely to pose a high risk, the people concerned must also be informed without undue delay, subject to the exceptions provided for in the regulation. The communication to them must, in particular, clearly set out the nature of the breach, its likely consequences, the measures taken, and a point of contact. Notifying the CNIL and informing customers are two separate processes. A general announcement does not automatically replace individual notification.
Other requirements may arise from the sector, contracts, or the organization’s status. In particular, the NIS2 framework provides for an early warning followed by a notification within specific deadlines for covered entities and significant incidents. For an incident in September 2026, the national and sector-specific rules actually in force will need to be checked. The best approach remains to prepare a matrix of obligations before a crisis, working with the legal team and the data protection officer.
Provide useful actions, not an anxiety-inducing checklist
Advice should match the data and access credentials actually exposed. If credentials have been compromised, specify which passwords to change and highlight the risk of reusing them elsewhere. If contact details have leaked, focus warnings on personalized fraudulent messages. If financial information is involved, explain the relevant steps to take with the bank, without suggesting that everyone faces the same risk.
The channel matters as much as the content. A status page independent of the affected system and accessible without logging in reduces reliance on unavailable infrastructure. Individual messages should avoid attachments and allow recipients to find the same instructions on the official website. Crisis communication should not train customers to click hastily on a link received by email.
One version of the facts, several points of contact
Customer service staff, sales teams, and account managers should have a timestamped briefing sheet: verified facts, approved responses, and questions to escalate. Without this shared foundation, one adviser may promise that no data has leaked while another recommends changing every password. Any public correction should be visible and explained, rather than quietly deleted.
What now? Looking ahead to September 2026, generative tools could amplify fake support messages and imitation company statements. Businesses would therefore benefit from establishing their official communication channels now, testing their notifications, and running a crisis simulation with their customer service teams. Trust will depend not on perfectly reassuring language, but on timestamped, consistent communication that is concrete enough to help everyone take action.