Communicating Security Incidents: Internally, Externally, and to the Press

Communication Determines the Damage

A security incident is always a crisis. But the crisis doesn't consist solely of the technical damage an attack causes. It equally consists of the communication that follows. Companies that communicate poorly during a cyberattack regularly suffer greater reputational damage than those that handle the incident transparently and in a structured manner.

This is because customers, partners, and the public accept a security incident to a certain degree as inevitable. Any company can fall victim to an attack — that's common knowledge today. What people don't accept is a lack of transparency, delays, and the feeling that a company is trying to cover something up.

The good news: good crisis communication can be prepared in advance. The bad news: most companies don't do it. They have an incident response plan for the technical side but no communication plan for the human side. And it's precisely this gap that becomes the problem in an emergency.

Internal Communication: Who Learns What and When?

Internal communication is the first and most important step in any security incident. Before anyone outside the company is informed, the following must be clear internally: What happened? How extensive is the damage? Who is doing what?

Defining Escalation Levels

Not every security incident requires the same internal communication. A phishing email that an employee reported with no impact doesn't need to wake the CEO at 3 AM. A ransomware attack that shuts down production does.

Define clear escalation levels based on the severity of the incident:

Level 1: Normal security incident. No or minimal business impact. Examples: single phishing email detected, malware isolated on one client, failed brute-force attack. Communication: internal IT security team, documentation in the ticketing system. No escalation to management or employees needed.

Level 2: Serious incident. Potential or limited business impact. Examples: successful phishing attack with a compromised account, limited data loss, outage of a non-critical system. Communication: IT management, ISO, affected department head. Executive management is informed but not necessarily involved immediately.

Level 3: Critical incident. Significant business impact or a reportable incident. Examples: ransomware encrypting production systems, large-scale data exfiltration, compromise of customer data. Communication: immediate notification of executive management, activation of the crisis team, notification of all employees via predefined channels.

Activating the Crisis Team

For a Level 3 incident, you need a crisis team that can act quickly. Ideally, this team has already been named and documented in a communication plan. Typical members:

• Executive management (decision-making authority)
• ISO or IT management (technical assessment)
• Legal department or external counsel (regulatory obligations, liability questions)
• Communications/PR (external communication, press inquiries)
• HR (employee communication, labor law questions)
• Affected business departments (operational assessment)

The crisis team doesn't need to meet physically. A pre-established channel in a messaging system or a conference call system is sufficient. What matters is that all members know how to reach each other — including outside business hours — and that contact details are up to date.

Employee Communication

If an incident affects employees' work, they must be informed. The principle: fast, clear, and action-oriented. Employees need to know what they should do, not necessarily all the technical details.

A good internal initial notification contains:

