Most cybersecurity audits are audits of prevention. They test whether the doors are locked, whether the alarms are wired and whether anyone is watching the monitors, and they are necessary. They do not answer the question the board asks after reading about a competitor’s ransomware event: if this happened to us tomorrow, could we actually recover, and how long would it take? That is a different audit, with different evidence, and organizations that have passed years of security audits fail it routinely, because recovery capability is an emergent property of backups nobody has restored, dependencies nobody has mapped, decisions nobody has pre-agreed and exercises that never went wrong. This guide sets out the recovery-side assurance program: the ransomware scenario as the design case, immutable backup verification, crown-jewel recovery sequencing, decision authority under extortion, exercise realism, a twelve-test program, a recovery capability record template and a worked example at a food manufacturer whose backups sat on the same network as the systems they protected.
In this guide
- Resilience versus security: a different question
- The frameworks that describe recovery
- The ransomware scenario as the design case
- Immutable backup verification
- Crown-jewel recovery sequencing
- Decision authority under extortion
- Exercise realism
- The test program
- The recovery capability record
- Worked example: Brightwater Foods’ ransomware readiness assessment
- Reporting the answer: days against tolerance
- Common mistakes
- Related guides
Resilience versus security: a different question
Security asks whether an attack can be prevented or detected. Resilience asks what happens when it is not, and assumes that at some point it will not be. The assumption changes every test. A security audit of backups asks whether backups run and are encrypted; a resilience audit asks whether an attacker who has held domain administrator rights for days or weeks before detonating, which is how ransomware operators work, could have found and destroyed them, and whether the organization could restore from what survived, in what order, and how long the business could function meanwhile. A security audit of incident response asks whether the plan exists and the team is trained; a resilience audit asks who decides whether to pay, whether the decision can be made at 3 a.m. on a Saturday with the email system down, and whether the people who would make it have ever practiced it. The table sets the two side by side, and the point of it is that the second column is not a harder version of the first; it is a separate program.
| Area | Prevention audit asks | Resilience audit asks |
|---|---|---|
| Backups | Do backups run, succeed and get encrypted? | Could an attacker with admin rights delete or encrypt them? Has a full restore of the crown jewels been demonstrated, and how long did it take? |
| Identity | Is MFA enforced and privileged access controlled? | If the directory is compromised, how is it rebuilt or restored, and what can run without it? |
| Network | Is the network segmented and monitored? | Can the organization isolate segments in minutes, and communicate when corporate email and chat are gone? |
| Incident response | Is there a plan, a team and training? | Who has authority to shut down production, engage a negotiator, and pay or refuse to pay? Has the plan been run against a scenario that broke it? |
| Business continuity | Do plans and RTOs exist? | Which processes can operate manually, for how long, and has that been tried? Do the RTOs add up when 300 systems must be recovered in sequence? |
| Third parties | Are providers assessed and contracted? | If the provider is the one hit, what is the fallback, and if the organization is hit, which providers must be told and which will cut it off? |
| Evidence standard | Configuration, policy, sample of operation | Demonstration: restores performed, exercises run, decisions rehearsed, timings measured |
The frameworks that describe recovery
Recovery has its own literature, and the audit’s criteria come from it. NIST’s SP 800-160 Volume 2, Revision 1 (December 2021), on developing cyber-resilient systems, frames resilience as the ability to anticipate, withstand, recover from and adapt to adverse conditions, and supplies engineering techniques and design principles that translate into testable properties, such as segmentation, redundancy, diversity and the protection of backup and restoration capability. NIST CSF 2.0 (February 2024) carries the outcomes: PR.DS-11 on backups created, protected, maintained and tested; PR.IR on technology infrastructure resilience; the Respond function’s incident management and mitigation categories; and the Recover function’s two categories, incident recovery plan execution (RC.RP) and incident recovery communication (RC.CO), which the CSF 2.0 assessment method shows how to assess. Sector rules add hard requirements: the EU’s DORA requires response and recovery plans, backup policies with restoration and recovery procedures, segregated restoration systems and testing (Articles 11 and 12), as the DORA guide sets out; UK operational resilience rules required firms to set impact tolerances for important business services and to be able to remain within them by the end of the transition on 31 March 2025; and US banking supervisors expect recovery capability to be demonstrated, with the financial sector’s Sheltered Harbor initiative standardizing data vaulting for the case where a bank’s own systems are gone. The IIA’s Organizational Resilience Topical Requirement, effective 30 April 2027, will make recovery-side coverage a conformance matter for assurance engagements on resilience, and CISA’s Cross-Sector Cybersecurity Performance Goals, updated to version 2.0 in December 2025, supply a baseline of practices mapped to all six CSF functions, including recovery.
Two guides on this site carry the halves this program bridges. The business continuity and organizational resilience guide covers the business-side planning, impact tolerances and the Topical Requirement; the backup and recovery audit guide covers the technical backup controls in depth. Cyber resilience is where they meet, and the reason it needs its own program is that the cyber scenario breaks the assumptions of both: the continuity plan assumes the technology is available somewhere, and the backup program assumes the backup infrastructure itself survives.
The ransomware scenario as the design case
Ransomware is the design case for cyber resilience because it is the attack that is built to defeat recovery. A modern intrusion does not encrypt on entry. It obtains a foothold, escalates to domain or cloud administrator, spends days or weeks mapping the environment, exfiltrates data for a second extortion lever, locates the backup infrastructure and either encrypts it, deletes it or corrupts it quietly so that the retained copies are useless, disables security tooling, and then detonates across the estate, often at a weekend or a holiday. The organization wakes to an estate where the directory is untrustworthy, the hypervisors may be encrypted, the backup console is gone, the monitoring platform is blind, the email and chat systems are down, and the phone numbers for the people who matter are in the directory nobody can reach. Every recovery assumption that was made in a business continuity plan written for a flood or a fire fails at once.
The audit therefore starts from the scenario and works backward through dependencies. Recovery of any business system requires identity (a trustworthy directory or a rebuilt one), network (segments that can be isolated and re-established), the platform layer (hypervisors, storage, cloud accounts, PKI, DNS, time), the backup infrastructure (console, catalog, repositories, and the credentials to reach them, which must not be the same credentials the attacker holds), and communications (an out-of-band channel with pre-distributed contact details). Each of those is a crown jewel in its own right, usually missing from the business’s crown-jewel list because the business does not see them, and the audit’s first output is the dependency map that puts them there. The incident response audit guide covers the detection and containment half of the same event; this program takes over at the moment containment is achieved and the question becomes recovery.
Immutable backup verification
A backup is resilient to ransomware only if the attacker, holding the highest privileges in the environment, cannot alter or destroy it, and “immutable” is a claim that has to be tested rather than read from a product sheet. The audit verifies five things. The mechanism: object lock or write-once storage with a retention lock the administrator cannot shorten, an air-gapped or offline copy that is disconnected except during controlled windows, or a vault held by a separate provider with separate credentials; a copy that is merely on a different server is not immutable. The credential boundary: the backup system’s administrative credentials are not domain credentials, not stored in the domain-joined password vault the attacker would also hold, and protected by MFA that does not depend on the compromised directory; an auditor who can log into the backup console with a domain administrator account has found the finding. The retention arithmetic: the immutable retention is longer than the plausible dwell time plus the detection lag, so that a clean copy exists from before the intrusion, which usually means weeks rather than days. The scope: the immutable copies cover the crown jewels and their dependencies, including the directory, the backup catalog itself and the configuration of the platform layer, not just the file shares and databases the business named. And the restore: a full restore of a crown-jewel system from the immutable copy, performed to isolated infrastructure, timed, with the data integrity verified by the business, within the period, and observed by the auditor at least once. The backup and recovery audit guide carries the wider control set; the resilience program tests these five and does not accept a restore test that restored a file.
Crown-jewel recovery sequencing
Recovery time objectives are set per system, and an organization with three hundred systems and per-system RTOs of 24 hours has not thereby committed to recovering in 24 hours; it has committed to something it has never calculated. Sequencing is the calculation. It begins with the dependency map, which orders recovery from the foundation upward: identity and network first, then the platform layer, then the core transaction systems, then the data stores, then the applications and integrations, then the user-facing services, with the crown jewels identified at each layer. It continues with the resource constraint: how many systems the recovery team can rebuild in parallel with the people and the hardware it will have, which is far fewer than the plan assumes when the plan assumes everyone is available and the hardware is not encrypted. And it ends with the minimum viable business: the smallest set of systems and manual workarounds that lets the organization meet its most critical obligations, with the impact tolerance for each stated in hours or days and the demonstrated recovery time recorded beside the objective.
| Recovery tier | What it contains | Depends on | Objective | Evidence the audit wants |
|---|---|---|---|---|
| 0. Foundations | Out-of-band communications; clean-room infrastructure; backup console and repositories; privileged credentials held offline | Nothing inside the compromised estate | Available at hour zero | Contact directory held offline and current; clean-room capacity contracted or built; backup access tested from outside the domain |
| 1. Identity and network | Directory (restored or rebuilt), PKI, DNS, time; core network and segmentation; remote access for the recovery team | Tier 0 | Hours | Directory restore or rebuild demonstrated; segmentation playbook executed in an exercise |
| 2. Platform | Hypervisors, storage, cloud landing zones, container platforms, secrets management | Tiers 0 to 1 | Hours to a day | Platform rebuild from immutable configuration demonstrated |
| 3. Core transaction systems | ERP, core banking or processing platform, plant control, order management | Tiers 0 to 2 | Impact tolerance of the business service | Full restore from immutable copy, timed, data verified by the business |
| 4. Data and integrations | Data warehouse, interfaces, EDI, payment gateways | Tier 3 | Within the service tolerance | Interface re-establishment tested; counterparties’ re-connection procedures known |
| 5. User services | Email, collaboration, endpoints, portals | Tiers 1 to 2 | Days | Endpoint rebuild capacity calculated; portal restore tested |
| Manual workarounds | Processes that can run without the systems above, for a stated period | People, paper, phones | Bridges the gap to tier 3 | Workarounds exercised, not just documented; the period they can sustain stated |
The audit test is arithmetic and demonstration together: take the sequence, the demonstrated recovery time of each tier from the restore tests and exercises, and the parallelism the team can actually achieve, and compute the elapsed time to the minimum viable business. That number, compared with the impact tolerance the board has stated, is the audit’s headline, and it is usually the first time the board has seen the two side by side.
Decision authority under extortion
The decisions in a ransomware event are made under time pressure, with incomplete information, by people who have never made them, and the audit asks whether the organization has taken the decisions it can take in advance. Five decisions need a pre-agreed owner and a pre-agreed framework. Whether to shut down production or isolate systems, which loses revenue with certainty to prevent a loss that is uncertain, and which technical staff must be authorized to take without waiting for an executive. Whether to engage external incident responders, negotiators and counsel, under retainers arranged in advance, and how they are paid when the finance system is down. Whether to pay, which is a legal question before it is a financial one: the US Treasury’s Office of Foreign Assets Control has warned since 2020, and updated the advisory in September 2021, that payments to sanctioned actors can violate sanctions law regardless of the payer’s knowledge, that cooperation with law enforcement is a mitigating factor, and that facilitators including insurers and negotiators bear the same risk; the decision therefore involves counsel, the insurer, the negotiator’s sanctions screening and the board, and it should be documented as a framework with thresholds before the event, not improvised during it. Whom to notify and when, which is a matrix of regulators, customers, counterparties and insurers with clocks that start at discovery: a US public company’s SEC Form 8-K Item 1.05 disclosure within four business days of determining materiality; a New York-regulated financial institution’s 72-hour notice under NYDFS Part 500 and its 24-hour notice of an extortion payment; a DORA entity’s four-hour and 24-hour initial notification; state and national breach laws where personal data was taken. And what to say publicly, with the communications lead named and a holding statement drafted in advance.
The audit tests the framework’s existence, the pre-arranged retainers and their invocation procedure, the notification matrix against the organization’s actual obligations, and, most usefully, whether the decision-makers have rehearsed. A board that has walked through a pay-or-refuse decision in an exercise, with counsel in the room and the sanctions question on the table, makes a better decision at 3 a.m. than one reading the framework for the first time. The incident response audit guide covers the notification obligations in detail and the audit committee presentation template the form in which the readiness picture reaches the board.
Exercise realism
An exercise that has never failed has never been realistic. Recovery exercises exist to find the assumptions the plan makes without knowing it, and the audit evaluates exercises on whether they were designed to break something. Four levels of exercise prove different things, and a mature program runs all four on a cycle.
| Level | What happens | What it proves | Realism tests the audit applies |
|---|---|---|---|
| Tabletop | Decision-makers walk through a scenario with injects, in a room, over hours | Roles, decision frameworks, notification matrix, communications | Injects that remove assumptions: the directory is compromised, email is down, the backup console is encrypted, the CISO is unreachable, the attacker publishes data mid-exercise; the pay decision put to the board with counsel present |
| Functional | Technical teams execute specific playbooks: isolate a segment, invoke the clean room, restore a system from immutable backup | Playbooks work; timings measured; credentials and access outside the domain function | Performed without the primary administrator; performed from the out-of-band environment; timed against the objective; the restored system verified by the business |
| Full recovery test | Crown-jewel systems restored end to end to isolated infrastructure from immutable copies, with dependencies, in sequence | The sequencing arithmetic; the demonstrated recovery time to minimum viable business | Performed in the planned order; parallelism limited to the real team; data integrity confirmed; elapsed time compared to the impact tolerance |
| Manual workaround exercise | Business units run critical processes without the systems, for a defined period | The bridge holds for as long as the sequencing needs | Run for the full stated period, not an hour; volumes realistic; the backlog re-entry tested afterward |
Each exercise produces a report with the assumptions that failed and the actions raised, and the audit tests that the actions were closed before the next exercise and that the next exercise’s scenario did not quietly avoid the areas that failed last time. The most telling single question the auditor can ask is what the last exercise got wrong; an answer of “nothing” is a finding.
The test program
| # | Test | Method | Pass condition |
|---|---|---|---|
| 1 | Crown jewels and dependency map | Compare the business’s crown-jewel list with the technical dependency map; confirm the foundations (identity, network, platform, backup infrastructure, communications) are on it | Map complete, current, owned; foundations included |
| 2 | Impact tolerances | Inspect board-approved tolerances for critical business services | Stated in time, approved, mapped to systems |
| 3 | Backup immutability | Inspect mechanism, retention lock, credential boundary, scope; attempt deletion or retention shortening with administrative rights in a test | Immutable copies of crown jewels and foundations, unreachable with domain credentials, retention beyond plausible dwell |
| 4 | Full restore demonstration | Observe or inspect a full restore of a crown-jewel system from the immutable copy to isolated infrastructure within the period | Restore succeeded, timed, verified by the business; time within tolerance or gap reported |
| 5 | Directory recovery | Inspect the directory restore or rebuild procedure and its last test | Procedure exists, tested, with clean credentials held outside the domain |
| 6 | Clean room and out-of-band communications | Inspect the isolated recovery environment and the communication channel; test access without the corporate estate | Available, tested, contact directory current and held offline |
| 7 | Sequencing arithmetic | Recompute elapsed time to minimum viable business from demonstrated tier times and real parallelism | Computed time compared to tolerance; gap reported |
| 8 | Decision framework and retainers | Inspect the pay/isolate/notify framework, retainers and invocation procedures; inspect sanctions screening arrangements | Owners named, thresholds set, retainers current, counsel and insurer roles defined |
| 9 | Notification matrix | Compare the matrix to the organization’s actual obligations (regulators, contracts, insurers) | Complete, with clocks and owners |
| 10 | Exercise program | Inspect the cycle, scenarios, injects, reports and actions for the last two years | All four levels run; assumptions broken and actions closed; scenarios not avoiding prior failures |
| 11 | Manual workarounds | Inspect workaround procedures and the last exercise; test one with the business unit | Workarounds sustainable for the stated period; backlog re-entry tested |
| 12 | Third-party dependencies | For each crown jewel provided by a third party, inspect the provider’s recovery evidence and the organization’s fallback | Provider recovery demonstrated or fallback credible; contractual notification both ways defined |
The recovery capability record
One record per crown-jewel system or foundation, maintained by the recovery owner and used by the audit as the test template. Together the records are the sequencing plan with its evidence attached.
Recovery capability record
1. System or foundation. Name; recovery tier; business services it supports and their impact tolerances; owner (business) and recovery owner (technical); third-party dependency, if any.
2. Dependencies. Systems and foundations it requires to recover (identity, network, platform, data sources, interfaces); systems that depend on it.
3. Backup and immutability. Backup method and frequency; immutable copy mechanism and retention lock; credential boundary; last verification of immutability; scope confirmation (configuration and data).
4. Recovery procedure. Documented steps; target environment (clean room, alternate site, cloud); prerequisites; staffing and skills required; expected duration.
5. Demonstrated recovery. Last full restore date; environment used; elapsed time; data integrity verification by the business (who, how); issues found and fixed; auditor observation, if any.
6. Objective versus demonstrated. RTO and RPO; demonstrated recovery time and data loss; gap and the accepted risk or the remediation plan with dates.
7. Manual workaround. Process that runs without the system; period sustainable; last exercised; backlog re-entry method.
8. Sign-off. Recovery owner, business owner, dates; next demonstration due.
Worked example: Brightwater Foods’ ransomware readiness assessment
Brightwater Foods is the illustrative food manufacturer used across this site: about $180 million of revenue, 600 staff, three plants, a co-sourced internal audit function sponsored by the finance director. Its first cybersecurity assessment, described in the CSF 2.0 method guide, had found that recovery had never been demonstrated for the ERP or the plant historian and that the backups sat on the same network segment as the systems they protected, and the board asked for a recovery-focused follow-up before the next budget cycle. The engagement was scoped at 180 co-sourced hours and 40 internal, with the plant engineering lead and the IT manager as the counterparts, and it was built around a single question the finance director wrote on the planning memo: if all three plants stopped on a Friday night, when would we ship again?
The dependency map was the first output and the first surprise. The business’s crown-jewel list had five entries: the ERP, the three plant control networks and the customer EDI gateway. The technical map added the directory, the two cloud tenants, the hypervisor cluster that ran the ERP and the historians, the backup server, and the plant engineering laptops that held the only copies of several PLC programs. The backup review found nightly backups to a repository on the corporate network, administered with domain credentials, with 14 days’ retention and no immutable or offline copy; a restore of the ERP had never been performed in full, and the historian backups for two of the three plants had been failing for five weeks with the alerts going to a mailbox nobody read. The clean-room question had no answer, because there was no isolated environment and no plan to obtain one, and the contact list for an incident lived in the directory. The decision framework did not exist: nobody could say who would authorize a plant shutdown, and the cyber insurance policy’s conditions on notification and on the use of the insurer’s panel responders had not been read by anyone outside the broker.
| Area | Finding | Rating and action |
|---|---|---|
| Backup immutability | No immutable or offline copy; repository reachable with domain credentials; historian backups failing unnoticed at two plants | High: immutable cloud vault with separate credentials and 60-day retention lock; failed-backup alerts routed to a monitored queue; PLC programs backed up from the engineering laptops |
| Demonstrated recovery | ERP never restored in full; historian restore never attempted; PLC programs unrecoverable at one plant | High: full ERP restore performed to a rented isolated environment during fieldwork, 41 hours elapsed against a stated 24-hour objective; historian restore succeeded at 9 hours; the PLC gap closed by re-extracting programs from the controllers |
| Sequencing | No dependency map; per-system RTOs of 24 hours summing to an unplanned week; no minimum viable business defined | High: sequence agreed (directory and network, hypervisor, ERP, historians, EDI); minimum viable business defined as one plant on manual scheduling with paper picking within 48 hours; computed time to full recovery nine days, board tolerance stated at five |
| Decision authority | No framework; plant shutdown authority undefined; insurance conditions unread; no retainers | Medium: framework approved with the plant managers authorized to isolate, the CFO and counsel owning the pay decision, panel responders identified from the policy, sanctions screening via the negotiator |
| Communications | Contact directory only in the compromised-able directory; no out-of-band channel | Medium: printed and offline directory; a separate messaging channel provisioned and tested |
| Exercises | None ever run | Medium: first tabletop run during fieldwork with an “email is down and backups are encrypted” inject; two of the four decision-makers could not be reached by the means the plan assumed |
| Manual workarounds | Plant scheduling and picking on paper had been done informally during a 2024 outage; never documented or timed | Low: documented; exercised at one plant for a shift; sustainable for about three days before customer service degrades |
The report’s headline answered the finance director’s question: on the evidence, Brightwater would ship again from one plant on paper within about two days and would be fully recovered in about nine, against a board tolerance of five, and the gap was mostly the sequence and the parallelism, not the technology. The board accepted the nine-day figure as the current state, funded the immutable vault and the clean-room arrangement, and asked for the number to be re-measured in a full recovery test the following year. The single most valuable hour of the engagement, by the finance director’s account, was the tabletop, because it was the first time the executives had discovered that they could not reach each other.
Reporting the answer: days against tolerance
The report for this program has a shape the board has not seen from internal audit before, and it should keep it. The headline is a recovery curve: elapsed time on one axis, the share of critical business services restored on the other, drawn from demonstrated tier times and the real parallelism, with the board’s impact tolerances marked as lines the curve either crosses in time or does not. Beneath the curve sit the three or four assumptions the number depends on, each with its evidence: the immutable copy exists and was restored from; the directory can be rebuilt in the stated time; the clean room can be stood up; the team of a given size can work the sequence. Then the findings, ordered by their effect on the curve rather than by their control category, so that the board sees which investment moves the number most. And then the exercise record, because a board that has seen the curve will ask when it was last tested.
Two rules for the number. It is reported as the demonstrated figure, not the planned one: a nine-day recovery with evidence is more useful than a two-day recovery in a plan, and a board that is told two days and lives through nine will not trust the function again. And it is re-measured on a cycle, with the movement reported, because the value of the program is in the second and third measurements, when the investments made after the first can be seen in the curve. The finding severity ratings guide applies to the individual findings; the curve is the engagement conclusion, and it is written in days.
Common mistakes
Auditing recovery through documents: plans, RTOs and backup policies, without a restore, a timing or an exercise. Accepting a file-level restore as proof that a system can be recovered. Testing backups with the credentials an attacker would hold and not noticing. Treating the directory, the hypervisors and the backup console as infrastructure rather than as crown jewels. Adding up per-system RTOs as if recovery were parallel and unlimited. Letting the business continuity plan assume the technology is available. Leaving the pay decision to the night it is needed. Running exercises that have never failed, or scenarios that avoid last year’s failure. Forgetting the plant, the acquired unit or the provider-hosted system in the crown-jewel list. And reporting the findings as a list of controls rather than as the answer to the board’s question, which is a number of days against a tolerance. The Active Directory and Entra ID guide covers the directory recovery that most recoveries hinge on, the patch and vulnerability guide the prevention side that reduces how often this program is needed, and the Cybersecurity Topical Requirement workbook the requirement row (incident response and recovery) that a resilience engagement satisfies.
Related guides
- How to audit backup and recovery
- How to audit incident response
- Business continuity and organizational resilience
- NIST CSF 2.0 assessment: an internal audit method
- DORA for internal auditors
- How to audit Active Directory and Entra ID
- How to audit patch and vulnerability management
- The Cybersecurity Topical Requirement workbook
- Auditing cybersecurity programs
- Audit committee presentation template
- How to build the IT audit plan
Leave a Reply