Cyber Resilience Maturity Model: Five Levels and Assessment

Organisations routinely report that backups exist and disaster recovery is documented, then discover during a destructive attack that they cannot rebuild the business in weeks, let alone the hours their plans assumed. This model describes five levels of cyber resilience maturity, from Ad hoc to Optimised, across seven dimensions: business impact analysis, backup protection, recovery testing, clean recovery environments, minimum viable company planning, identity recovery and governance. Each dimension has observable indicators, self-assessment questions and the steps to move up a level. It is written for resilience leads, CISOs, infrastructure owners and the executives who set impact tolerances. The concepts behind it (NIST SP 800-160 Vol. 2 goals, impact tolerances, graceful degradation) are explained in the Cyber Resilience Guide; this page assumes them and focuses on staged maturity.

Key takeaways

Resilience is measured by recovery, not by backups. The test is whether the organisation can restore its most important services within a tolerance the business has agreed, from copies an attacker could not reach.
Level 3 means proven, not planned. At Defined, recovery times come from tests rather than vendor specifications, and backups are isolated and immutable.
Identity is usually the first thing to rebuild. If directory, privileged and machine accounts cannot be restored to a trusted state, nothing that depends on them can be trusted either.
The minimum viable company sets the order. Mature organisations know the smallest set of services they must run to survive and have rebuilt that set in an exercise.
Score each dimension separately. Strong backups with no clean room, or a good BIA with no tested restore, leaves the organisation at its weakest level.

The five levels

Level	Name	Description
1	Ad hoc	Backups run but are reachable from the production domain and rarely restored. There is no business impact analysis, recovery order is decided during the incident, and identity systems are assumed to survive. Continuity plans do not consider cyber attack.
2	Developing	A BIA exists for some services and recovery time objectives have been set. Backups are copied offsite or to a separate account, with some immutability. File-level restores are tested; full system rebuilds are not. An incident response plan mentions recovery.
3	Defined	Important business services and impact tolerances are agreed by the business. Backups are isolated, immutable and protected by separate credentials. Full restores of critical services are tested at least annually, a clean recovery environment design exists, the minimum viable company is defined, and identity recovery has a written runbook.
4	Managed	Recovery is rehearsed end to end, including identity, in a clean environment. Actual recovery times are measured against tolerances and reported to the executive. Dependencies, including suppliers and cloud control planes, are mapped and kept current. Backup integrity is checked automatically.
5	Optimised	Services are designed to degrade gracefully and recover by rebuild from code and golden images. Recovery capability is tested continuously, scenarios are drawn from threat intelligence and real incidents, and lessons change architecture and investment.

The level names follow the NHI Mgmt Group five-level scale used across our maturity models, including the Identity Security Maturity Model.

The seven dimensions

Dimension	Level 1 indicators	Level 3 indicators	Level 5 indicators
Business impact analysis	No BIA, or an IT asset list ranked by IT	Important business services named; impact tolerances, maximum tolerable downtime, RTO and RPO agreed by business owners; dependencies mapped	Tolerances reviewed after every change and incident; dependency maps generated from live data
Backup protection	Backups on the production domain with shared administrator accounts	Offline or logically isolated copies; immutability (object lock or equivalent); separate identities and multi-person approval for deletion	Integrity and malware checks automated on every copy; backup estate treated as a separate security domain
Recovery testing	Occasional file restores	Full restore of each critical service at least annually; results recorded against RTO	Continuous automated restore testing; scenario exercises with business and suppliers
Clean recovery environment	Recovery planned into the compromised estate	Isolated recovery environment designed, with its own identity, network and tooling; build procedure documented	Clean room rebuilt from code on demand and exercised; forensic and recovery work separated
Minimum viable company	Every system treated as equally urgent	The smallest set of services needed to survive is defined, with recovery order and exit criteria per stage	MVC rebuilt in exercises; manual workarounds tested for the time until it is back
Identity recovery	Directory assumed to survive; no offline credentials	Runbooks for directory and cloud identity recovery; break-glass accounts and recovery keys stored offline; service and machine credentials inventoried	Identity rebuilt first in every exercise; all privileged and machine credentials reissued as part of recovery
Governance and learning	Resilience owned by IT alone	Executive owner; resilience metrics reported; suppliers held to backup and recovery requirements in contracts	Board sets tolerances; lessons from exercises and incidents change investment and architecture

