Cyber Resilience Guide

Organisations that design only to keep attackers out have no plan for the day an attacker is already inside, holding the domain admin account and deleting the backups. Cyber resilience is the discipline that assumes that day will come and engineers the business to keep its most important services running, at reduced capacity if necessary, and to recover them from a known-good state. This guide explains how resilience differs from security and continuity, uses NIST SP 800-160 Volume 2 goals, objectives and techniques as a design vocabulary, and covers impact tolerances, graceful degradation, the identity plane as a single point of failure, recovery testing and measurement. It is written for security architects, resilience and continuity leads, infrastructure owners and the executives who set impact tolerances.

Key takeaways

• Resilience starts from the service, not the system. Decide which business services must survive, how much disruption each can tolerate, and engineer backwards from those limits.
• Assume the adversary is already in. NIST SP 800-160 Vol. 2 is "predicated on the assumption that the adversary will breach defenses and establish a long-term presence".
• Design degraded modes deliberately. A service that can run in a reduced, isolated or manual mode buys time that no recovery plan can.
• The identity plane is the usual single point of failure. If Active Directory, Entra ID or the management plane is compromised, every recovery that depends on them fails at once.
• Only a tested recovery counts. Measure achieved recovery times from realistic exercises, including rebuild from a compromised state, not restore-from-backup alone.

Resilience, security and continuity

NIST SP 800-160 Vol. 2 states that "Cyber resiliency is the ability to anticipate, withstand, recover from, and adapt to adverse conditions", including attacks on and compromises of systems that use or are enabled by cyber resources. The terms overlap, but each answers a different question:

The difference from classic continuity is the adversary. A flood does not follow you to the recovery site; an attacker with your credentials can. Recovery must therefore restore trust as well as function. Do not confuse the topic with the EU Cyber Resilience Act (Regulation (EU) 2024/2847), which sets security requirements for products with digital elements rather than organisational resilience. Continuity planning, BIA and DR architecture are covered in the Business Continuity and Disaster Recovery Guide; this guide builds on it.

NIST SP 800-160 Vol. 2: goals, objectives and techniques

SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (December 2021, NIST with MITRE), offers constructs that organisations select and adapt: goals, objectives, techniques, approaches and design principles. The four goals are:

• Anticipate: "Maintain a state of informed preparedness for adversity."
• Withstand: "Continue essential mission or business functions despite adversity."
• Recover: "Restore mission or business functions during and after adversity."
• Adapt: modify functions and supporting capabilities in response to predicted changes in the technical, operational or threat environment.

Eight objectives make the goals more specific: Prevent or Avoid, Prepare, Continue, Constrain ("Limit damage from adversity"), Reconstitute, Understand, Transform and Re-Architect. Fourteen techniques describe how to get there. The table shows practical examples for an enterprise estate:

The publication also sets out strategic and structural design principles. Use it as a selection menu for resilience engineering: pick the objectives that matter for each critical service, then the techniques that fit your architecture and budget, and record the choice as part of your cyber resilience strategy so that architecture reviews can test new systems against it.

Important business services and impact tolerances

UK financial regulation turned resilience into a board-level, service-based duty. The FCA's PS21/3 and the PRA's SS1/21 required in-scope firms to identify important business services, those which, if disrupted, "could cause intolerable harm to consumers and markets", and to "set impact tolerances for the maximum tolerable disruption" by 31 March 2022. By "no later than 31 March 2025" firms had to have performed mapping and testing and made the investments needed to operate within those tolerances. Testing is against severe but plausible scenarios, and a cyber attack that corrupts data is the scenario most firms find hardest.

The model works outside financial services too:

1. Name the services customers and the public depend on (take payments, dispatch ambulances, ship orders), not internal systems.
2. Set a tolerance for each, normally a maximum duration of disruption, sometimes with a data or volume limit, approved by the board.
3. Map the resources each service needs: people, sites, technology, data, identity services and suppliers.
4. Test against scenarios such as ransomware across the estate, identity provider compromise, loss of a major cloud region or supplier.
5. Fix the gaps where a scenario would breach tolerance, and record residual risk.

The EU equivalent for financial entities is DORA, with digital operational resilience testing and threat-led penetration testing; see the DORA Guide rather than repeating it here. For essential services in the UK, NCSC Cyber Assessment Framework (CAF) v4.0 Objective D, "Minimising the impact of cyber security incidents", sets the outcome that "Capabilities exist to minimise the adverse impact of a cyber security incident", with contributing outcomes D1.a Response Plan, D1.b Response and Recovery Capability and D1.c Testing and Exercising, plus principle D2 Lessons Learned.

