On 29 July, the NCSC published What To Do When Cyber-Attacks Disrupt Your Organisation, a detailed framework covering the first hours of a disruptive attack through to the months of rebuild that follow. It’s well timed. Attack volumes are up, and the guidance is clear-eyed about something many boards still underestimate: recovery from a serious cyber incident routinely takes weeks, sometimes months, not the days most contingency plans assume.
It’s also genuinely useful. But read against twenty years of established business continuity practice, it’s worth being precise about what the guidance adds, what it simply restates, and where it leaves organisations exposed if they treat it as the whole picture.
What it gets right
The three-stage structure, first hours, recovery to minimum viable operations, then longer-term rebuild, maps sensibly onto how a serious incident actually unfolds, and the guidance resists the temptation to make each stage sound tidier than it is. It’s honest that priorities won’t be fully defined in the first few hours, that recovery timelines slip, and that leaders should expect setbacks rather than a clean technical fix.
The emphasis on rehearsal over documentation is also worth noting. The NCSC draws a comparison to marathon training: reading about the race and writing a plan is a start, but it’s the actual running that builds the capability. That’s not a new idea to anyone who’s run a tabletop exercise, but it’s a useful reminder that a plan sitting in a folder is not the same thing as an organisation that can respond.
The cross-cutting functions, good leadership, governance and record-keeping, workforce wellbeing, log learning, are also well chosen. Burnout among the people carrying an incident is a real and under-discussed risk, and the guidance is right to treat it as a delivery function rather than an afterthought.
Where minimum viable operations meets minimum business continuity objectives
The guidance’s central concept, recovering to minimum viable operations, will sound familiar to anyone working within ISO 22301. Business continuity practitioners have had a term for this for years: the minimum business continuity objective, the reduced level of service an organisation can accept during recovery. The NCSC’s version is a reasonable restatement of the same idea, and there’s nothing wrong with that. But the guidance introduces it as though it’s a fresh concept, with no reference to existing BC frameworks or to the business impact analysis work that should already have identified which functions matter and in what order.
That matters in practice. Several of the recovery workstreams described, recovering business functions, developing workarounds, common infrastructure and assurance, all assume that priorities from triage are already in hand and simply need executing against. For an organisation with a mature BIA, that’s exactly right. For one without, this is the point in the guidance where things get theoretical. Deciding what’s business-critical in the middle of a live incident, under pressure, with incomplete information, is a much harder exercise than the document implies. The guidance describes the mechanics of recovery well. It has much less to say about how you’d generate a sound prioritisation on the fly if the groundwork wasn’t done in advance.
Strong on cyber, thinner on operational resilience generally
Strip out the cyber-specific elements, incident response providers, ransom payment approach, operational technology considerations, and what’s left is a genuinely solid generic framework for recovering from any major operational disruption: incident command, a structured recovery programme with named workstream leads, cross-cutting governance and wellbeing functions, a rebuild phase focused on addressing root causes rather than just patching over them.
That’s a strength, if organisations recognise it. A recovery programme structured this way would serve just as well after a fire, a major utility failure, or the loss of a key site, not only a ransomware attack. The guidance doesn’t invite that broader reading itself, understandably, since it’s an NCSC publication with a cyber remit, but resilience professionals reading it should. There’s more transferable value here than the title suggests.
Who this is actually written for
The guidance names its intended audience clearly: CEOs, boards, CISOs, CTOs and dedicated resilience professionals, in organisations where the loss of digital systems has significant operational consequences. That’s an honest scope, and it shows throughout. References to Gold, Silver and Bronze command structures, dedicated financial modelling workstreams, and named leads for eleven separate recovery workstreams all assume a headcount and organisational depth that most small and mid-sized organisations simply don’t have.
That’s not a criticism of the document on its own terms. But it’s a real gap for the much larger population of organisations who’ll read this, recognise the value in it, and then have to work out for themselves how a recovery programme with eleven workstreams collapses down to the two or three people who’ll actually be running it. Anyone advising smaller clients on incident response will need to do that translation work themselves; the guidance won’t do it for them.
The bottom line
This is worth reading, and worth using to pressure-test an existing business continuity plan against a fresh, authoritative source. It’s well timed, honest about how long recovery really takes, and right to treat leadership behaviour and workforce wellbeing as core to recovery rather than incidental to it. What it isn’t is a substitute for the prioritisation work a proper business impact analysis already does, or a framework that’s been scaled for organisations without a CISO and a board. Use it to check your thinking. Don’t mistake it for the whole plan.