Why these dimensions

Business impact analysis: NIST SP 800-34 Rev. 1 puts the BIA at the centre of contingency planning, and the UK Prudential Regulation Authority's SS1/21 requires financial firms to identify important business services and set impact tolerances for them. Without them, recovery has no target. See the Business Impact Analysis Template.
Backup protection: CISA's #StopRansomware Guide notes that many ransomware variants search for and delete or encrypt reachable backups, and recommends offline, encrypted backups that are tested regularly, plus object lock, delete protection and versioning for cloud storage. Attackers deleting backups maps to ATT&CK T1490 Inhibit System Recovery. See the Backup Security and Immutable Backup Guide.
Recovery testing: the NCSC Cyber Assessment Framework outcome D1.c expects exercises built from past incidents, threat intelligence and risk assessment, run routinely, testing every part of the response cycle.
Clean recovery environment: restoring into a compromised estate reinfects it. CISA advises checking for precursor malware before restoring and avoiding reinfection of clean systems during recovery. See the Cloud Recovery and Clean Room Guide and the Cyber Recovery Vault Guide.
Minimum viable company: sets the recovery order when everything is down at once. See the Minimum Viable Company and Critical Service Recovery guide.
Identity recovery: CISA recommends resetting passwords only after the environment has been cleaned and rebuilt; mature programmes go further and reissue every privileged and machine credential. See the Recovering IAM and PAM After Ransomware or Domain Compromise guide and the Active Directory Forest Recovery Runbook.
Governance and learning: NIST SP 800-160 Vol. 2 frames resiliency as the ability to anticipate, withstand, recover from and adapt to adverse conditions. Adapting is a governance outcome, not a technical one.

Dimension to framework mapping

Dimension	NIST CSF 2.0	NIST SP 800-53 Rev 5	NCSC CAF
Business impact analysis	GV.OC-04 Critical objectives, capabilities and services understood	CP-2 Contingency Plan	D1.a Response Plan
Backup protection	PR.DS-11 Backups created, protected, maintained and tested	CP-9 System Backup	D1.b Response and Recovery Capability
Recovery testing	ID.IM-02 Improvements identified from tests and exercises	CP-4 Contingency Plan Testing	D1.c Testing and Exercising
Clean environment and restore integrity	RC.RP-03 Integrity of backups verified before restoration; RC.RP-05 Integrity of restored assets verified	CP-10 System Recovery and Reconstitution	D1.b
Minimum viable company and graceful degradation	PR.IR-03 Mechanisms implemented to achieve resilience requirements	SC-36 Distributed Processing and Storage	D1.a
Governance and learning	ID.IM-02	CP-2	D2 Lessons Learned

Regulated sectors add their own expectations: see the DORA Guide for EU financial entities and the HKMA Cyber Resilience Assessment Framework Guide for Hong Kong banks.

Self-assessment questions

Answer yes only with evidence. Three or more "no" answers in a dimension place you below the level named.

Business impact analysis (Level 3)

Have business owners, not IT, agreed the important business services and their impact tolerances?
Does each critical service have a documented RTO and RPO, and a dependency map covering identity, network, data, suppliers and cloud control planes?
Was the BIA reviewed in the last 12 months or after the last major change?

Backup protection (Level 3)

Could an attacker with Domain Admin or cloud tenant administrator rights delete or encrypt every copy of your critical data? If yes, you are below Level 3.
Are backup administration accounts separate from production identities, protected by phishing-resistant MFA and multi-person approval for deletion or retention changes?
Do suppliers that hold or back up your data meet the same requirements, written into contracts?

Recovery testing (Level 3 to 4)

Has each critical service been fully restored (not just files) in the last 12 months, with actual time recorded against RTO?
Did any exercise assume the directory and backup console were unavailable?
Are exercise findings tracked to closure and reported?

Clean recovery environment (Level 3 to 4)

Is there a designed, isolated environment with its own identity and network to recover into?
Can it be stood up within your tolerance, and has it been?
Do you scan restored data and images for persistence before reconnecting them?

Minimum viable company and identity recovery (Level 3 to 4)

Is the minimum viable company written down, with recovery order and exit criteria per stage?
Are break-glass credentials, recovery keys and the contact list available offline?
Is there an inventory of service accounts, API keys and certificates that must be reissued after a compromise?

