#Chapter 12 — Resilience, Backup and Recovery

How to build a backup and recovery capability that survives an adversary who is specifically hunting it — immutable storage, credentials that live outside the domain you are restoring, restore tests with a stopwatch, and an identity-first recovery order.

Who needs this: CISO, Infrastructure Lead, Backup Administrator, Identity Team, BC/DR Owner, Incident Commander, CFO (insurance) | Read time: 24 min | Maps to: CSF 2.0 RECOVER (RC.RP, RC.CO), PROTECT (PR.DS, PR.IR, PR.AA), IDENTIFY (ID.AM), GOVERN (GV.RM, GV.OV) · CIS Controls 1, 5, 6, 11, 17 · ISO/IEC 27001 A.5.29, A.5.30 · ISO 22301

Cyber warriors, we need to talk about the slide.

You have it. Every organization has it. It says "Backups" with a green tick beside it, and it has survived four board meetings without a single follow-up question. Meanwhile, Mandiant's frontline investigators describe the defining ransomware shift of the current era as the move from data theft to recovery denial: operators now deliberately target backup infrastructure, identity services, virtualization management planes, AD CS certificate templates, and hypervisor datastores — attacking your ability to recover rather than only your ability to operate (M-Trends 2026). Your green tick is on their target list. It has been for years.

The numbers say this is winnable and expensive at the same time. Sophos found that 66% of organizations with encrypted data recovered from backups, up 12 points — and that the average recovery cost was $1.7M, up 11% (Sophos State of Ransomware 2026). Two thirds get their data back. It still costs seven figures. The gap between those two facts is made almost entirely of things this chapter covers: how long the restore took, whether the identity plane came back before the applications, and whether anyone had ever actually done it before the day it mattered.

We have spent a decade getting good at detection and containment and left recovery as an IT infrastructure chore. CISA's own federal incident response playbook devotes roughly four bullets to the entire recovery phase (CISA Playbooks). The British Library put the correction plainly in its own post-incident review: "Prioritize recovery alongside security… Investment in security needs to be balanced against investment in back-up and recovery capabilities" (British Library cyber incident review).

This chapter is that balancing. Chapter 14.1 contains the ransomware response playbook itself; what follows is the capability that playbook assumes exists.

#1. Immutability as the providers actually implement it

"Immutable backup" is a phrase four different vendors will happily sell you, meaning four different things, two of which a compromised administrator can undo in about nine seconds. Precision here is the difference between having a copy and thinking you have one.

AWS S3 Object Lock (docs) requires S3 Versioning, and retention and legal holds apply per object version — they do not prevent new versions or delete markers being created. In compliance mode, "a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account… its retention mode can't be changed, and its retention period can't be shortened"; the only route to early deletion is closing the account. In governance mode, any principal holding s3:BypassGovernanceRetention can override by sending the x-amz-bypass-governance-retention:true header — and the S3 console includes that header by default. Governance mode plus a console-capable admin is not immutability; it is a speed bump with good branding. Legal hold is separate again: no expiry, independent of retention, set and cleared via s3:PutObjectLegalHold.

AWS Backup Vault Lock (docs) is the vault-level equivalent. Governance mode is removable by anyone with sufficient IAM permissions. Compliance mode has a grace time (ChangeableForDays, minimum 3 days, maximum 36,500) after which "the vault and its lock are immutable and cannot be changed or deleted by any user or by AWS."

# Lock a backup vault in COMPLIANCE mode. After --changeable-for-days elapses,
# neither you nor AWS can shorten retention or delete the vault.
# Omit --changeable-for-days for GOVERNANCE mode: no grace period, and removable
# by any sufficiently privileged IAM principal.
aws backup put-backup-vault-lock-configuration \
  --backup-vault-name my_vault_to_lock --changeable-for-days 3 \
  --min-retention-days 7 --max-retention-days 30

# Works only during the grace window; after LockDate this returns an error.
aws backup delete-backup-vault-lock-configuration --backup-vault-name my_vault_to_lock