• What happened? (One sentence, no technical deep dive)
• What does this mean for my work? (Which systems are affected, what isn't working?)
• What should I do? (Concrete instructions: shut down PC, don't click certain links, etc.)
• Whom do I contact with questions? (A central point of contact, not five different numbers)
• When will the next update come?

Avoid speculation about causes and perpetrators in internal communication. It's better to say "We are investigating the incident" than to provide a premature explanation that later turns out to be wrong.

A practical tip: explicitly instruct employees not to share any information about the incident on social media. What starts as a well-meaning LinkedIn post can quickly be picked up by journalists and trigger a media dynamic the company can no longer control.

External Communication: Customers, Partners, Suppliers

Communication with external stakeholders is the area where most mistakes happen. Too late, too vague, too technical, or simply dishonest — each of these variants causes more damage than the incident itself.

When to Communicate Externally?

The basic rule: as soon as external stakeholders are affected or could be affected, they must be informed. "Affected" in this context means: their data, their systems, or their business processes are impacted by the incident.

Specifically: if customer data may have been exfiltrated, customers must be informed. If a shared system was compromised, partners must be informed. If suppliers had access to their data through your system, suppliers must be informed.

DSGVO (GDPR) provides a clear framework here: if a data breach is likely to result in a high risk to the rights and freedoms of natural persons, the affected individuals must be notified without undue delay (Art. 34 GDPR).

Communication Sequence

The sequence is critical and should be established in advance:

1. Executive management and crisis team (immediately)
2. Affected employees (within a few hours)
3. Directly affected customers and partners (as quickly as possible, ideally within 24 hours)
4. Authorities (BSI: 24 hours, data protection authority: 72 hours)
5. Broader customer base (if relevant)
6. Public/press (only if necessary and after consultation with the legal department)

What External Communication Must Include

A good external notification contains the following elements:

• What happened? (Short and understandable, no technical details)
• Which data or systems are affected?
• What are we doing about it? (Measures already initiated)
• What does this mean for the recipient? (Do they need to take action? Change password? Check bank statements?)
• Where is more information available? (Hotline, FAQ page, email address)
• When will the next update come?

What external communication should not contain: blame, speculation about attackers, technical details about the vulnerability (which only help other attackers), and promises you can't keep ("Your data is safe" — if you don't know that yet, don't say it).

Tone and Attitude

The tone of external communication is at least as important as the content. Three basic principles:

Take responsibility. Even if the attack came from outside, you are responsible for protecting the data. Phrases like "Despite our extensive security measures..." are fine. Phrases like "We fell victim to an attack" sound like playing the victim and avoiding responsibility.

Be transparent. State what you know, and openly state what you don't yet know. "We are currently investigating whether and to what extent customer data is affected" is better than silence or premature reassurance.

Show empathy. For affected customers, the incident is unpleasant, worrying, and frustrating. Show that you understand this, and make it as easy as possible for those affected to get information and protect themselves.

Regulatory Reports: BSI and Data Protection Authority

Beyond communication with customers and partners, there are legal reporting obligations with fixed deadlines, and non-compliance can have significant consequences.

Reporting to BSI (NIS2)

For companies subject to NIS2, the following reporting deadlines apply:

Within 24 hours: Early warning. Initial report to BSI that a significant security incident has occurred. This report doesn't need to contain detailed information yet, but it must communicate the suspicion of a significant incident and indicate whether the incident could be attributable to unlawful or malicious actions.

Within 72 hours: Incident report. Update of the initial report with a first assessment of the incident, including severity and impact, as well as indicators of compromise if applicable.

Within one month: Final report. Detailed report with a comprehensive description of the incident, the nature of the threat, measures taken, and cross-border impacts if applicable.

Reporting to the Data Protection Authority (GDPR)

If personal data is affected, Art. 33 GDPR additionally applies. The report to the competent data protection supervisory authority must be made within 72 hours of becoming aware of the breach.

The report must contain:

• Description of the nature of the breach
• Categories and approximate number of affected individuals
• Categories and approximate number of affected data records
• Name and contact details of the data protection officer
• Description of the likely consequences
• Description of measures taken and proposed

Practical Tips for Regulatory Reports

Prepare the reporting forms in advance as much as possible. The contact details for BSI and the competent data protection authority should be stored in the incident response plan, along with internal responsibilities (who drafts the report, who approves it, who sends it).

Document the time at which the incident became known carefully. Reporting deadlines begin from the time of awareness, not from the time of the actual attack. If an attack occurs on Friday but is only discovered on Monday, the deadlines begin on Monday.

Report early rather than late. An initial report noting "details to follow" is better than a late report with complete information. Authorities know that not everything is clear in the first hours after an incident and accept follow-up reports.

Press Inquiries: Messaging Guidelines and Dos and Don'ts

If a security incident is large enough, press inquiries will come. Sometimes faster than expected, especially if employees post about the incident on social media or if the effects are publicly visible (website unreachable, customers reporting problems).

Preparation

The best preparation for press inquiries consists of three elements:

Messaging guidelines. A pre-coordinated statement covering the key points, used consistently by all authorized spokespersons. The messaging must be kept current as new findings emerge.

Authorized spokesperson. Exactly one person (plus a backup) is authorized to speak with the press. All other employees refer press inquiries to this person. This sounds obvious but only works in practice if it's clearly communicated and practiced beforehand.

Q&A document. A list of the most likely questions with prepared answers. Typical questions: What happened? How long have you known? Is customer data affected? What are you doing to prevent this from happening again? Who is behind it?

Dos

• Respond quickly to press inquiries, even if you can't say much yet. "We have confirmed the incident and are investigating. We will inform you as soon as we have further findings" is an acceptable initial response.
• Stick to the facts. Say what you know, and nothing more.
• Demonstrate capability. "We immediately activated our incident response team and are working with external forensic specialists" signals competence.
• Update messaging regularly and provide proactive updates rather than responding to each inquiry individually.
• Prepare a written press statement that can be published on the company website. This reduces the number of individual inquiries.

Don'ts

• Never say "No comment." This is interpreted as an admission of guilt or concealment.
• Don't speculate about attackers, motives, or scope. "This is the subject of the ongoing investigation" is the right answer to speculative questions.
• Don't make promises you can't keep. "We guarantee that no data was exfiltrated" is a statement that will come back to haunt you if the opposite turns out to be true.
• Don't reveal technical details that could help other attackers.
• Don't blame anyone — neither employees nor alleged attackers — while the investigation is ongoing.

Social Media: Speed and Control

Social media is the channel where crisis communication can spiral out of control the fastest. At the same time, it's often the channel where affected parties first look for information. Ignoring it is therefore not an option.

Initial Response on Social Media

If the incident becomes public, a short statement should appear on the company's relevant social media channels within a maximum of two hours. This statement doesn't need to contain all details — it should signal: we know about it, we're working on it, we'll keep you informed.

An example of a social media initial response: "We have been affected by a security incident and are working intensively on analysis and resolution. We take the protection of your data very seriously and will inform you about results promptly. Current information can be found at [link to status page]."

Monitoring and Handling Comments

Set up social media monitoring to detect and correct misinformation early. Respond to factual questions with prepared answers. Don't delete critical comments unless they contain insults or misinformation that actively causes harm. Deleted comments are almost always noticed and lead to even more negative attention.

Prepared Templates

Templates for crisis communication should be part of your incident response plan. Here are the most important ones:

Template: Internal Initial Notification

Subject: Security Incident — Initial Information

Dear colleagues,

Today we detected a security incident affecting [affected systems/areas]. Our incident response team has been working on analysis and resolution since [time].

What this means for you: [Concrete impacts, e.g., "System X is currently unavailable" or "Please temporarily refrain from using USB drives"]

What you should do: [Concrete instructions]

Important: Please do not share any information about the incident on social media or with external parties. Please direct press inquiries to [name/contact].

We will provide an update by [time].

[Name, function]

Template: External Customer Notification

Subject: Important Security Notice

Dear Sir or Madam,

We would like to inform you that we detected a security incident on [date]. [One sentence about the nature of the incident, e.g., "Unauthorized third parties gained access to one of our systems."]

What we know: [Current findings about nature and scope]

What we are doing: [Measures initiated]

What this means for you: [Recommended protective measures, e.g., change password]

We take this incident very seriously and are working with [external forensic specialists / the relevant authorities] on a full investigation.

For questions, please contact us at [hotline / email]. Current information can be found at [URL].

Sincerely, [Executive management]

Template: Press Statement

[Company name] confirms a security incident that was detected on [date]. We immediately activated our incident response team and are working with external security experts on the analysis and resolution of the incident.

[Optional: One sentence about the scope, if known]

The relevant authorities have been notified. We will keep the public informed about significant developments.

Please direct inquiries to [press office contact details].

Practical Example: Communication During a Ransomware Attack

To put the preceding recommendations into a concrete context, here's a walkthrough scenario:

Day 1, 06:30 AM: Discovery

The first employee notices that multiple files are encrypted. They report it to the IT hotline. By 07:15 AM, IT confirms: ransomware, multiple servers affected, production partially shut down.

07:30 AM: Crisis team is activated. Conference call with executive management, IT management, ISO, legal department, HR, and communications. Initial assessment: 40% of production systems affected, backups being checked, no indication of data exfiltration so far.

08:00 AM: Internal initial notification. Via email and physical notice (because the email system is partially affected): "Security incident detected, IT is working on resolution, please do not turn on any PCs that are still off, do not use USB drives, contact the IT hotline with questions."

09:00 AM: Executive management briefs department heads in a short meeting. Department heads pass information to their teams. Clear message: we have the situation under control, recovery work is underway.

Day 1, Afternoon: Regulatory Reports

02:00 PM: Early warning to BSI via the reporting portal. Content: ransomware incident, scope under investigation, no indications of data exfiltration, systems partially affected.

03:00 PM: Forensics team (externally commissioned) begins analysis. Initial finding: the attack occurred via a compromised VPN connection.

04:00 PM: Internal update to all employees: progress on recovery, estimated time to normalization, which systems will be available when.

Day 2: External Communication

Morning: Forensics results indicate that customer data is not affected. Executive management nevertheless decides to proactively inform the most important customers because the production outage is causing delivery delays.

11:00 AM: Customer notification via email to all active customers. Content: security incident, production temporarily limited, delivery delays possible, customer data not affected based on current knowledge, hotline for questions established.

02:00 PM: First press inquiry from a local newspaper (an employee had written about "the hack" on LinkedIn). Response: prepared press statement is sent. No further details, reference to website for updates.

Day 3: Incident Report to BSI

The 72-hour report to BSI is submitted with an initial assessment: ransomware group identified, attack vector known, no indications of data exfiltration, recovery from backups in progress, approximately 80% of systems expected to be operational again within 5 days.

Week 2 to Month 1: Normalization and Conclusion

Production is running at 95% again. Closing communication to customers: the incident is resolved, measures to prevent future incidents, thanks for their understanding. Final report to BSI. Internal report for executive management with lessons learned and investment recommendations.

Lessons Learned: What Most Companies Get Wrong

Analysis of numerous security incidents reveals recurring communication mistakes:

Communicating too late. The hope that the incident will be quickly resolved and nobody will notice almost always leads to worse consequences. Customers who learn about the incident from the press rather than from the company itself feel betrayed.

Promising too much. "Your data is safe" is a statement that can almost never be made with certainty in the first hours after an incident. It's better to say: "Based on current knowledge, there are no indications of data exfiltration. Should this change, we will inform you immediately."

Inconsistent statements. When the ISO says one thing, the press office says another, and executive management says something else entirely, confusion and mistrust arise. Central messaging is mandatory.

No updates and no closure. Affected parties want to know what happens next. Regular updates are better than radio silence. And many companies forget to officially close the incident: "The incident is resolved, these are the measures we took, this is what we learned." A clean closure restores trust.

Crisis communication during security incidents cannot be improvised. The preparation costs a few hours and pays off a thousandfold in an emergency. Tools like ISMS Lite automatically track reporting deadlines and ensure that no communication step is forgotten.

Further Reading

• Detecting and Reporting Security Incidents
• Creating an Incident Response Plan
• Ransomware Attack: Immediate Measures
• NIS2 Initial Report to BSI: Content, Deadlines, and Template
• Reporting a GDPR Data Breach