Governance (Level 4)

Does an executive own resilience, and does the board see recovery test results against tolerances?
Have lessons from an exercise or incident changed investment or architecture in the last year?

Moving up a level

Level 1 to 2: get a baseline. Run a BIA for the top services, set RTO and RPO, move at least one copy of backups out of reach of production credentials, test file and system restores, and add recovery to the incident response plan.
Level 2 to 3: make backups survivable and prove restores. Enforce immutability and separate backup identities; agree impact tolerances with business owners; define the minimum viable company; write identity recovery runbooks and store break-glass credentials offline; fully restore each critical service once and record the time. Start with one service as a pilot and keep the old backup chain until the new one has passed a restore test.
Level 3 to 4: rehearse the whole thing. Build and exercise a clean recovery environment; rebuild identity first, then the minimum viable company, in an exercise that assumes the production domain is lost; measure against tolerances and report to the executive; automate backup integrity checks; bring key suppliers into exercises.
Level 4 to 5: design for recovery. Rebuild infrastructure from code and golden images (CISA recommends keeping version-controlled infrastructure as code templates with offline copies), design services to degrade gracefully, run continuous restore testing and draw scenarios from threat intelligence and real incidents.

A small organisation can reach Level 3 with immutable cloud or offline backups, a one-page BIA, a written minimum viable company and an annual full restore test. Levels 4 and 5 require dedicated recovery infrastructure and staff that are usually justified only where downtime costs are high or regulators require it.

Metrics that show maturity

Metric	What it shows	Typical Level 3 expectation
Critical services with a full restore test in the last 12 months	Whether recovery claims are proven	All of them
Measured recovery time versus RTO, per service	Gap between plan and reality	Recorded and within tolerance, or a funded plan to close it
Critical data with an immutable, isolated copy	Survivability of backups	All critical data
Accounts able to delete or alter backups	Backup blast radius	Small, named, separate from production, MFA protected
Open exercise actions older than 90 days	Whether lessons are acted on	Few, each with an owner
Time to stand up the clean recovery environment	Readiness of the clean room	Tested at least once

Common failure patterns

Backups inside the blast radius: backup servers joined to the production domain or cloud backups administered by the same tenant administrators, so the attacker deletes them first.
Recovery times from vendor specifications: RTOs that were never tested become the basis of board reporting.
Containment without a restart order: systems are shut down correctly but nobody knows dependencies or restart order. Jaguar Land Rover's phased restart began more than five weeks after production stopped. See the Jaguar Land Rover cyberattack.
No tested manual workarounds: the business has no way to operate while systems are down. Marks and Spencer paused online orders for about two months and estimated a profit impact of around £300 million. See the Marks and Spencer cyberattack.
Restoring the attacker: images and backups restored without checking for persistence, or credentials not reissued after rebuild.
Supplier recovery assumed: managed service providers and SaaS platforms that hold critical data are expected to recover on the organisation's timetable, but their contracts say nothing about backup isolation, restore testing or recovery times. CISA recommends formalising backup requirements for third parties in contracts.
Identity left out of the plan: every runbook starts with "log in to the console", assuming the directory and administrator accounts still work.

Lessons from incidents

The 2025 UK retail and manufacturing attacks show the same maturity gaps. In both the Marks and Spencer and Jaguar Land Rover cases, the organisations took systems offline to contain the attack, and the length of disruption was set by how quickly they could rebuild in a trusted order and how well the business could run without systems in the meantime. Those are the minimum viable company, clean recovery and recovery testing dimensions. Both incidents also began with compromised identities, which is why identity recovery and the reissue of privileged and machine credentials sit in this model as their own dimension.

Practitioner checklist

Score each of the seven dimensions separately and report the lowest alongside the average.
Agree important business services and impact tolerances with business owners.
Make at least one copy of critical data immutable and unreachable with production credentials.
Fully restore every critical service once a year and record the actual time.
Design, build and exercise a clean recovery environment with its own identity.
Write down the minimum viable company with recovery order and exit criteria.
Store break-glass credentials, recovery keys and contacts offline.
Inventory service accounts, API keys and certificates that must be reissued after compromise.
Bring key suppliers into recovery exercises and contracts.

Cyber Resilience Maturity Model: Five Levels From Ad Hoc to Optimised