Verify with DescribeBackupVault and confirm "Locked": true plus the LockDate at which grace ends. Three AWS-documented footguns belong in your runbook, not in a support ticket at 04:00: a recovery point with retention set to "Always" becomes permanently un-deletable once grace expires; closing the AWS account deletes vault contents after 90 days even with Vault Lock in place; and ec2:DisableImage can render an EC2 recovery point unrestorable even inside a locked vault or under legal hold — deny that action explicitly in your SCP.

Azure (immutable vault, immutable blob storage, soft delete and immutability advancements) implements vault immutability as two states, Enabled and Locked, with the Enabled → Locked transition one-way. Once locked, no user regardless of privilege can delete recovery points before retention expires or disable immutability. Soft delete is on by default for all vaults. Azure also adds multi-user authorization (MUA): disabling immutability or soft delete requires approval from a separate security administrator — the control that specifically defeats a single compromised privileged account, which is statistically the account your attacker will be holding. Azure Blob immutable storage supplies the WORM primitive via time-based retention policies and legal holds (indefinite until explicitly cleared).

Veeam Hardened Repository (user guide, Veeam blog, best practices) is a Linux server holding backup files immutable for a configured period, deployed with single-use credentials used once to install the Veeam Data Mover and not stored in the backup infrastructure — so compromising the Veeam Backup & Replication server does not hand the attacker credentials to the repository. Recommended hardening includes disabling SSH.

The cheap version. S3 Object Lock in compliance mode costs storage, not license — there is no immutability SKU. A single bucket in a separate AWS account with versioning on, compliance-mode object lock, a lifecycle policy and a cross-account replication rule from production takes an afternoon and costs the price of the bytes. If you are a 60-person company with no backup vendor, that is your control. Build it this quarter.

Actionable takeaway: For every backup repository you own, write down which mode in the table above it is actually in — not which one it was procured as. Any repository in an overridable mode gets a dated migration plan to the non-overridable mode this quarter, or a signed risk acceptance naming the executive who owns the outcome.

#2. Isolated credentials: the single most common recovery failure

Here is how a bad week becomes a bad quarter.

An adversary lands via a phished session token — 79% of ransomware attacks began with an identity-based approach (Sophos) — escalates to Domain Admin, and spends a few days quietly enumerating. They find the backup server. It is domain-joined. Its console authenticates via SSO against the same directory they now own. They log in as an administrator, delete the retention policies, purge the repository, then deploy the encryptor. When your team arrives, the backups are gone and the account you would use to check is also gone, because the directory that issued it is encrypted.

That is not an exotic attack. It is the default outcome of the default architecture, and it is why CISA's ransomware guidance insists backups be kept offline: "it is important that backups are maintained offline, as most ransomware actors attempt to find and subsequently destroy them" (CISA Ransomware Guide). Offline is one way to break the trust relationship. Isolated credentials are the other, and they scale better. Generalised, this is the load-bearing sentence of the chapter:

Backup infrastructure must not authenticate against the identity provider it exists to recover.

If your backup console uses AD or Entra SSO and the domain is encrypted, you cannot log in to restore the domain. AWS Backup Vault Lock and Azure MUA are built around the same insight from the other direction: a single compromised privileged identity in the production tenant must not be able to destroy the backups.

The practical rules:

Rule 7 is the one everyone skips and the only one that proves the other six. A restore performed by an engineer already logged into the domain proves nothing about the day the domain is gone.

The cheap version. Trust-domain separation does not need a second data centre. A separate cloud account with its own root credential, its own MFA token in a physical safe, and no trust relationship to production costs nothing plus storage. On-premises, a repository server that is not domain-joined, with a local account whose password lives on paper in a safe, is free. Both beat a domain-joined appliance with an enterprise support contract.

Actionable takeaway: Today, answer one question in writing: if the production directory is encrypted right now, which specific credential logs into the backup console, where is it stored, and who has physically held it in the last 90 days? If the answer involves the word "SSO," you do not have backups. You have copies the attacker also controls.

#3. Restore testing on a cadence, with a stopwatch

An untested backup is not a control. It is a belief system with a storage bill.

The distinction that matters: backup job success is an input metric; time-to-restore is the outcome metric. Every backup product reports the first one beautifully. Almost none report the second, because the second requires you to actually do the restore.

#A testing rubric

Five tiers, each proving something the tier below it does not.

