Resilience and recovery

For years, security spending flowed almost entirely toward keeping attackers out. The current frameworks correct that. The NIST Cybersecurity Framework 2.0 keeps Recover as one of its six named functions, alongside Govern, Identify, Protect, Detect and Respond, which means recovery is treated as a designed capability to be planned and measured, not an improvisation that begins once everything else has failed.

The UK regulator makes the same point in enforceable terms. The NCSC Cyber Assessment Framework devotes its whole objective D to minimising the impact of an incident: the ability to restore essential functions, the planning that makes restoration possible, and the improvement that follows an event. For operators of essential services, that is not advice but the profile an auditor scores them against. The practical consequence is that recovery evidence, tested restores, a defined recovery plan, a rehearsed team, becomes something a board is expected to be able to show, not merely assert.

Recovery also sits inside a longer arc. It is the last stage of incident response in NIST SP 800-61 Rev. 3, and it feeds the wider discipline of business continuity, the plan for keeping the whole organisation running through a disruption of any cause. The internationally recognised standard for that discipline is ISO 22301, which sets out how to run a business continuity management system. Cyber recovery is the part of continuity that assumes the disruption is a deliberate, adaptive adversary rather than a flood or a failed disk.

Almost every organisation has backups. Far fewer have backups that survive contact with a competent attacker, because a ransomware operator who has gained administrative rights does not start by encrypting the live systems. They start by finding and destroying the backups, so that paying becomes the only way back. Backup design is therefore adversarial design, not storage administration.

The familiar 3-2-1 rule is the floor and not the answer: keep at least three copies of the data, on two different kinds of media, with one copy off site. That protects against fire, theft and hardware failure. It does not, on its own, protect against an attacker with your credentials, because a copy that your administrators can delete is a copy the attacker can delete once they hold those administrator accounts. Three properties close that gap.

The first is an immutable backup: a copy written once and then locked against change or deletion for a set retention period, using write-once storage or an object-lock feature. Even an attacker with backup-admin rights cannot remove it before the retention window expires. The second is separation of trust: the backup system runs on its own credentials and its own identity domain, so compromising the production directory does not hand over the backups as well. The third is an offline or air-gapped copy that is physically or logically disconnected, the copy Maersk survived on by accident. The last property, and the one most often skipped, is a tested restore at production scale. A backup that has never been restored is a hypothesis, not a control.

Read the ladder from the top down. The convenient copies, an online replica or a snapshot in the same account, restore fastest but share the credentials the attacker already holds, so they may be encrypted along with everything else. As you move down, each layer survives a stronger attacker and typically takes longer to restore, until the offline copy survives a full domain compromise at the cost of the slowest recovery. The design question is not which single layer to have but how the layers combine, so that the fastest surviving clean copy is the one you actually restore from.

Two numbers turn resilience from an aspiration into an engineering requirement. The recovery time objective is the longest a service can be down before the disruption causes unacceptable harm. The recovery point objective is the most data, measured as a period of time, the organisation can afford to lose, which is really a statement about how often backups must be taken. A payroll system with an eight-hour recovery time objective and a fifteen-minute recovery point objective is a very different engineering problem from an archive that can be down for a week and lose a day.

The discipline is to derive both numbers from a business impact analysis, service by service, rather than accept whatever a storage product happens to deliver. Ask what breaks, and for whom, when a given service is unavailable for an hour, a day, a week, and the tolerances fall out of the answers. That matters because tighter targets cost more, often steeply: a fifteen-minute recovery point means near-continuous replication, while a daily backup is cheap. Setting the target first, then paying for the architecture that meets it, is the correct order. An objective that nobody costed is a wish rather than a target, and it is discovered to be a wish only during the incident.

There is a cyber-specific twist that a generic continuity plan misses. Against a destructive attack, the most recent recovery point may itself be poisoned, because the malware or the attacker may have been present in the environment for weeks before detonation. Recovery therefore sometimes means restoring to an earlier, known-clean point and accepting more data loss than the recovery point objective would normally allow, which is a decision the business must have agreed in advance rather than improvised at three in the morning.

A plan that has never been rehearsed is a document, not a capability. Exercising recovery runs on a progression. A tabletop exercise gathers the people who would make the decisions and walks them through a scenario in discussion, surfacing the gaps in roles, authority and communications cheaply and without touching production. A technical restore test then proves the mechanics: that the immutable copy really restores, that it restores within the recovery time objective, and that the restored system is clean. The NCSC offers Exercise in a Box as a free structured set of exercises across a range of scenarios, which removes the excuse that building a first exercise is too much work.

A cyber recovery is not one team's job done in sequence but four teams working in parallel under time pressure. The figure below lays the first 72 hours out as swimlanes so a tabletop can walk the grid and ask, for each cell, who does this and by when.

Incident command sets priorities and holds the recovery order so that the highest-value services come back first. Technical recovery, the emphasised lane, preserves evidence, then rebuilds a clean core from an immutable copy before restoring services in order and watching for reinfection. Communications keeps staff, customers and the board informed on a steady cadence, because silence is filled by rumour and by the attacker's own leak site. Legal and regulatory assesses reporting duties against the clock: a personal-data breach may have to be reported to the Information Commissioner's Office within 72 hours of the organisation becoming aware of it, and the insurer and counsel are engaged early because their decisions shape everything else. The grid makes the interdependencies visible, which is exactly what a first rehearsal needs to expose.

Perfect recovery answers only half of a modern ransomware incident. The previous module showed that extortion has shifted from encryption to double extortion, where the attacker steals the data before encrypting and then threatens to publish it. Restoring from an immutable backup brings your systems back and defeats the attacker's encryption hold entirely, but it does nothing about the copy the attacker already took. You can be fully recovered and still facing the threat of publication.

This is why resilience is necessary but not sufficient, and why it must be paired with the controls from neighbouring modules. Recovery covers the availability half of the problem: getting services back. The confidentiality half, the stolen data, is answered by reducing what an attacker can exfiltrate in the first place, by detecting the theft early, and by the governance and disclosure duties that decide how a leak is handled once it has happened. A resilience plan that promises the board that backups make ransomware a non-event is quietly wrong, and it is better to say so before an incident than during one.