Every year, organisations pour significant resource into compliance. Frameworks are mapped. Controls are documented. Auditors are invited in. And every year, one of the most operationally critical capabilities escapes serious scrutiny.
Out-of-band communication - the ability to coordinate, escalate, and respond through a channel that's entirely independent of your primary infrastructure - sits in a strange position in most compliance programmes. It's implied by almost every major framework. It's tested by almost none of them.
That gap is getting harder to ignore.
DORA, NIS2, and the FCA's operational resilience rules each approach the problem from a slightly different angle - but the thread running through all of them is consistent. Organisations must demonstrate not just that they have plans, but that those plans are executable when primary systems are unavailable, degraded, or actively compromised.
DORA is the most explicit. Its ICT incident management requirements include clear expectations around internal and external communication during disruptions - who is notified, when, through what channel, and how that process is documented and tested. The assumption that your communication infrastructure will be intact during the incident it's meant to help you manage is precisely the assumption DORA is designed to challenge. An out-of-band channel isn't a nice-to-have under DORA. It's the logical conclusion of what the regulation requires.
NIS2 reinforces this. Incident handling obligations include communication requirements that extend beyond simple notification - to regulators, affected parties, and in some cases the public. The 24-hour early warning requirement leaves no room for improvised coordination over channels you're no longer sure you can trust.
The FCA goes further still. Firms must demonstrate - not just assert - that they can remain within impact tolerances during severe but plausible disruptions. That demonstration is impossible without a communication capability that functions independently of the systems under stress.
Crisis communication readiness is difficult to test in a way that satisfies a checkbox. It doesn't map cleanly to a control. It can't be verified by reviewing a document.
Genuine out-of-band readiness means the right people can reach each other, through a channel that's independent of the compromised environment, within a timeframe that keeps regulatory obligations achievable - and that this has been tested under conditions that reflect a real incident, not a scheduled exercise where everyone knows the answers in advance.
That's a harder thing to audit than a policy document. So most audits don't try.
The result is that organisations can be substantially compliant on paper - policies in place, frameworks mapped, sign-off obtained - while being genuinely unprepared for the communication reality of a live incident. The gap isn't visible until it's too late to close it.
Yes - but perhaps not in the way most people assume.
For large enterprises and financial institutions operating under DORA or FCA oversight, out-of-band communication is increasingly a regulatory expectation with teeth. The scale of these organisations means more stakeholders to coordinate, more regulatory relationships to manage, and more reputational exposure if the response is visibly chaotic. A purpose-built, enterprise-grade out-of-band platform isn't optional at this level - it's a core piece of operational resilience infrastructure, and regulators are beginning to treat it as such.
For mid-sized organisations - particularly those in sectors covered by NIS2, or those handling sensitive data at scale - the risk profile is often underestimated. These organisations are frequently targeted precisely because they're seen as less prepared than their larger counterparts, yet they carry similar notification obligations and similar reputational consequences when things go wrong. An out-of-band capability that's proportionate to their size is entirely achievable. The mistake is assuming that because they're not a large enterprise, the need is somehow smaller.
For smaller organisations, the calculus is different but the need doesn't disappear. A lean incident response team actually has less margin for communication failure, not more. When there are only a handful of people who need to coordinate a response, the consequences of those people being unable to reach each other - or of a threat actor monitoring the channel they're using - can be disproportionately severe. Simpler, lighter-weight out-of-band solutions exist precisely for this context.
The common thread, regardless of size, is this: every organisation that has a regulatory obligation to respond to and report incidents also has an implicit obligation to ensure the communication infrastructure that supports that response is trustworthy and independent. The sophistication of the solution may vary. The need for one doesn't.
It starts with independence. Your out-of-band channel must exist entirely outside your primary environment - not hosted on the same infrastructure, not dependent on the same identity provider, not routed through systems that may be offline or compromised.
It requires verified contact. Not a directory that was accurate when it was created, but one that is actively maintained. An out-of-band system is only as useful as the people who can access it. If key contacts haven't verified their credentials since the platform was set up, you don't have a backup - you have a false sense of one.
It demands tested access. Everyone who would need to use the out-of-band channel in an incident should have used it before one starts - from the devices they'd actually use, under pressure that approximates a real scenario.
And it needs to be documented in a way that maps to regulatory expectations. Under DORA and NIS2 in particular, the ability to demonstrate the process - not just describe it - is increasingly what auditors and regulators are looking for.
Compliance teams working through DORA and NIS2 implementation are increasingly encountering a question they weren't prepared for: not "do you have a communication plan?" but "show us it works."
That's a reasonable question. And for most organisations, the honest answer is more complicated than their compliance documentation suggests.
The gap between having an out-of-band communication capability and being able to demonstrate it under scrutiny is where the real compliance risk lives. It's also where the operational risk lives.
Closing it doesn't require a major programme. It requires treating out-of-band communication as a first-class capability - one that gets tested, maintained, and evidenced with the same rigour applied to everything else in the compliance stack.
Because when the primary systems go down and the regulator asks how you coordinated your response, "we figured it out on WhatsApp" is not an answer that lands well.