Employee Communications During a Cyber Incident

During a cyber incident, staff need to hear from the organisation quickly and safely, yet the normal channels may be down or watched by the attacker, and every "urgent IT message" is a gift to phishers. Poor internal communication causes real harm: staff keep using compromised systems, post speculation on social media, fall for fake helpdesk calls or hand an attacker a view of the response. This guide covers only the staff-facing side of incident communication: which channels to use when email and chat cannot be trusted, what employees may and may not say, how to stop incident messages becoming a phishing lure, update cadence, and what to tell staff whose own data is affected. It is for incident commanders, internal communications leads, HR and the security awareness team. For the full stakeholder plan and approved templates, use the Incident Communication Plan Template; this page goes deeper on employees and does not repeat it.

Key takeaways

Assume the attacker can read your normal channels. CISA reported that Scattered Spider searched victims' Slack, Microsoft Teams and Exchange Online to see whether it had been detected, and frequently joined incident response calls.
Incident messages must be recognisable and verifiable. Agree in advance one sender, one format and one place where staff can confirm any instruction, so a fake "reset your password here" email stands out.
Never ask for credentials or put links to sign-in pages in incident messages. Tell staff to go to known locations themselves; this one rule removes most incident-themed phishing value.
Give a fixed update rhythm, even when there is nothing new. A predictable cadence starves the rumour mill and tells staff where the truth lives.
Staff are also data subjects. If HR or payroll data is affected, staff may need a direct notice under data protection law, written with the same care as a customer notice.

Why employee communication fails in incidents

Three pressures collide. First, the normal channels (corporate email, chat, the intranet) may be encrypted, offline or under attacker observation. CISA's ransomware guide advises using out-of-band methods such as phone calls during coordinated isolation so attackers do not learn they have been detected. Second, staff fill silence with speculation, often in public channels or with journalists. Third, attackers impersonate the response itself: CISA and FBI reported that Scattered Spider posed as company IT or helpdesk staff by phone or SMS to obtain credentials and one-time passwords. An incident is exactly when staff expect unusual instructions from IT, which makes them easier to fool.

Each pressure needs a planned answer, set before the incident and practised in exercises. The table summarises them.

Risk	What it looks like	Planned control
Attacker watching internal channels	Response discussed in the same Teams or Slack tenant the attacker has access to	Out-of-band channel for responders; staff told only what is safe if read by the attacker
Attacker joining calls	Unknown participants on bridge calls; recordings left in shared drives	Invite-only bridges, roll call, waiting rooms, new links per call
Incident-themed phishing and vishing	"IT security" emails, texts or calls asking staff to reset passwords, install tools or read out codes	Published "we will never" rules, verification page, helpdesk callback procedure
Rumour and leaks	Speculation on social media, staff messaging journalists, screenshots of internal notes	Fixed cadence, clear do and do not rules, a named place for questions
Staff unable to work	No laptops, no email, unclear whether to come in	Pre-agreed fallback: phone tree, SMS service, line managers with printed contact lists

Choosing the channel when normal systems are suspect

The design of a full out-of-band environment for responders is covered in the Out-of-Band Communications for Incident Response Guide. Staff communication has a different need: reach every employee, including those without a working device, with messages that are safe if the attacker sees them.

Channel	Reach	Safe while the tenant is compromised?	Best use
Corporate email and chat	Everyone with a working account	Only if identity and mail are confirmed clean	Routine updates once scope is understood
Mass notification or SMS service hosted outside the corporate identity provider	Everyone with a registered mobile number	Yes, if its admin accounts are separate and protected with phishing-resistant MFA	First alert, "do not use" instructions, pointer to the status page
External status page or recorded phone line	Anyone with the address or number	Yes, if hosted separately	Single source of truth for staff to verify instructions
Line manager cascade (phone tree)	Everyone, including those without devices	Yes, if contact lists are held offline	Shift workers, sites with systems down, personal reassurance
Printed notices and site briefings	Everyone on site	Yes	Manual workarounds, where to go for help

