Why the tools most organisations plan to use in a crisis are the ones the crisis takes offline – and what a genuinely resilient incident response channel looks like
It is 2:47am. The SOC alert fires. Ransomware is spreading across the network. The security team lead reaches for their laptop and opens Microsoft Teams to pull in the incident response team.
Teams is down. It runs on the same Microsoft 365 tenant that the ransomware just encrypted.
They try email. The mail server is on the affected infrastructure. They try Slack. The Slack integration was connected to the corporate identity provider that is now inaccessible. The ticketing system the team uses to track incidents is on the same network segment that has been isolated. The incident response playbook is in a SharePoint folder that nobody can reach.
The response to the most serious security incident the organisation has ever faced is being coordinated over personal WhatsApp messages and phone calls, with no audit trail, no task tracking, no document sharing, and no way to bring in external forensic investigators without giving them a personal email address.
This scenario is not a worst-case hypothetical. It is the documented reality of how incident response fails in organisations that have invested heavily in security tools but have never addressed a fundamental architectural problem: their incident response infrastructure runs on the same infrastructure the incident attacks.
The Infrastructure Paradox
Every organisation with a mature security posture has an incident response plan. Most of those plans assume that the people executing the plan can communicate with each other, access the playbooks they need, track the actions being taken, and bring in external support when required.
What most plans do not account for is the scenario where the communication infrastructure itself is part of the incident.
Ransomware does not just encrypt files. It encrypts the file server that holds the incident response documentation. The email gateway that the security team uses to communicate. The identity management system that authenticates access to every internal tool. The ticketing platform that tracks open incidents. Modern ransomware operators understand that disrupting the response is as valuable as disrupting the operations – and they target communication infrastructure deliberately.
DDoS attacks take down the network, including the internal tools running on it. Insider threats may involve deliberate compromise of communication channels before other actions are taken. Cloud provider outages can take down Microsoft 365, Google Workspace, and every tool built on top of them simultaneously. And in non-cyber crises – floods, fires, power outages, infrastructure failures – the physical damage that creates the crisis also destroys the communication infrastructure needed to manage it.
The common thread is that the tools you plan to use in a crisis are often the first things the crisis takes offline. Planning to coordinate your incident response over tools that share infrastructure with the systems being attacked is not a plan. It is an assumption that the crisis will be contained enough to leave your communication tools intact. That assumption fails precisely when the crisis is serious enough to matter.
What Out-of-Band Actually Means
Security professionals talk about out-of-band communication as though it is a solved problem. Have a backup phone list. Use personal email in an emergency. Set up a WhatsApp group for the incident response team.
These are better than nothing. They are not a solution.
A personal WhatsApp group has no audit trail. It cannot produce the immutable record of who decided what and when that NIS2, DORA, and most cyber insurance policies require. It cannot be used to securely share forensic findings, vulnerability details, or legal advice. It cannot bring in an external forensic investigator under controlled, authenticated conditions. It cannot track the actions being taken across multiple teams and show the incident commander a real-time view of what has been done, what is in progress, and what has been missed.
Personal email is similarly inadequate. It is unencrypted by default, uncontrolled, and creates a compliance nightmare when the incident review requires production of all communications related to the event.
True out-of-band incident response infrastructure requires a platform that is entirely independent of the organisation’s normal infrastructure – running on separate servers, authenticated through separate credentials, accessible from any device with an internet connection, and carrying none of the dependencies on corporate identity, corporate email, or corporate network access that make standard tools unavailable when the crisis hits.
It also requires that this platform be in place and familiar before the incident occurs. A crisis response channel that has to be set up when the crisis hits will not be set up in time. The team that has never used the platform will not use it effectively under pressure. The playbooks that were never loaded into the channel will not be accessible when they are needed.
Out-of-band means ready before you need it. Independent of everything that might fail. And familiar enough that the team can use it at 3am under significant pressure without stopping to figure out how it works.
The Regulatory Dimension
For most organisations, incident response is no longer just an operational challenge. It is a regulatory one.
NIS2 requires organisations to notify competent authorities within 24 hours of becoming aware of a significant incident, with a full report within 72 hours. DORA imposes similar requirements on financial entities, with detailed expectations around incident classification, escalation, and documentation. Most cyber insurance policies require that the insured be able to produce a complete, chronological record of the incident response – who knew what, when, what decisions were made, and what actions were taken.
These requirements create a problem that WhatsApp messages and personal email cannot solve. The record they require is not just a list of actions taken. It is a documented, authenticated, timestamped record of every communication, every decision, every task assigned and completed, every document accessed and shared – from the moment of detection to the moment of resolution.
In a well-structured incident response channel, this record builds automatically. Every message is logged. Every task is tracked. Every sign-off is recorded with a timestamp and the identity of the person who gave it. Every document shared in the channel is encrypted, access-controlled, and associated with the incident record. When the regulator asks for the complete incident timeline – or when the insurance claim requires it – the record is already there, complete and unimpeachable, without a manual reconstruction exercise that nobody has time for in the 72 hours after a major incident.
The organisations that handle regulatory reporting smoothly after an incident are not the ones that were lucky. They are the ones that had the infrastructure in place to generate the required record automatically while they were managing the response.
Beyond Cybersecurity: Crisis Response Across Every Domain
The infrastructure problem that makes dedicated incident response channels valuable for cybersecurity incidents is equally relevant – and in some ways more acute – for crises that have nothing to do with IT.
A flood that destroys a local authority’s data centre takes down their internal communication tools at exactly the moment they need to coordinate the emergency response. A fire in a commercial building takes the building’s internal systems offline – including the communication tools the response team planned to use. A public health emergency that forces all staff to work remotely may reveal that the organisation’s collaboration infrastructure was never designed to handle a complete and sudden shift away from the office.
Multi-agency response compounds the problem further. A major incident involving police, fire, ambulance, local authority, utilities, and central government requires coordination across organisations that may use completely different communication platforms, none of which are naturally interoperable, and some of which may be affected by the same incident they are responding to.
A browser-based collaboration channel, accessible from any device on any network, requiring no software installation and supporting authentication through existing Google or Microsoft credentials, removes every barrier to cross-agency coordination. The police inspector can join the same channel as the local authority emergency manager and the utility company operations lead within seconds of being invited, from whatever device they have available, without any of the cross-tenant complexity that would normally make this impossible.
The channel that was configured for a specific crisis scenario – major flood, infrastructure failure, public health emergency – before the crisis occurred is available the moment it is needed, with the relevant plans, contacts, and documentation already inside it. The team that has used it in exercises knows how it works under pressure. The response begins in minutes, not hours.
What the Channel Provides During a Live Incident
The specific capabilities that matter most when an incident is active are different from the capabilities that matter for day-to-day collaboration. They are also the capabilities that standard collaboration tools most commonly fail to provide when they are needed.
A communication channel that the incident cannot take offline
Running on independent infrastructure, accessible through a browser from any device, with authentication through credentials that exist outside the compromised environment. If the corporate network is down, the mobile network works. If the corporate identity provider is inaccessible, the channel authenticates through a separate path. If every device on the corporate estate is encrypted, a personal phone or a laptop from a coffee shop can access the channel and contribute to the response.
Controlled external access
Forensic investigators, legal counsel, regulators, insurers, and specialist advisors can be brought into the channel within seconds, authenticated through their own credentials, with access limited to exactly what they need. When their involvement ends, access is revoked instantly. The entire engagement is logged. There are no personal email addresses being shared, no uncontrolled communication channels being opened, and no audit trail gaps created by external parties working outside the managed environment.
Task management that the incident commander can actually use
Every action generated by the incident is a task: isolate this system, notify this regulator, preserve this evidence, brief this executive, patch this vulnerability. Each task is assigned to a specific person or team, given a deadline, and tracked in real time. The incident commander’s dashboard shows what has been done, what is in progress, what is overdue, and what has not yet been started – across every team and every external party simultaneously. Sign-off closes each task formally, creating a timestamped record of completion that feeds directly into the incident report.
Secure documentation
Forensic reports, vulnerability assessments, legal advice, and regulatory communications shared in the channel are encrypted at the application level, with keys held in a hardware security module outside the platform’s infrastructure. Sensitive findings do not travel as email attachments. Privileged legal communications do not exist in systems the incident may have compromised. And when documents are no longer needed – preliminary findings, internal assessments that should not be retained – auto-deletion removes them from the channel entirely, across all participants, without manual effort.
An immutable audit trail that builds itself
Every message, every document access, every task, every sign-off – logged automatically, in real time, tied to verified identities. The record that NIS2 and DORA require is being created by the response itself. When the 24-hour early warning is due, the information needed is already in the channel. When the 72-hour full report is required, the timeline is already assembled. When the insurance claim needs documentation, the record is complete.
Before the Incident: The Preparation That Makes Response Possible
The channel that works during a crisis is the channel that was configured and tested before the crisis. This is the principle that every business continuity professional knows and that most organisations fail to act on.
A tabletop exercise run through the incident response channel does three things simultaneously. It tests the response plan. It familiarises the team with the platform they will use under pressure. And it populates the channel with the documentation – playbooks, contact lists, regulatory notification templates, escalation paths, architecture diagrams – that will be needed when a real incident occurs.
The incident response channel should contain, before any incident occurs, the complete set of materials the response team will need during one. The playbook for each major scenario. The contact details for external advisors, regulators, and insurers. The regulatory notification templates pre-populated with the organisation’s details. The architecture diagrams and system inventories that forensic investigators will need. The escalation authorities and approval thresholds that define who can make which decisions.
When the incident hits, the team does not need to find these things. They are already in the channel. The response begins with the information it needs, in the environment it will use, with the team already familiar with both.
The Question to Ask Before the Next Incident
Every organisation with a security team has an incident response plan. The useful question is not whether the plan exists but whether the infrastructure needed to execute it will be available when it is needed.
If the answer depends on email being up, Teams being accessible, the corporate network being reachable, or any tool that shares infrastructure with the systems being attacked – the plan has a gap that no amount of planning can close. The gap is not in the plan. It is in the infrastructure.
The infrastructure question has a straightforward answer: a dedicated, browser-based, independently hosted channel, configured before the incident, tested in exercises, and carrying everything the response team needs – communication, task management, documentation, external access, audit trail – in a single environment that the crisis cannot reach.
Not because it is hidden. Because it was never part of the infrastructure the crisis attacked.
The best incident response platform is the one that is still running when everything else isn’t. Make sure yours is ready before you need it.