Assume breach: designing for graceful degradation

Attackers who reach the impact stage aim at recovery itself. MITRE ATT&CK lists the techniques resilience design must survive:

The Codefinger S3 ransomware campaign shows the cloud version: stolen AWS keys were used to encrypt buckets with AWS's own encryption, so copies in the same account under the same credentials are not a recovery path. See the Backup Security and Immutable Backup Guide.

Graceful degradation means deciding in advance what a service looks like at 50% and at 10%:

• Minimum viable service: for each critical service, the smallest set of functions, people and systems that still meets the tolerance, such as accepting orders by phone and fulfilling later.
• Manual fallbacks: paper or spreadsheet processes with a defined way to re-enter data afterwards, rehearsed by the people who will use them.
• Isolation by design: segment so that a site, business unit or cloud account can be cut off without stopping the rest. Production lines and clinical systems that cannot run without the corporate domain are a design flaw. The Jaguar Land Rover cyberattack shows the cost when production halts globally.
• Clean recovery environment: an isolated network with its own identity, tooling and gold images where systems are rebuilt and validated before reconnecting.
• Out-of-band communications: a crisis channel that does not depend on corporate email, chat or identity, with contact lists held offline.

Planning for a catastrophic cyber event

Plan explicitly for the worst credible case: every domain-joined Windows system encrypted, the directory untrusted and corporate email gone, for weeks rather than days. Most continuity of operations plans stop short of this. The plan should state:

• Decision rights: who can order a full shutdown, disconnect from partners or the internet, and invoke the clean recovery environment, with deputies named.
• Recovery order: identity and network foundations first, then the services with the shortest tolerances, then everything else, with data validation before reconnection.
• Crisis communication: pre-approved holding statements for staff, customers, regulators and media; a single spokesperson; a cadence for updates; and channels that work without corporate systems. Legal and regulatory notification decisions sit with counsel; see the Incident Response Guide.
• Surge support: retained forensic, recovery and communications partners with contracts signed in advance, and the hardware or cloud capacity to rebuild endpoints at scale.

Where identity fits: the identity plane as a single point of failure

Almost every recovery plan quietly assumes that administrators can sign in. Microsoft's Entra architecture guidance describes IAM resilience as "the ability to endure disruption to system components and recover with minimal impact", tells readers to "assume disruptions will occur and plan for them", and warns that adding identity systems "may reduce your resilience rather than increase it". Design for three identity failure modes:

• Directory compromise: an attacker holding Domain Admin or Global Administrator can wipe devices, disable accounts and delete backups through legitimate tools. In the Stryker cyberattack, one hijacked admin account used Microsoft Intune to wipe tens of thousands of devices. Microsoft's Active Directory Forest Recovery Guide covers the case where "a forest-wide failure renders all domain controllers (DCs) in the forest incapable of functioning normally" and is a template for your own plan. See the Active Directory and Entra ID Hardening Guide.
• Hybrid bridge abuse: sync and federation services connect on-premises and cloud identity, so a compromise crosses both. Storm-0501 used stolen Entra Connect Sync credentials to carry ransomware operations into the cloud.
• Identity provider outage: if the IdP, MFA service or certificate authority is unavailable, nobody signs in to anything. Keep cloud-only emergency access accounts with phishing-resistant authenticators, excluded from dependencies that could fail with the primary path. See the Break-Glass Account Guide.

Non-human identities matter as much: backup software service accounts, hypervisor management credentials and CI/CD tokens are often more powerful than any person. Give backup and recovery tooling separate credentials from production, store recovery secrets offline, and plan to rotate every machine credential after a compromise. See the Service Account Security Guide.

Recovery testing and exercises

Treat each exercise as an incident simulation with realistic constraints: assume email, chat and the primary IdP are unavailable, that a named key person is absent, and that the last two weeks of backups may contain the attacker's persistence. Record the achieved time for each step; it is the most honest measure you have. For ransomware-specific recovery steps, see the Ransomware Response and Recovery Guide.

Implementing a cyber resilience programme

