Out-of-Band Communication: Your Incident Plan Assumes the Systems You're Using to Respond Still Work

Somewhere in your incident response plan is an assumption so obvious no one wrote it down: when something goes wrong, your team will be able to talk to each other privately. They’ll open a Teams channel, start a bridge call, send an email to the crisis distribution list, and get to work. Out of band communication exists because that assumption is now one of the most dangerous lines in your plan.

This isn’t hypothetical. CISA and the FBI warn that Scattered Spider “often search[es] a targeted organization’s Slack, Microsoft Teams, and Microsoft Exchange Online for emails or conversations regarding the threat actors’ intrusion and any security response.” The same advisory says the group “frequently join[s] incident remediation and response calls and teleconferences,” likely to see how defenders are hunting them. When Microsoft disclosed its Midnight Blizzard intrusion, the attackers had been reading email from members of its senior leadership team and employees in its cybersecurity and legal functions, initially looking for what Microsoft knew about Midnight Blizzard itself.

Read that again: the people you need most in a breach, your executives, your security team, and your lawyers, are exactly the people adversaries want to listen to. If your response runs on the systems the attacker already controls, you aren’t running a response. You’re running a briefing for the other side.

What is out of band communication?

Out of band communication is a way for incident responders to coordinate on a channel that is independent of the organization’s primary systems, including its email, chat, conferencing, and identity infrastructure. Because that channel doesn’t depend on the systems an attacker may have compromised, responders can share findings, make decisions, and direct work without tipping off the adversary or losing contact when production systems go down.

The term comes from telecommunications, where “in-band” signaling travels on the same channel as the data and “out-of-band” signaling travels on a separate one. In cybersecurity, the principle is the same: the control channel for your response should not share fate with the environment you’re defending. Governments have been explicit about this for years. A 2020 joint advisory from CISA and the national cyber agencies of the UK, Canada, Australia, and New Zealand lists “communicating over the same network as the incident response is being conducted” as a common misstep and tells responders to “ensure all communications are held out-of-band”.

The word that matters in that definition is independent. A channel isn’t out of band because it’s a different app. It’s out of band when it doesn’t rely on your corporate identity provider, your devices, your directory, or your network to work, and when the attacker has no reason to know it exists.

Why in-band response is losing to offensive AI

Offensive AI is increasing attack velocity, volume, and concurrency, and the gap between how fast attackers move and how fast enterprises can respond is widening. Mandiant’s M-Trends 2026 found that the median time between an initial access event and its hand-off to a second threat group fell from more than 8 hours in 2022 to 22 seconds in 2025. Global median dwell time rose to 14 days. That’s two weeks in which an intruder can map your environment, including the channels your team will reach for the moment it notices.

AI is compressing the attacker’s side of the clock further. In November 2025, Anthropic reported that a Chinese state-sponsored group it tracks as GTG-1002 used AI to “execute 80-90% of tactical operations independently” against roughly 30 organizations, at request rates no human team could match. The response side has no equivalent shortcut. The decisions still belong to people, and those people still need a trusted place to make them.

Attackers also know where defenders go to recover. M-Trends 2026 reports that ransomware groups “are actively destroying the ability to recover,” deleting cloud backups and encrypting hypervisor datastores that can take every virtual machine down at once. Voice phishing became the second most common initial infection vector, at 11% of intrusions, often aimed at IT help desks to bypass MFA and take over identities. When identity is the target, every tool that signs in through that identity is suspect, and that includes the collaboration suite your plan tells everyone to use.

Put those findings together and the risk is clear. The longer an attacker is inside and the more of your identity layer they control, the more likely your in-band response channels are either compromised, monitored, or about to disappear. Out of band communication is how you keep the response itself from becoming part of the attack surface.

Why a Signal or WhatsApp group isn’t an out-of-band plan

Ask most organizations about their out-of-band plan and you’ll hear some version of “we have a Signal group” or “we’ll use WhatsApp on our personal phones.” It feels responsible. It’s encrypted, it’s off the corporate network, and it took ten minutes to set up. Then a real incident starts, and the gaps show up one at a time.

The group is out of date, because the deputy general counsel who joined in March was never added and the CISO who left in June was never removed. No one can verify that the person typing as your CFO is actually your CFO, which matters when voice and identity impersonation are now a leading way in. Decisions about containment, notification, and disclosure are scattered across threads, with no owner, no task list, and no record your counsel can rely on later. And because the channel was never exercised, half the team is installing the app during the first hour of the incident.

The deeper problem is that a messaging app keeps people talking but doesn’t keep the response running. Your playbooks, contact trees, regulatory obligations, and decision log still live in the systems you can’t trust. That’s why the most useful way to think about out of band communication is as the first step in moving the response itself out of band, not as a backup chat.

What a real out of band communication capability needs

If you’re evaluating an out-of-band approach, or pressure-testing the one you have, these are the questions that separate a real capability from a reassuring idea.