CISA's ransomware guide recommends keeping a hard copy and an offline version of the incident response plan; keep the staff contact list and message templates with it. The Out-of-Band Communications Plan Template gives a structure for recording these channels.

Stopping incident messages from becoming a phishing lure

Every incident message trains staff on what a genuine message looks like. Make that pattern hard to copy and easy to check. The NCSC phishing guidance recommends that important email requests are verified using a second type of communication and that staff know the normal ways of working, so unusual requests stand out.

Publish "we will never" rules in advance and repeat them in every message: the security team will never ask for your password, MFA code or recovery code; will never ask you to install software from a link; will never ask you to approve an MFA prompt you did not start.
No sign-in links in incident messages. Tell staff to open the known portal from a bookmark or type the address. If a password reset is needed, follow the Mass Password Reset Playbook, which keeps the reset in known, verified channels.
One verification point. Every instruction appears on the status page or recorded line. Staff are told: if it is not there, do not do it, and report it.
Helpdesk callback rule. Staff never act on an inbound call claiming to be IT; they hang up and call the published helpdesk number. Equally, the helpdesk verifies callers to a higher standard during the incident. See the Help Desk Identity Verification Policy Template.
Consistent sender and format. One named sender (often the incident commander or a named communications lead), a fixed subject prefix, a sequence number and a time stamp. Staff then notice when update 7 appears out of order or from a different address.
Easy reporting. Keep the phishing report button working, or give a fallback (a phone number or SMS short code) if mail is down. The NCSC notes that users may be unable to use normal means of communication if their device is compromised, and recommends quick feedback and no blame for people who report after clicking.

Watch for lookalike domains and spoofed messages that reference the incident, and warn staff with an example when one is seen. The Vishing and Help Desk Social Engineering Awareness Guide covers the voice side.

What employees may and may not say

Staff need a short, plain list. Long policy extracts are not read during a crisis. Issue it in the first message and repeat it.

Do	Do not
Follow instructions only from the named sender or the status page	Speculate about the cause, the attacker or a ransom in any channel
Refer all media, customer and partner questions to the named contact	Comment to journalists or on social media, including personal accounts
Report suspicious emails, calls and texts, especially those about the incident	Forward internal incident notes outside the organisation or screenshot them
Tell your manager if you clicked a link or shared a code, at once	Try to investigate, reboot or "fix" affected systems yourself unless asked
Use the approved customer holding line if customers ask	Promise customers timescales or say data is safe
Keep incident details out of shared drives and chat unless told the channel is clean	Discuss the response on calls you cannot verify

Two cautions. Avoid language that sounds like a gag on raising concerns: say what to refer and where, and remind staff that whistleblowing and regulator routes remain open. And respect legal privilege: if counsel is directing parts of the investigation, staff updates should state facts and actions, not analysis. See the Legal Privilege in Incident Response Guide.

Update cadence and content

CISA's ransomware guide says the communications plan should include organisational communication procedures and holding statements, and agree how much detail is shared internally and how information flows. In practice a simple rhythm works:

Phase	Audience	Cadence	Content
First hour after declaration	All staff	One alert	Something is wrong, what to stop doing, where updates will appear, the "we will never" rules
Containment	All staff	At fixed times, at least daily, plus when instructions change	What works, what does not, workarounds, next update time
Containment	People managers	Before each all-staff update	Briefing pack, likely questions and answers, escalation route
Containment	IT and helpdesk	Per shift	Verification rules, scripts, known lures, what to escalate
Recovery	All staff	Daily, then weekly	Systems restored, password or device actions, thanks
Closure	All staff	Once	What happened at an approved level of detail, what changes, support available

Each update should answer five questions: what we know, what we do not know yet, what you need to do, what you should not do, and when the next update is. Publishing the next update time even when there is no news is one of the most effective rumour controls available. The Incident Commander Role Guide covers who approves each message; the Incident Response RACI Template records it.

When staff data is part of the breach

