There is a point in many cybersecurity incidents when the technical side is already moving, but the organization around it is still figuring things out.

The alert has fired off, the communication channel has been established, people are joining from security, IT, operations, legal, perhaps communications, and yet the room is not quite ahead of the incident. It is still trying to decide what sort of problem it is looking at.

Which systems must be isolated first, which data matters enough to protect at all costs, which service has to keep breathing even if the rest of the network goes dark for a while, which vendor or dependency, sitting quietly in the background on an ordinary day, is about to become the turning point for the next six hours. In more organizations than many would care to admit, that knowledge is still too scattered, too informal, or too dependent on the right person being around when the crisis hits.

That is what makes the present moment more serious than another familiar round of “cyber-panic”. The pace has changed, and it is beginning to expose a weakness that many mature security programs have managed to live with for longer than they should have.

Microsoft warned this month that in some Medusa ransomware campaigns, the time from exploitation of vulnerable web-facing assets to exfiltration and deployment can collapse into roughly 24 hours.

The issue is not simply that this is fast, though it certainly is. It is that a day leaves very little room for an organization to discover, in the middle of an incident, what it should already have known before one began.

Build better firefighters

Organizations are obsessed with building better detectors, “finding the fire faster”, but they fail to build better firefighters — the human process of organizing a response once the “fire” is found. The real failure isn't seeing the threat; it's the chaotic, slow, and confusing process of translating that technical signal into a coordinated business action. Most assume that with a clean dashboard, good controls, and respectable governance language, they are prepared, but in reality, they lose the plot at the handoff when the issues are organizational.

And that's where the cracks are starting to show. What slows response is often not some grand strategic failure, but an accumulation of smaller, older habits: “criticality” defined too broadly to be useful, escalation paths living in spreadsheets, fallback procedures that looked sensible six months ago, annual tabletop exercises treated almost like a ceremonial ritual, completed as a matter of obligation, then forgotten just as quickly. Then a real incident arrives, fast and badly timed, and the whole arrangement reveals itself for what it is: not quite preparation, more a collection of good intentions that have never been taught to move together.

CISA’s own guidance points in a more serious direction than many organizations have yet taken. It tells organizations to identify and prioritize critical systems and data for restoration, maintain communications plans, and exercise incident response and resiliency plans rather than merely keep them on file. NIST’s revised incident response guidance also advises a concrete approach. An organization should not be making its first real decisions about criticality, continuity, and authority while the incident is already unfolding.

A recent example

A recent public example shows just how far this can reverberate. In the US in April, after a cyberattack disrupted critical systems and digital services in Minnesota, Governor Tim Walz authorized Minnesota National Guard support because the incident had significantly impaired the county’s ability to deliver emergency and municipal services. A cyber incident becomes something else the moment ordinary decision paths, communications, and essential operations begin to wobble.

This is where resilience tends to fail now: at the intersection of technical detection and operational execution. Many organizations have spent real money on tools, monitoring, and governance. Far fewer have already defined which information is truly critical, which systems and vendors are upstream dependencies, which fallback procedures must activate first, and which decisions belong to whom once normal conditions begin to slip. The organization might have all the right tools, but it is still oddly unready to handle its own response.

That is also why the answer is not simply “more security.” It is a more disciplined operating model around response. The first step is continuous information control. Before anything goes wrong, an organization needs to know exactly which data, services, dependencies, and communication paths are truly vital. This isn't about what looks good on paper or fits a checklist for rules; but rather real-world operations. They need to clearly identify: what must be preserved, what can be sacrificed, and what absolutely cannot be allowed to drift into uncertainty for even a few hours.

A way of reducing hesitation

The second step is to treat crisis exercise less as a yearly ritual and more as a way of reducing hesitation. Smaller, lighter, repeatable exercises do more for real response than the grand tabletop that happens once a year and disappears into memory the following week. Teams need to rehearse the decisions that become expensive under compression: who isolates what, who declares what, who speaks to staff, customers, or the public, what gets restored first, and what dependencies will quietly halt the work if no one has mapped them in advance.

The third step is to treat continuity communications as part of response design, rather than a courtesy to be addressed after the technical work has started. In many incidents, communication isn't just something you do after the problem starts. It is actually part of the problem itself. If employees don't know where to go, if external partners aren't sure which contact method is safe, or if leaders are trying to use a system that might be broken, everything slows down. These delays pile up quickly, and no report or chart can fix them later.

The next divide in cyber maturity will not be between organizations that detect and those that do not. Detection has improved. The sharper divide, rather, will run between organizations that can act under compression and those that are still trying to decide what matters while the incident is already moving. That is the real gap now. Not a lack of alerts, but a lack of readiness at the moment when alert has to become action. And that is a more unsettling weakness, because it sits much closer to the center of the organization itself.

We've Reviewed, Rated, and Ranked the Best Firewall Software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Founder of Risk & Decision and Resilient24.