T4 and T5 are the two that fail in practice, and the two nobody schedules. Schedule them like an audit — a date, a named owner, a calendar hold, and a result that goes in the risk register whether it is good or bad. Chapter 18 covers exercise design; a T5 drill is a functional exercise in NIST SP 800-84 terms, not a tabletop, and must not be run as one.

#The metrics to track

Two honesty rules, borrowed from Chapter 16. First, measured TTR must include the boring parts — ticket approval, someone finding the credential, the network team opening a path, the application owner confirming the data is right. A restore that "takes 40 minutes" but needs six hours of coordination to start has an RTO of nearly seven hours. Second, a test aborted for a scheduling conflict is a failed test, not a deferred one. Attackers also create scheduling conflicts.

Actionable takeaway: Put a stopwatch on your next restore. Not an estimate — a stopwatch, started when someone says "restore it" and stopped when a business owner says "this is correct." Publish that number next to the RTO you have been claiming. If they disagree, the RTO is fiction and the roadmap item writes itself.

#4. RTO and RPO that mean something

RTO and RPO belong to business continuity — ISO 22301 is their proper home, and where business impact analysis, recovery objectives and continuity strategy live. ISO/IEC 27001's A.5.29 (Information security during disruption) and A.5.30 (ICT readiness for business continuity) are deliberately thin: they point at continuity without specifying it (Annex A structure). Use 22301 for the continuity plan and 27035 for the incident plan, and make the handoff explicit.

Three failure modes turn documented objectives into fiction:

1. Objectives without dependency ordering. Your ERP has a four-hour RTO. Its database has a four-hour RTO. The identity provider both authenticate against has no stated RTO because nobody thought of it as a business service. In a domain-wide event the ERP's real RTO is identity plus database plus ERP, sequentially. Per-system objectives that do not compose along the dependency graph are arithmetic nobody has checked.

2. No pre-defined critical asset list. CISA's ransomware guidance says to prioritize restoration "using a predefined list of assets essential to health, safety, revenue, or operations" (CISA — I've Been Hit By Ransomware). Predefined. Built during the incident, that list comes from the loudest voice on the bridge, and the loudest voice is rarely attached to the most critical system. Rafeeq Rehman's CISO MindMap says the same thing in its ransomware branch (rafeeqrehman.com): identify critical systems, perform a ransomware BIA, tie it to BC/DR plans.

3. RPO set without reference to when encryption happens. Sophos found 88% of ransomware encryption occurred outside business hours (Help Net Security on Sophos). A backup completing at 23:00 against an encryptor running at 02:00 gives you roughly the RPO you claim. A backup window that starts at 01:00 may be writing your last good copy while the encryption runs — which is how organizations discover their three most recent restore points are all encrypted.

A workable tiering:

Note what T0 does to the arithmetic: no T1 objective is achievable independently of the T0 objective, which is why identity gets its own tier rather than sitting inside T1.

Actionable takeaway: Take your three most critical business services and draw their full dependency chain down to the identity provider, DNS and the secrets store. Sum the RTOs along that chain. That sum — not the number in the BIA spreadsheet — is what you can promise a regulator, a customer, or a board.

#5. Identity-first recovery: the order, and why each step precedes the next

The event that shaped this discipline is Maersk/NotPetya: essentially every online domain controller and its online backups were destroyed, and recovery reportedly depended on a single domain controller in Accra, Ghana that happened to be offline during a local power cut. Maersk's CISO has been quoted saying nine days for an Active Directory recovery is not good enough and organizations should aspire to 24 hours — because until identity is back, nothing else can be repaired (Dark Reading, Semperis).

The authoritative sequence is Microsoft's AD Forest Recovery guidance (perform initial recovery, steps for restoring the forest). Restore the forest root domain first — "always recover a parent domain before recovering a child to prevent any break in the trust hierarchy or DNS name resolution" — and one writeable DC per domain. The abbreviated sequence, with the reason each step gates the next:

Plan a full user password reset if user accounts may be compromised. If a restored DC holds an FSMO role, temporarily set HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations to REG_DWORD 0.

The full-stack order that follows from this:

clean network and out-of-band communications → identity (AD / Entra) → DNS, DHCP, PKI, NTP → certificate and secrets infrastructure → core file and database services → applications → user data → endpoints

The reason is dependency, not preference. Services restored before identity come up authenticating against something that is not yet trustworthy — and every one of them will need re-doing, or worse, will silently accept credentials the attacker still holds.

Actionable takeaway: Print the sequence above, walk it with your identity team against a real backup in an isolated network, and record where you got stuck. Every organization gets stuck somewhere — usually DNS at step 8 or the RID pool at step 9. Finding out which is yours costs a day now and saves a week later.

#6. Clean room recovery: what "clean" means and how you prove it

A clean room — an Isolated Recovery Environment (IRE) — is a separate, network-isolated environment into which backups are restored, scanned and validated before anything is trusted in production (Broadcom — What is an IRE / Clean Room?). It is a quarantine ward, and it exists because modern ransomware operations leave persistence behind: restoring straight from backup into production reintroduces the intrusion you just spent a week evicting.

Four properties separate a real clean room from a slide with a padlock icon:

1. Separate infrastructure — not a VLAN on the same hypervisor cluster whose management plane the attacker may hold.
2. Separate credentials — the out-of-band credentials from §2, not the production IdP.
3. No routed path back to production until validation passes, and the path is opened by an explicit, logged action.
4. Its own clean tooling — EDR, AV, integrity checking, all installed from known-good media, not restored from the same backup you are validating.

Microsoft's AD forest recovery procedure is a clean-room procedure — restore in isolation, validate, then connect — which is why steps 1 and 4 above are non-negotiable.

How you prove "clean." You cannot prove a negative, so define the standard you are actually meeting and write it down:

• Restored systems scanned with current signatures and behavioral detection, from tooling installed post-restore.
• Persistence surfaces enumerated and compared against a known-good baseline: scheduled tasks, services, run keys, WMI subscriptions, startup items, local accounts, SSH authorized_keys, cron.
• The initial access vector identified and closed — CISA's gating precondition for eradication is that "all means of persistent access into the network have been accounted for" (CISA Playbooks).
• Restore point chosen from before the earliest confirmed adversary activity, not before the encryption event. Dwell time is measured in days to months; encryption is the end of the intrusion, not the start.
• Enhanced monitoring on restored systems for a defined period, with an owner. CISA requires "enhanced vigilance and controls in place to validate that the recovery plan has been successfully executed and that no signs of adversary activity exist in the environment," and suggests considering an independent test or review.

The cheap version. A clean room needs no second site and no recovery-as-a-service contract. A spare host or a small isolated cloud VPC with no route to production, a switch port on its own VLAN with the uplink physically disconnected, a USB drive of installers, and a printed validation checklist gets you all four properties. What you cannot substitute is the discipline — the moment someone opens a firewall rule "just to get the agent talking to the console," the clean room stops being one.

Actionable takeaway: Write the promotion criteria before you need them: the enumerated checks a restored system must pass before it is allowed a route to production, and the named role that signs off. Criteria invented mid-incident are always the criteria the schedule can afford.

#7. Ransomware recovery is identity and endpoints, not just data

The most common scoping error in resilience planning is treating recovery as a data problem. Data is the part your backup vendor sells you. It is also, on most incidents, not the constraint.

Identity is in scope. Everything in §5, plus the certificate authority and AD CS templates (named by Mandiant as a deliberate target), the secrets vault, MFA registration state, Conditional Access or policy configuration, service principals, and federation trusts. If your PKI is compromised, every certificate it issued is suspect and every mutual-TLS dependency in the estate becomes a recovery task. Chapter 4 owns the identity controls; this chapter owns the fact that the identity plane needs a backup and a tested restore of its own, exactly as a database does.

Endpoints are in scope, and they are usually the long pole. After the servers are back, several thousand workstations still need reimaging, re-enrolling, re-encrypting and returning to users. CISA's guidance is to reimage from clean "gold" sources, rebuild systems from scratch, and rebuild hardware where rootkits are involved (CISA Playbooks). Three numbers determine your real endpoint RTO, and almost nobody has measured them:

• Imaging throughput — devices per hour, per technician, per site, with the imaging infrastructure also rebuilt.
• Enrolment throughput — how fast your MDM or configuration manager can re-enrol devices once identity is back, and whether it can do so at all if it was itself domain-joined.
• Physical logistics — for a distributed or remote workforce, whether the device comes to a technician or a technician goes to the device.

Multiply devices by rate and you get a number in weeks. That number belongs in the BIA, and it is the honest input to any conversation about how long the manual fallback procedures in §8 must be sustainable.

Third-party and SaaS dependencies are in scope. If a SaaS platform authenticates through your federated identity, restoring your directory is a precondition for restoring that service, and the vendor's own RTO is irrelevant until you get there. Chapter 11 covers vendor risk; the resilience question is narrower: which vendors can you not reach with your identity plane down, and does any of them have a break-glass path that does not route through it?

Actionable takeaway: Add the three lines most recovery plans are missing — the tested restore procedure for the identity plane, the measured device-per-hour reimaging rate, and the list of third-party services unreachable until federation is restored. If you cannot fill in the numbers, that is the finding.

#8. Business continuity: operating while the recovery runs

Recovery takes days. The business does not stop for days. The gap between those two facts is business continuity, and it is where the security team most often hands a technically excellent recovery plan to an organization that has no idea how to invoice a customer without the ERP.

Manual fallback procedures are the answer, and they must exist on paper before the incident: an actual document, per critical business process, saying how it runs without its system — paper forms, a phone number, a pre-agreed spreadsheet template, a manual authorization threshold. Two properties make them real. First, they are printed or otherwise reachable when the network is down; the British Library, with website and intranet down, fell back to social media and WhatsApp/email cascades (British Library review), and CISA's playbook requires infrastructure "in place to handle complex incidents, including classified and out-of-band communications," plus segmenting and managing SOC systems separately from broader enterprise IT so defensive systems stay operational during an attack. Second, someone has done them at least once — a manual process never executed has unknown throughput, and throughput is the whole question when it must carry a week of business volume.

