The first hour is a leadership problem

What changed

The NCSC has published a practical framework for organisations facing a cyber attack severe enough to stop normal operations. It separates recovery into three phases: immediate action in the first hours, a structured programme to reach minimum viable operations, and a longer rebuild.

That sequence matters because the pressure to restore everything at once can create a second incident. The guidance warns that recovering before responders understand whether an attacker still has access can restart the damage. Fast is useful; fast without a shared picture is merely energetic.

The first hours need command, not improvisation

The opening phase is deliberately broader than IT. The NCSC recommends a clear incident command structure, specialist incident-response support, an initial view of affected business functions and dependencies, and one authoritative record of facts, decisions and actions.

Even apparently technical choices carry business consequences. Disconnecting a system may limit an attack and preserve evidence; powering it down may destroy useful evidence or make the investigation harder. The right decision depends on safety, operational impact and specialist advice, not whoever reaches the plug first.

Communications also need a trusted route. If normal corporate channels may be compromised, the organisation needs an alternative way to coordinate staff, suppliers and customers. Regulatory and contractual reporting deadlines must be identified separately; reporting to the NCSC does not replace those obligations.

Recover the business, not just the servers

The NCSC defines minimum viable operations as the lowest safe level at which an organisation can keep operating, meet legal duties and maintain trust. That reframes the recovery queue. Payroll, customer support or a manual order process may matter before a less critical system that happens to be easier to restore.

Identity is an early dependency because existing accounts may be compromised. Backups need the same suspicion: confirm that they are available, complete and trustworthy before relying on them. Temporary workarounds should also receive a security review so urgency does not quietly introduce a fresh route in.

What to do before the alarm

The government's Cyber Governance Code expects boards to gain assurance that an incident plan exists, is exercised at least annually with relevant internal and external stakeholders, and is improved after exercises and real incidents. The NCSC goes further in practical terms: test failover, rehearse shutdown and restart, and prove that systems can actually be rebuilt from backups.

A useful rehearsal should leave four things behind: named decision-makers, an offline contact route, a prioritised list of business functions and dependencies, and evidence that recovery data works. A beautifully formatted plan without those ingredients is stationery.

• Name the incident lead and the people authorised to make containment decisions.
• Record critical business functions, the systems they depend on and the order they should return.
• Keep trusted contacts for legal, insurance, communications and incident-response support available offline.
• Restore a representative backup into a clean environment and document the real time and dependencies.
• Run a scenario at least annually, then update the plan from what failed or caused delay.

The Beekeeper view

External security work is often framed around preventing entry. That remains essential, but resilience asks a second question: if a public-facing system fails or is compromised, does the organisation know what it can trust and what must come back first?

The strongest recovery plans are short enough to use, specific enough to test and owned beyond the technology team. The calmest incident response usually began months earlier, in a room where nothing was on fire.