In short: Good crisis communication after a cyberattack is fast, honest and consistent. Inform internally first, then those affected and partners, and say only what is established, clearly separated from what is still being investigated. Obligations to notify, for example under Art. 34 GDPR, must be coordinated with the data protection officer and legal advice; this page is not legal advice.
Why communication is part of incident handling
An attack on a web server is at first a technical problem. Very quickly, though, it also becomes a question of trust: customers notice a website that cannot be reached, partners receive suspicious emails, employees ask questions. If you then stay silent or answer inconsistently, you lose more trust than through the incident itself.
The current PHP2Shell situation makes this tangible. Many companies took their websites offline as a precaution or carried out maintenance at short notice. That does not automatically mean they were hacked. This is exactly the distinction you should be able to explain clearly and calmly to the outside world.
Crisis communication after a cyberattack: the right order
A proven order prevents important groups from learning about it from the press or from third parties:
- Internal crisis team: senior management, technical staff, data protection, where applicable legal advisers and the insurer. This is where it is decided what is said.
- Employees: a short internal notice with the request to forward inquiries to the named contact, and advice to be careful with suspicious emails.
- Authorities, where necessary: for example the data protection supervisory authority under Art. 33 GDPR, the BSI if NIS2 applies, the police if you file a report. You coordinate the order with your legal advisers.
- Affected customers and partners: directly and before a public statement, if possible.
- The public: a notice on the website, possibly a press statement.
Under Art. 34 GDPR, data subjects must be notified without undue delay if a personal data breach is likely to result in a high risk to them. The basics are explained in GDPR reporting obligation: 72 hours.
What belongs in a notice
A good notice is short and answers the questions that those affected ask themselves. This structure has proven its worth:
| Section | Content |
|---|---|
| What happened? | Factual description in simple words, with the time period |
| What do we know, what not? | Established facts separated from the ongoing investigation |
| Who is affected? | Groups of people or data, as far as known |
| What have we done? | Immediate measures, involvement of experts and authorities |
| What should you do? | Concrete recommendations, such as changing your password, watching for phishing |
| How can you reach us? | A fixed contact point for queries |
Announce when you will inform again, and keep that commitment. Even a "no new findings yet" at the announced time builds trust.
Prepare templates for internal information, customer notice and website notice before anything happens. In an emergency, only the facts then have to be filled in.
What you had better avoid
Certain wording and behavior regularly does harm:
- Premature all-clear: "No data was taken" is only permissible if it is proven. An applied patch does not prove that nothing happened beforehand.
- Playing it down: terms such as "minor technical incident" appear dishonest if more becomes known later.
- Blame: pointing at the host, service provider or manufacturer does not help those affected and can have legal consequences.
- Technical details useful to attackers: concrete vulnerabilities of your systems do not belong in public notices.
- Guarantees: statements such as "completely secure" or "unhackable" cannot be upheld.
Website, search engines and phishing wave
After an attack on a website, two side effects often follow. First, Google may display a warning if malicious code was found; how to have it removed after cleanup is under Removing the Google warning. Second, fraudsters use known incidents for fake emails in the name of the affected company. Warn your customers about this actively and state through which channels you actually communicate.
If you take the website offline as a precaution, a plain static page with a short notice and a contact route that does not depend on the affected server is enough.
Once the incident is closed, a final notice to everyone you informed beforehand is worthwhile: what the investigation found, which measures were implemented permanently and whom people can continue to contact. Many companies skip this step because the pressure eases. Yet it is precisely this step that shows you took the incident seriously. Also evaluate internally what went well in the communication and what did not, and adjust templates and responsibilities in your emergency plan accordingly.
How does PHP SOS help?
- We deliver the technical facts in an understandable form and clearly separate what is proven, what is likely and what is unknown.
- We check drafts of your notices for technical accuracy and for details that could help attackers.
- We provide a static maintenance page at short notice that runs independently of the affected system.
- Through incident response, we keep the technology in step with your communication so that commitments on the state of information can be met.
Frequently asked questions
Should we make an attack public while not everything is clear yet?
That depends on the situation, obligations and those affected. Often a short, factual notice with the known state is better than silence, because customers and partners otherwise learn of it from other sources. Coordinate the timing with legal advisers and the insurer.
What should never be in a customer notice?
Assumptions that appear as facts, blaming third parties, technical details that help attackers, and promises you cannot keep with certainty. Wording such as completely ruled out should only be used if it is proven.
Who should speak externally?
A named person, usually from senior management or corporate communications, supported by technical staff and legal advice. Everyone else refers to this contact. That keeps statements consistent.
Do we have to take our website offline and explain that?
If you take the website offline as a precaution, a short notice helps, for example on a static maintenance page. It does not have to be technical. Taking it offline as a precaution does not automatically mean that an attack succeeded.