CISA is equally explicit on communications discipline: isolate systems in a coordinated manner and "use out-of-band communication methods such as phone calls to avoid tipping off actors that they have been discovered" (CISA — I've Been Hit By Ransomware). That applies to recovery coordination as much as containment. Your recovery bridge must not run on the platform you are restoring.

Who decides to invoke. This is the seam between the incident plan and the continuity plan — between ISO/IEC 27035 and ISO 22301 — and it is almost never documented. Make it explicit:

The third row does not sit with security. Deciding to run payroll on paper is a business decision made by the person accountable for payroll. The security team's job is to tell them, accurately and early, how long the outage will be — which is why the measured TTR numbers from §3 matter far outside the SOC.

Actionable takeaway: Pick your highest-revenue business process and write its one-page manual fallback this month — who does what, on what form, with what authorization limit, at what throughput. Then have the owning team run two hours on the paper version. Two hours is cheap. Five days of improvisation is not.

#9. Cyber insurance: what it does, and how you accidentally void it

Rehman's CISO MindMap places Cyber Risk Insurance under Incident Management (rafeeqrehman.com), and that placement is correct in a way most organizations discover the hard way: insurance is not a finance product in a drawer, it is an operational dependency with clocks and constraints that bind your responders.

Four things about the policy affect what your team may do at T+2 hours.

1. The notification clock, which is not a statutory one. Cyber insurance policies typically require notice "as soon as practicable" and can deny coverage for late notice. That sits inside a broader pattern: contractual clocks routinely beat regulatory ones — BAAs compress HIPAA's 60 days to 5–15 days, customer MSAs increasingly demand 24–48 hour notification — and these are usually the first deadlines you actually miss.

2. Panel vendors and consent. Carriers commonly maintain approved panels of incident response, forensic and legal providers, and engaging a non-panel firm without consent can affect reimbursement. The practical failure: your team calls the DFIR firm you hold a retainer with at hour two, because that is the sensible engineering decision — and the carrier later declines the invoice. Resolve this in peacetime. If your preferred IR firm is not on the panel, negotiate the exception at renewal and get it in writing.

3. Evidence preservation versus speed. CISA's federal playbook does not address this at all: it contains no carrier notification step, no panel-vendor constraint, and no coverage-preservation steps — which frequently conflict with "reimage immediately." The carrier's forensic requirements may demand images and artefacts your instinct is to destroy in the rush to restore. Chapter 13 owns evidence handling; the resilience rule is simply capture before you reimage, even when the reimaging is urgent, and record who authorized each deviation.

4. The ransom decision runs through the insurer and through counsel. OFAC's advisory applies strict liability — a US person can face civil penalties for a sanctions-nexus transaction "regardless of intent or knowledge" — and is aimed explicitly at financial institutions, cyber-insurance firms, and forensic and incident response firms, not just victims (OFAC Updated Advisory). NCSC's guidance is that the decision is ultimately the victim's, but that organizations should consult external experts including the insurer, record decision-making offline or on unaffected systems, and investigate root cause first (NCSC guidance). Chapter 15 owns the payment decision tree and sanctions screening in full.

That last item deserves emphasis. Underwriting questionnaires now routinely ask whether you have immutable backups, MFA on privileged and remote access, and tested recovery procedures. Answering "yes" about a control you do not have in the state described in §1 is a representation to an insurer. Discovering at claim time that it was governance mode rather than compliance mode is a conversation nobody wants.

Actionable takeaway: Pull your policy this week and put four things on one page: the notification requirement, the panel-vendor consent process, the business-interruption waiting period, and every control you attested to at underwriting. Then verify each attested control is true today. Not "was true when we filled in the form." Today.

Resilience is the only security control your customers experience directly — everything else is invisible when it works, while recovery is visible precisely when it doesn't. The organizations that come through a domain-wide event in days rather than months are rarely the ones with the best detection. They are the ones where somebody, in a quiet week eighteen months earlier, restored a domain controller into an isolated network using a credential from a sealed envelope, wrote down how long it took, and then fixed the part that was slow.

Lock the vault, keep the keys somewhere the domain can't reach, and restore something on purpose before something restores you by force.

#Chapter checklist

Tags reference NIST CSF 2.0 categories, CIS Critical Security Controls v8.1 numbers, and ISO/IEC 27001:2022 Annex A controls. Broader ransomware preparation guidance sits in the CISA #StopRansomware Guide.

• RES-01Every backup repository is documented with its exact immutability mode (compliance/governance, Locked/Enabled), and no repository holding a last-resort copy is in a mode a sufficiently privileged principal can override. [IG1] [PR.DS] [CIS 11]
• RES-02At least one copy of every T0 and T1 asset exists in a repository where retention cannot be shortened, nor the copy deleted, by any account in the production identity domain. [IG1] [PR.DS] [CIS 11]
• RES-03Backup and recovery systems authenticate using dedicated credentials that do not depend on the production identity provider, and those credentials are stored offline. [IG1] [PR.AA] [CIS 5]
• RES-04The offline backup credentials have been physically retrieved and used in a restore test within the last 12 months, with the retrieval logged. [IG2] [RC.RP]
• RES-05No account is simultaneously a member of a production privileged group and a backup administrator group, verified by an automated check rather than assertion. [IG2] [PR.AA] [CIS 6]
• RES-06Destructive backup operations — shortening retention, disabling immutability, removing a legal hold, deleting a vault — require multi-person approval, enforced by the platform wherever the platform supports it. [IG2] [PR.AA]
• RES-07Backup vaults for cloud workloads reside in a separate account, subscription or project from the production workloads they protect, with a distinct break-glass path. [IG2] [PR.IR]
• RES-08A predefined list of assets essential to health, safety, revenue or operations exists, is owned by a named role, and is reviewed at least annually. [IG1] [ID.AM] [CIS 1]
• RES-09Every T1 service has a documented RTO and RPO derived from a business impact analysis, with its dependency chain down to identity, DNS and the secrets store documented. [IG2] [ID.AM] [A.5.30]
• RES-10Time-to-restore is measured from restore authorization to business-owner verification, recorded per test, and compared against the stated RTO. [IG2] [RC.RP]
• RES-11Restore testing runs on a documented cadence covering all five tiers (file, full system, application-consistent, identity plane, clean-room drill), and an aborted test is recorded as a failure. [IG2] [RC.RP] [CIS 11]
• RES-12An identity-plane restore — one writeable domain controller or the IdP configuration into an isolated network — has been successfully executed within the last 12 months. [IG2] [RC.RP]
• RES-13A documented, step-ordered identity-first recovery procedure exists, covering forest-root-before-child ordering, authoritative SYSVOL restore on the first DC only, Tier-0 credential and gMSA reset before additional DCs are installed, the RID pool raise, and the double krbtgt reset with at least 10 hours between resets. [IG2] [RC.RP]
• RES-14The full-stack recovery order (network and out-of-band comms → identity → DNS/DHCP/PKI/NTP → secrets → core data services → applications → user data → endpoints) is documented and has been walked with the teams who would execute it. [IG2] [RC.RP]
• RES-15A clean-room / isolated recovery environment is defined with separate infrastructure, separate credentials, no routed path to production before validation, and its own independently installed security tooling. [IG3] [RC.RP]
• RES-16Written promotion criteria specify the checks a restored system must pass before it is granted a route to production, name the role authorized to sign off, and require a restore point predating the earliest confirmed adversary activity rather than the encryption event. [IG2] [RC.RP]
• RES-17The identity plane — directory, PKI/AD CS, secrets vault, MFA registration state, policy configuration — is backed up and covered by a tested restore procedure separate from application data. [IG2] [PR.AA] [RC.RP]
• RES-18Endpoint recovery capacity is measured (devices reimaged and re-enrolled per hour, per technician, per site) and that measured rate is reflected in the business impact analysis. [IG2] [RC.RP]
• RES-19Manual fallback procedures exist in printed or offline-accessible form for every T1 business process, each with a named process owner and a documented invocation authority. [IG1] [A.5.29]
• RES-20At least one manual fallback procedure has been executed as a live drill within the last 12 months, with observed throughput recorded. [IG3] [A.5.29]
• RES-21Recovery coordination uses an out-of-band communications channel and a printed contact list that do not depend on the systems being restored. [IG1] [RC.CO]
• RES-22The cyber insurance notification requirement, panel-vendor consent process, business-interruption waiting period, and every control attested to at underwriting are extracted onto a single page held with the IR plan. [IG1] [GV.RM]
• RES-23Every control attested to on the most recent cyber insurance application has been verified as true in its current implemented state, with evidence, and any divergence reported to the broker. [IG2] [GV.OV]
• RES-24The board receives, at least annually, the date of the last tested identity-first restore and its measured time-to-restore against the stated recovery objective. [IG2] [GV.OV] [RC.RP]

#Sources

1. AWS — S3 Object Lock
2. AWS — AWS Backup Vault Lock
3. Microsoft — Immutable vault for Azure Backup
4. Microsoft — Immutable storage for Azure Blob data
5. Microsoft Tech Community — Enhanced security for Azure Backup: soft delete and immutability
6. Veeam — Hardened Repository (user guide)
7. Veeam — Immutable backup solutions: Linux hardened repository
8. Veeam — Hardened Linux repository best practices
9. Microsoft — AD Forest Recovery: perform initial recovery
10. Microsoft — AD Forest Recovery: steps for restoring the forest
11. CISA — Eviction Strategies Tool, CM0050 (krbtgt reset)
12. Broadcom / VMware — What is an IRE / Clean Room?
13. CISA — I've Been Hit By Ransomware!
14. CISA — #StopRansomware Guide
15. CISA — Ransomware Guide
16. CISA — Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (PDF)
17. Google Cloud / Mandiant — M-Trends 2026
18. Sophos — State of Ransomware 2026
19. Help Net Security — Sophos: identity-driven breaches report
20. British Library — Cyber incident review, 8 March 2024
21. Dark Reading — Maersk CISO on NotPetya
22. Semperis — US indictment of Sandworm highlights the importance of protecting Active Directory
23. OFAC — Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments
24. NCSC — Guidance for organizations considering payment in ransomware incidents
25. NIST — Cybersecurity Framework 2.0 (CSWP 29)
26. CIS — CIS Critical Security Controls list
27. ISMS.online — ISO/IEC 27001 Annex A control structure
28. Rafeeq Rehman — CISO MindMap 2026