Cybersecurity Foundations (Grades 6–8) · lesson 44 of 48 · 8 min
Communication Is a Security Skill
When a security incident occurs, the technical response is only half the challenge. The other half is communication — coordinating with your team, escalating to management, notifying affected users, and documenting everything in real time. Poor communication during an incident can be as damaging as the attack itself.
Professional incident response teams practise communication as rigorously as they practise technical skills. They use structured frameworks, clear roles, and defined escalation paths to ensure nothing falls through the cracks under pressure.
By the end of this lesson you will be able to apply the SBAR communication framework, describe the key roles in an incident response team, explain why real-time documentation matters, and identify when to use out-of-band communication channels.
Real consequence
In 2017, a major US hospital was hit by ransomware. The IT team contained the infection but failed to communicate clearly with clinical staff. Nurses continued using infected workstations because no one told them to stop. The infection spread to additional systems. The communication failure doubled the recovery time and cost. The lesson: in an incident, communication failures compound technical failures.
Why Communication Is a Security Skill
When a security incident occurs, technical skills alone are not enough. Incidents are stressful, fast-moving, and involve multiple people with different roles. Poor communication during an incident leads to duplicated effort, missed steps, delayed response, and sometimes makes the situation worse.
Professional incident response teams spend as much time practising communication as they do practising technical skills. This lesson covers the communication principles that make incident response effective.
Roles in an Incident Response Team
Communication Principles During an Incident
The SBAR Communication Framework
The SBAR framework (borrowed from healthcare) provides a structured way to communicate incident status quickly and clearly:
Knowledge Check
Team Communication During Incidents
Why should you use an out-of-band communication channel during an incident involving a compromised email system?
- Email is too slow for incident response
- The compromised system may be monitored by the attacker
- Out-of-band channels are more secure by default
- Email attachments cannot be sent during incidents
Answer: The compromised system may be monitored by the attacker
If the attacker has access to your email system, they can read your response communications and adapt their attack. Use a separate, uncompromised channel.
During an incident, a colleague says “I think it was a nation-state attack.” What is wrong with this statement?
- It is too technical
- It is speculation, not a factual observation
- It should be reported to the media
- It is not relevant to the incident
Answer: It is speculation, not a factual observation
During an incident, communication should be factual. Speculation wastes time and can misdirect the response. Report what you observed, not what you think.
What does the “A” in the SBAR framework stand for?
- Action — what you did
- Assessment — your analysis of the situation
- Alert — the initial notification
- Authority — who is in charge
Answer: Assessment — your analysis of the situation
SBAR: Situation, Background, Assessment, Recommendation. Assessment is your analysis of what the evidence means and how serious the situation is.
Documenting actions during an incident can wait until after the incident is resolved.
- True
- False
Answer: False
Real-time documentation is critical. Memory is unreliable under stress, and post-incident documentation often misses important details. Document as you go.
The person responsible for overall coordination and final decisions during an incident is called the Incident _____.
Answer: Commander
The Incident Commander has overall authority during the response. They receive status updates, authorise actions, and communicate with leadership.
Real-World Case Studies
Case 1: The NotPetya Attack — When Communication Saved Maersk
In 2017, the NotPetya malware destroyed the IT systems of Maersk, the world’s largest shipping company, in minutes. 45,000 PCs and 4,000 servers were wiped. The company had to rebuild its entire IT infrastructure in 10 days — a feat that normally takes months. The key to their recovery was communication: the CEO personally coordinated the response, clear roles were assigned, and teams across 130 countries communicated through a crisis command structure. The lesson: when technical systems fail, human communication and coordination become the primary recovery tool.
Case 2: The Equifax Breach Notification Failure
Equifax discovered their breach in July 2017 but did not notify the public until September — six weeks later. During that time, several executives sold company stock (they were later investigated for insider trading). When the notification finally came, it was poorly communicated, directed users to a fake-looking website, and the notification site itself had security vulnerabilities. The lesson: breach notification is a communication challenge as much as a technical one. Delayed, unclear, or poorly executed notification compounds the damage to affected users and the organisation’s reputation.
Previous lesson: Cyber ethics and permission
Back to Cybersecurity Foundations (Grades 6–8)
Next lesson: Threat modeling for students