About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Out-of-band, in a cyber recovery, means a way to reach the people who must decide and the people who must be told, without using the mail system, the chat tenant, or the identity provider you are treating as untrusted. Those systems are how you normally run an incident. They are also how an intruder watches you, locks you out, and reads the list of systems you are about to save.
The September 2023 #StopRansomware Guide puts the operational warning in the first response steps. After a compromise, actors may monitor your activity and your communications to see whether they have been discovered. Isolate in a coordinated way, and use out-of-band methods such as phone calls, so the response itself does not prompt them to move sideways or to deploy ransomware more widely before the network is taken offline. The same guide tells you to keep a hard copy of the incident response plan and an offline version, to have the communications plan approved by the chief executive or equivalent, and to agree in advance what level of detail is fit to share inside the organisation and with the public. It also tells you to fill in a contact table before you need it: who you will call, and a 24-hour number.
NIST SP 800-184 states the same constraint from the recovery side. Some methods will be unavailable or undesirable. If the network has been compromised, email may be unwise. Teams should prepare alternate means of secure, reliable communication and practise them. The recovery plan's out-of-band item is the ability to reach critical business, IT, and security people, including external responders, without production systems, because advanced adversaries frequently watch those systems. NIST IR 8374r1 says ransomware can disable common channels such as email, that planning must include a way to reach staff and partners anyway, and that the incident plan should contain an out-of-band strategy for when normal business communication is disrupted. NIST SP 800-61 Rev. 3 then recommends sharing recovery progress with the people the plan names, senior leadership to be updated on major incidents, suppliers to be coordinated with under the contract, and public updates to use approved methods and messages.
This article is the communications system. It is not the design of the backup credential, and it is not a notification-law opinion.
What is actually down
"Email is down" understates the failure. Walk the tools a commander would reach for, and mark which of them depend on the identity provider or on a server you have isolated.
- Corporate mail and the chat tool bound to it. Even if the servers still answer, SP 800-184's point is that they may be unwise, not only unavailable. CISA's point is that they may be read.
- The phone system that authenticates handsets or the bridge number through that directory. A help-desk queue that only exists as a mailbox is the same failure.
- The status page, the customer-support console, and the supplier portal whose administrators sign in with the compromised tenant. You can still owe those people an update. You may be unable to post it through the usual door.
- The address book. IR 8374r1's instruction to keep an up-to-date contact list, including law enforcement, legal counsel, and response resources, is there because the global address list will not open. A list that lives only in that address book is not a list you have.
- Personal inboxes you have never agreed to use. They often still work. They are not automatically the plan. A channel you have not named, and have not practised, will be used anyway, by several people, with several versions of the facts.
The CISA guide also says to maintain the plan so it can be followed by security staff and by end users, and to keep it where a network outage does not take it. Paper in the places the named people can stand, and an offline electronic copy that does not require the corporate tenant, are the guide's own words. "It is in the wiki" fails both tests.
Who you reach, and in which hour
SP 800-184 separates stakeholders and asks you to keep current points of contact so recovery is not spent hunting for a mobile number. SP 800-61 Rev. 3 separates the roles: leadership for high-impact decisions, incident handlers, technologists, legal, public affairs, human resources, facilities, and asset owners. The communications plan maps those roles onto channels that survive.
A workable split, as a planning recommendation rather than a template from the standards:
| When | Who | What the call is for |
|---|---|---|
| First hour | The two or more managers who may activate the recovery plan, the incident lead, legal, and the person who holds the offline contact list | Activate, agree the out-of-band channel for the next day, and stop further use of corporate mail for incident content. |
| Same period | The custodian who can release an isolated backup copy, by the path you already tested | So the technical work is not waiting on a mailbox. |
| As soon as the facts support it | Law enforcement and the national response contacts the guide names for US organisations, or the contacts your own plan lists | CISA says to report and to consider asking for help, and to share what you actually know. IR 8374r1 includes those contacts in the list you maintain. |
| On a schedule, not on inspiration | Senior leadership | SP 800-61 Rev. 3 says to update them regularly on major incidents. A schedule stops both silence and a running commentary. |
| Before anything public | Public affairs and legal, using the holding statement you already agreed | CISA says to coordinate so that what is said inside and outside is accurate, and to have agreed the level of detail. |
| When a supplier's service is part of the outage | The supplier's incident contact from the contract, not their account manager's corporate email if that mailbox is yours | SP 800-61 Rev. 3 says to follow the contract's rules for sharing and to coordinate crisis communication with critical suppliers. |
End users need a different message from the one executives need, and they need it on a channel they can still read. SP 800-184's fictional scenarios include telling staff the status accurately while obeying the pre-agreed rules about what may be shared, and adding people to the support path because the usual one is overwhelmed. "Say nothing until we know everything" leaves staff to invent a worse version. The holding statement is how you say something true and small.
What you may say
CISA asks the organisation to reach a consensus, before the incident, on the level of detail that is appropriate inside the organisation and with the public, and to put templates for holding statements in the communications plan. SP 800-184 says to define the goals, scope, and rules of recovery communication before you share, and it points to NIST's threat-information-sharing guide for the preparatory work. SP 800-61 Rev. 3's public-update outcome is "approved methods and messaging", including an explanation of the steps being taken to recover and to prevent a repeat, and it ties breach notification to the organisation's own procedures.
Three content rules follow from those texts. They are our planning recommendations derived from that guidance, not additional quoted requirements.
- Say what you have confirmed and what you are doing next. Leave attribution, attacker names, and the state of any particular backup out of the broad message unless legal and the incident lead have cleared them. Unconfirmed catalogue theories become headlines, and they may also be read by the attacker if the channel is not the one you think.
- Give staff a practical instruction: which systems to leave powered, which phone number to use, whether to come to a site. CISA's technical steps, such as not powering machines off when you still need memory, can be undone by a well-meant all-staff mail that says the opposite. The holding statement and the technical plan have to match. That match is a reason to write both in the same exercise.
- Breach notification is a legal decision. The CISA guide discusses US state breach laws, health-breach rules, and notice to individuals and to other businesses. Those are United States references. An Australian organisation does not discharge its own duties by following that list. Put your counsel's notification path in the contact table. This article is not that advice.
SP 800-61 Rev. 3 also separates public affairs from the technical team because the media sometimes learns of an incident from somewhere else. A plan that assumes you control the first headline is already late. The holding statement is what a spokesperson can say when they are called before the technical picture is finished. "No comment" from five executives and a detailed theory from one engineer is the failure mode the role split is meant to prevent.
A channel you can actually use
The sources do not anoint a product. They describe properties. Apply the properties to whatever you propose to use.
- It does not require the identity provider under suspicion. If the bridge line's host login is a corporate account, you do not have an out-of-band bridge.
- The numbers and the instructions exist on paper and on an offline copy. People who are travelling still need a way in. Name a deputy, which is the same "two or more" SP 800-184 asks for when activating a plan.
- You have placed a call on it in an exercise that forbade corporate mail and corporate chat. IR 8374r1 and SP 800-184 both treat exercise, including communications, as part of preparation. A tabletop that sends the inject by email has not tested this control.
- You know what the channel does not protect. A personal messaging application may be reachable when mail is not. It may also be unsuitable for the detail your consensus forbids, and it may be the same application an attacker already watches on a stolen phone. "Reachable" and "fit for the incident record" are different. The incident record, the decisions, and the times belong somewhere you can keep. A disappearing chat log is a poor record of who authorised a public statement.
- Suppliers and customers are told, in peacetime, how you will reach them if you cannot use the normal portal. A sentence in the contract and a contact who has answered a test call beat a status page you can no longer log in to.
Hypothetical: the incident commander opens the response plan from the file server, finds every number stored as a directory link, and sends a chat message to the executive group that lives in the tenant the attacker is reading. That message is the tip-off CISA describes. The paper list in the executive's home and in the office safe, with a bridge that was tested last quarter, is the control that was supposed to make that message unnecessary. If the test last quarter was cancelled because everyone was busy, the control exists only as a document.
A reachable phone number does not authenticate an instruction. Our recommendation is to verify high-impact requests through a pre-recorded contact route, such as calling back a known number from the offline directory, and use the approval process agreed in advance. Do not accept a caller’s claimed title, caller ID or a new number supplied in the same message as sufficient proof. Record who was verified and what they approved without putting recovery credentials into a broad bridge call.
Risks and limits
- A phone tree leaks. People forward, speculate, and screenshot. The detail consensus is the mitigation. It does not make the channel confidential in a cryptographic sense. SP 800-184 asks for a means that is secure and reliable, and then leaves the implementation to you. This article does not certify any handset, application, or carrier.
- Out-of-band communication can itself alarm an attacker who is watching a particular person. CISA's point about coordinated isolation still applies. Calling fifty people with "we are encrypting, unplug everything" before the handlers have isolated anything is a second incident. The first-hour list is short on purpose.
- Paying a ransom, naming an attacker, or promising a recovery time in the holding statement goes beyond what the sources support. Recovery times in SP 800-184's scenario are internal metrics. They are not a public promise.
- The US reporting contacts in the CISA guide are for that guide's audience. Copying them into an Australian plan as if they were the local authority would be a mistake. Keep them if you have a US duty. Add the contacts your counsel names.
- No call was placed for this article. A channel described here and never dialled is not a capability.
Research and verification
This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.
Sources
Independently reopened 13 November 2026.
- CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
- NIST SP 800-184 (December 2016).
- NIST SP 800-61 Rev. 3 (April 2025).
- NIST IR 8374r1 (June 2026).
This article was originally published on .