1. Agree scope and tolerances: list critical services with business owners and get board-approved tolerances.
2. Map dependencies: for each service, trace technology, data, identity, network, certificates and suppliers. Flag shared dependencies.
3. Protect recovery first: separate backup credentials, immutable and offline copies, break-glass accounts, offline runbooks. Cheap and highest value.
4. Build the clean recovery environment: start with one critical service and the identity components it needs; prove it in a pilot restore before extending.
5. Design degraded modes: document and rehearse manual and reduced operations with the business.
6. Test and measure: run the exercise programme, compare achieved times with tolerances and feed gaps into funded remediation.
7. Adapt: after each incident or exercise, update architecture, not just documents (CAF principle D2).

Roll out architectural changes in rings: pilot isolation and break-glass changes on a non-critical service, run in monitor mode where controls allow (for example, alerting on backup deletion before blocking it), and keep the previous configuration exportable so a change that disrupts operations can be reverted within the maintenance window.

Decision guidance

• Redundancy or rebuild: active-active replication protects against outages but replicates corruption and attacker changes instantly. For cyber scenarios, pair it with point-in-time immutable copies and the ability to rebuild from code.
• Same provider or diverse: a second region with the same provider and same identity handles infrastructure failure; separate accounts, tenants or providers handle credential compromise. Pay for diversity where the tolerance is shortest.
• Small organisations: focus on offline or immutable backups with separate credentials, break-glass accounts, a printed contact sheet and one annual restore test of the most important system. A managed recovery service can supply the clean environment.
• Large organisations: fund a standing clean recovery environment, identity recovery capability, dependency mapping tooling and a dedicated resilience function linking security, continuity and risk.

Measuring resilience

Measures should show whether services can stay within tolerance, not how many controls exist:

• Services tested within tolerance: percentage of critical services whose last full recovery test met the tolerance in the last 12 months.
• Achieved recovery time: measured time to restore each critical service from a compromised state in the last exercise, against the target.
• Recovery independence: percentage of critical services whose recovery does not depend on production identity, email or management planes.
• Backup integrity: percentage of restore tests that succeeded and were scanned clean before use.
• Degraded-mode readiness: critical services with a rehearsed manual or reduced mode.
• Remediation closure: exercise findings closed within the agreed time.

Monitor the attack paths against recovery: alerts on shadow copy and backup catalogue deletion, retention policy changes, snapshot deletion in cloud and hypervisors, mass account disablement and bulk device wipe actions. For an external benchmark, CISA's Cyber Resilience Review is an interview-based assessment that maps maturity across 10 domains, derived from the CERT Resilience Management Model.

Framework mapping

Common failure patterns

• Backups reachable with production credentials: the attacker deletes them with the same admin account used to deploy ransomware (T1490).
• Recovery that assumes the directory is healthy: restoring servers into a compromised domain re-infects them; identity must be rebuilt or validated first.
• Replication mistaken for resilience: real-time copies replicate encryption and deletion within seconds.
• Tolerances set by IT, not the business: numbers that nobody senior has accepted get ignored when funding is decided.
• Testing only the easy restore: single-server restores pass while a full rebuild has never been attempted, so achieved recovery time is unknown.
• Management plane as the blast radius: one admin account in device management or cloud consoles can wipe or destroy at scale, as the Stryker incident showed.

Practitioner checklist

• List critical business services with owners and board-approved impact tolerances.
• Map each service's dependencies, including identity, DNS, certificates and suppliers.
• Separate backup and recovery credentials from production identity and keep immutable and offline copies.
• Create and test break-glass accounts that work when the primary identity path fails.
• Build a clean recovery environment and prove one critical service in it.
• Define and rehearse degraded and manual modes for each critical service.
• Alert on backup deletion, snapshot removal, retention changes and bulk wipe actions.
• Run an annual full rebuild exercise and record achieved times against tolerance.
• Plan rotation of all machine credentials and secrets after compromise.
• Report resilience measures to the board alongside security metrics.

Standards and references

• NIST: SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach
• NCSC: CAF Objective D, Minimising the impact of cyber security incidents
• FCA: PS21/3 Building operational resilience
• Bank of England PRA: SS1/21 Operational resilience: Impact tolerances for important business services
• MITRE ATT&CK: T1490 Inhibit System Recovery
• Microsoft Learn: Active Directory Forest Recovery Guide
• Microsoft Learn: Building resilient identity and access management with Microsoft Entra ID
• CISA: Cyber Resilience Review

Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide · DORA Guide · Active Directory and Entra ID Hardening Guide · Backup Security and Immutable Backup Guide · Ransomware Response and Recovery Guide