Payroll, HR and identity systems are common targets, so staff may be victims as well as audience. Under UK GDPR, the ICO says that where a breach is likely to result in a high risk to individuals' rights and freedoms, the organisation must inform them without undue delay, describe the breach in clear and plain language, and include a contact point, the likely consequences and the measures taken. Where possible it should also give specific advice, such as resetting passwords or watching for phishing. Notification to the ICO itself is due within 72 hours of becoming aware of a notifiable breach. Other jurisdictions set their own rules, so involve legal and the data protection officer early.

Separate the notice from routine updates. A data breach notice to staff is a legal communication; draft it with legal and HR and keep it distinct from operational updates.
Expect targeted fraud. Stolen HR data fuels convincing phishing aimed at staff and their families. Tell staff what was taken and what a fraudulent contact might look like.
Offer practical support. A named contact, any identity protection service offered, and how to report suspected misuse.

Implementation plan

Agree ownership. Name the approver for staff messages (usually the incident commander), the drafter (internal communications) and reviewers (legal, HR, security). Record it in the RACI.
Stand up channels before you need them. Register staff mobile numbers in a notification service hosted outside your identity provider, with separate admin accounts. Set up the status page or recorded line. Print contact lists for managers and refresh them quarterly.
Write templates. First alert, containment update, manager briefing, helpdesk script, staff data breach notice and closure note, each with placeholders and the "we will never" rules.
Brief staff in peacetime. Add the verification rules and reporting routes to security awareness training, so staff recognise genuine incident messages before the first one arrives.
Exercise. Include staff communication in tabletop exercises: send a test alert, inject a fake "IT" message and measure who reports it. Use the Ransomware Tabletop Exercise as a base.
Review after every incident and exercise. Record what reached people, what was misunderstood and which lures appeared, then update templates.

Measuring whether it works

Time to first staff alert from incident declaration (target set in the plan, measured in exercises).
Reach: percentage of staff who acknowledged the first alert through the out-of-band channel.
Reporting rate for injected or real incident-themed lures, and time to first report.
Helpdesk verification failures during the incident window (callers who could not be verified and were refused).
Cadence adherence: percentage of updates issued at the promised time.
Unapproved disclosures: count of staff posts or leaks about the incident found by monitoring.

Common failure patterns

Discussing the response on the compromised tenant. CISA reported attackers reading Teams, Slack and Exchange to track the response. In the Co-op Cyber Attack 2025, staff were reportedly told to keep cameras on in meetings, not to record or transcribe calls and not to post sensitive information in Teams chats.
Incident emails that look like phishing. A link to "reset your password now" from an unfamiliar address trains staff to click the next fake one.
Silence while waiting for facts. Staff turn to social media and the press; a holding message with the next update time is better than nothing.
Forgetting staff without devices. Frontline and shift workers miss email-only updates when systems are down.
Open bridge calls. Reused links and no roll call let outsiders listen in, as CISA reported in Scattered Spider cases.
Treating a staff data breach as an internal memo. If HR data is affected, the notice has legal content requirements and needs legal review.

Framework mapping

Need	NIST CSF 2.0	NIST SP 800-53 Rev 5
Notify internal stakeholders of incidents	RS.CO-02	IR-6
Share information with designated internal stakeholders	RS.CO-03	IR-4
Communicate recovery progress	RC.CO-03	CP-2
Plan communication procedures in advance	RS.MA-01	IR-8
Train staff to recognise genuine and fake incident messages	PR.AT-01	AT-2

NIST SP 800-61 Rev. 3 (final, April 2025) frames incident response through these CSF 2.0 outcomes and replaces Rev. 2.

Practitioner checklist

Name the approver, drafter and reviewers for staff messages in the IR RACI.
Register staff mobile numbers in a notification service outside the corporate identity provider.
Set up a status page or recorded phone line as the single verification point.
Publish the "we will never ask" rules now, in awareness training and on the intranet.
Hold printed contact lists and templates with the offline IR plan.
Write the six core templates, including a staff data breach notice reviewed by legal.
Give the helpdesk a stricter verification script for incident periods.
Issue a one-page do and do not list in the first alert.
Commit to a published update time in every message.
Test staff communications, including an injected lure, in every major exercise.

Employee Communications During a Cyber Incident: Internal Messages, Rumour Control and Phishing Risk