1. Independence from corporate identity and infrastructure. Can responders get in if your identity provider, email, or endpoint fleet is compromised or offline? If access runs through the same single sign-on the attacker just took over, the channel isn’t out of band.
2. Verified participants and clear roles. Do you know who is in the room, and can you prove it? Responders should be provisioned ahead of time with defined roles, so legal, executives, IT, and outside advisors each see what they need and nothing they shouldn’t.
3. Provisioned and familiar before the incident. Is everyone already enrolled, and have they used it? A channel that’s introduced mid-crisis adds confusion at the worst possible moment, so it should be part of how you exercise, not just how you respond.
4. The plan travels with the people. Are your playbooks, contact lists, and obligations available inside the independent environment? Talking securely doesn’t help much if the instructions for what to do next are locked in a compromised SharePoint.
5. A defensible record as work happens. Will you be able to show regulators, auditors, and your board what was known, what was decided, and why? Decisions and evidence should be captured as the response unfolds, not reconstructed from screenshots afterward.
6. Useful for every incident, not just the catastrophic one. Is it something your team reaches for from activation through resolution? A capability reserved for the once-a-decade disaster is one nobody will remember how to use.

The regulatory clock doesn’t stop when your email does

Regulators have compressed the time between “something is wrong” and “tell us about it,” and none of their deadlines pause because your collaboration suite is down. Under the SEC’s 2023 rules, a public company’s Item 1.05 Form 8-K is generally due four business days after it determines an incident is material. In the EU, NIS2 requires essential and important entities to send an early warning within 24 hours of becoming aware of a significant incident, followed by a full notification within 72 hours.

Meeting those deadlines takes the coordinated work of security, legal, privacy, communications, and executives, often across time zones and with outside counsel involved. That work depends on sensitive conversations staying confidential and on a clear record of what was known and when. If that coordination happens on channels an attacker can read, or doesn’t happen because those channels are gone, the incident becomes a disclosure problem and a credibility problem as well as a security problem.

Don’t just move communications out of band. Move the entire response.

BreachRx built Out-of-Band Communication to keep responders connected through an environment that is independent of corporate systems, including when those systems are disrupted or untrusted. It runs on the Rex Platform, the out-of-band, AI-powered operating environment for cyber incident response, so teams can start with independent communications as a complete solution on its own.

But communications are only the first part of the response that needs to be independent. Through Cybersecurity Incident Response Management (CIRM), the same environment holds the work itself: the procedures responders follow, who owns each action, the obligations that apply, the decisions made, and the record of how the response unfolded. Rex agentic AI performs supported response work within automated workflows, so the team can keep pace as incidents grow in speed and number, while people remain accountable for the consequential decisions.

Readiness belongs in the same place. With AI Tabletops on Demand, teams exercise more often in the same out-of-band environment they’ll use in a real incident, improve their plans based on what they find, and test again. That way the first time your executives use the channel isn’t the morning your network goes dark.

If your response plan still assumes the systems you’d use to respond will be there and will be private, it’s time to test that assumption. See how BreachRx Out-of-Band Communication works, or run an AI tabletop to find out how your team performs when in-band channels can’t be trusted.

Frequently asked questions about out of band communication

What is out of band communication in cybersecurity? Out of band communication is a channel incident responders use to coordinate that is independent of the organization’s primary email, chat, conferencing, and identity systems. It lets the team communicate privately and keep working even when those systems are compromised, monitored by an attacker, or offline.

Why is out of band communication important during incident response? Attackers increasingly watch how defenders respond. CISA and the FBI report that some groups search Slack, Teams, and Exchange for response conversations and join incident response calls. An independent channel keeps the response from tipping off the adversary and from collapsing when production systems go down.

Is a consumer messaging app like Signal or WhatsApp good enough? It’s better than nothing, but it usually isn’t a plan. Group membership drifts, identities are hard to verify, decisions and obligations are scattered across threads, and nothing creates a record the organization can rely on later.

What is the difference between out-of-band communication and out-of-band authentication? Out-of-band authentication verifies a user’s identity through a second, separate channel, such as an authenticator app. Out of band communication is about where incident responders coordinate. Both rely on the same principle of not trusting a single channel the attacker might control.

When should an organization use out-of-band communication? From the start of any managed response, not only once an incident becomes a crisis. Teams that only switch over after confirming a compromise have often already discussed the incident on channels the attacker could see.

How often should we test our out-of-band plan? Often enough that using it is routine. Exercising your out-of-band environment during regular tabletops makes sure people are enrolled, know how to get in, and know where the plan lives before they need it.

Sources

• CISA and FBI, Scattered Spider, AA23-320A (updated July 29, 2025)
• CISA, ACSC, CCCS, NZ NCSC, CERT NZ and UK NCSC, Technical Approaches to Uncovering and Remediating Malicious Activity, AA20-245A (September 1, 2020)
• Microsoft, Form 8-K Exhibit 99.1 on Midnight Blizzard (January 2024)
• Mandiant (Google Cloud), M-Trends 2026 (March 23, 2026)
• Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign (November 2025)
• U.S. SEC, Press Release 2023-139 (July 26, 2023)
• Centre for Cybersecurity Belgium, The notification of NIS2 incidents (updated March 14, 2025)