Cyber Recovery Vault Guide: Isolated, Immutable Recovery for Ransomware

Ordinary backups are designed for failed disks and deleted files, not for an attacker who holds domain admin, cloud admin and the backup console at the same time. A cyber recovery vault is a separately governed environment that holds a protected copy of the data and configuration needed to rebuild critical services, plus the means to verify and restore it, when production and its backups can no longer be trusted. This guide covers vault architecture (physical, operational and logical air gaps), what to put in the vault, clean room recovery, sector schemes such as Sheltered Harbor, the NIST SP 1800 data integrity guides, and how to test and measure a vault. It is written for infrastructure and resilience architects, CISOs and business continuity owners deciding whether and how to build one. Immutable storage settings are covered in the Backup Security and Immutable Backup Guide and product selection in the Backup and Cyber Recovery Buyer's Guide.

Key takeaways

• A vault is a recovery capability, not a storage tier. It combines an isolated copy, independent identity, integrity checking and a place to restore into; missing any one of these leaves you with an expensive archive.
• Isolation has three layers. Network (air gap), control plane (separate administration) and data (immutability). Attackers with valid admin credentials defeat any vault that relies on only one.
• Vault the minimum viable business, not everything. Scope by critical services and their dependencies, starting with identity, DNS, PKI and the configuration needed to rebuild.
• Recovery happens in a clean room. Restored systems must be scanned and validated in an isolated environment before reconnecting, or you restore the attacker with them.
• Only full rehearsals prove it. Measure time to a known good copy and time to a working critical service, not backup job success.

What a cyber recovery vault is and how it differs from backup

Disaster recovery assumes the primary site is lost but the data and identities are trustworthy. Cyber recovery assumes the opposite: the infrastructure may still be running, but the attacker controls it, has been present for an unknown period and may have corrupted or encrypted backups. The NIST NCCoE data integrity series frames this as three tasks: identify and protect assets (SP 1800-25), detect and respond (SP 1800-26), and recover so that organisations can "trust the accuracy and precision of the recovered data" (SP 1800-11).

Replication to a DR site faithfully copies encryption and deletion, so it is not a vault. Same-account snapshots share the production control plane, so they are not a vault either.

Air gap models

The NCSC's offline rule is "never having all backups connected (or 'hot') at the same time", and for cloud storage that cannot be unplugged it says you can "deny connection requests while the storage is not in use ('cold')". Vault designs implement this in three ways.

• Operational air gap in practice: vendors describe it as a separately governed environment with "its own controls, credentials, and management plane", where the replication interface is enabled from inside the vault and disabled outside the window. The key test is that nothing outside the vault can open the link.
• Logical air gap in practice: an AWS Backup logically air-gapped vault is always locked in compliance mode, stores backups in an AWS Backup service-owned account, and can be shared through AWS Resource Access Manager only to named account IDs, which can restore but not copy. Google Cloud backup vaults enforce a minimum retention from 1 day to 99 years during which backups "can't be manually deleted" by administrators or by Google.
• Combining models: many organisations pair a logical cloud vault for fast restore with a physical copy of the smallest critical set, so that a cloud identity compromise or provider issue still leaves an independent route back.

Designing the vault: isolation layers

• Network: no inbound path from production; outbound only for the replication window or managed service endpoints. No shared management VLANs, jump hosts or monitoring agents that reach into the vault from production.
• Identity and control plane: vault administrators exist only in the vault's own directory, forest, cloud organisation or tenant, with phishing-resistant MFA and multi-person approval for destructive actions. AWS Backup multi-party approval, for example, places an approval team in a separate recovery organisation that uses its own IAM Identity Center. See the Backup Identity Isolation Guide.
• Data immutability: compliance-mode or locked retention so that even vault admins cannot shorten it. Set retention longer than your assumed attacker dwell time, so at least one copy predates the intrusion.
• Keys: encryption keys held in the vault or a recovery-only account. AWS recommends a customer managed key for a logically air-gapped vault come from "a separate recovery-dedicated account"; a key the attacker can schedule for deletion is a ransom lever. See the Cryptographic Key Management Guide.
• Time: retention locks depend on clocks. Protect the vault's time source from manipulation, since rolling time forward could otherwise expire retention early.
• Monitoring that survives: vault alerts and logs should reach responders through a channel that does not depend on the production email or chat tenant.

What to put in the vault

Scope from the business impact analysis: the services you must restore first to stay solvent, safe and compliant, and everything they depend on. CISA's #StopRansomware Guide asks organisations to maintain "offline, encrypted backups of critical data", to maintain and update "golden images" of critical systems, and to "keep backups of template files offline to quickly redeploy resources".

Data with no business priority does not belong in the vault; it raises cost and slows the search for a clean copy. The JADEPUFFER agentic ransomware case shows the end state without one: an AI agent encrypted 1,342 Nacos configuration items and dropped entire databases using a key that was generated randomly and never stored, so the data could not be recovered even by paying. Only an independent copy outside the compromised environment would have helped.

Clean room recovery

A clean room (also called an isolated recovery environment) is where vaulted data is restored, inspected and rebuilt before anything returns to production. CISA's guidance is to restore on "a clean network", by priority of critical services, and to "take care not to re-infect clean systems during recovery". The NCSC adds that backups should be "only connected to known clean devices before starting recovery" and scanned first, because malware may have been backed up during the attacker's dwell time.

1. Declare and isolate: invoke the cyber recovery plan through incident response; keep the vault link closed while forensics establishes the intrusion window.
2. Select a candidate copy: choose the newest copy older than the earliest known attacker activity. Use integrity analytics and indicators of compromise to check it.
3. Restore tier 0 into the clean room: identity, DNS and PKI first, on isolated compute and network with no route to production.
4. Validate: scan with current signatures and incident indicators, check for persistence (scheduled tasks, new accounts, altered group policy), compare configuration against known good baselines, and verify data integrity as NIST CSF 2.0 RC.RP-03 requires before use.
5. Reset credentials: rotate all privileged, service and machine credentials in the restored environment, including krbtgt twice for Active Directory, before reconnecting anything.
6. Rebuild critical services: in dependency order from golden images and IaC, restoring only data from backups where possible.
7. Promote: move validated services into a clean production network, with monitoring in place, and confirm normal operation (RC.RP-05).

Clean rooms can be standing (pre-built, cost always incurred, fastest), on-demand in cloud (built from IaC when declared), or hybrid. See the Cloud Recovery and Clean Room Guide and the Ransomware Response and Recovery Guide.

Sector schemes and government guidance

• Sheltered Harbor (US financial sector): participating institutions make a daily copy of critical customer account data in a standard format and archive it, encrypted and unalterable, in an offline vault, so that a peer institution or core service provider can restore account information and keep customers served if continuity plans fail. Participants undergo adherence reviews. FS-ISAC reports that the Sheltered Harbor board has approved winding down the organisation, with its specification and supporting documents transferring to FS-ISAC and managed by FS-ISAC's Resilience Congress for members. Check the current status before relying on it for programme planning.
• NIST SP 1800-25, 1800-26 and 1800-11: the NCCoE data integrity practice guides, finalised in 2020, provide reference architectures for protecting, detecting and recovering from ransomware and destructive events. SP 1800-25 covers backups, secure storage, integrity checking and audit logs; SP 1800-26 covers detecting, mitigating and containing data integrity events; SP 1800-11 covers recovery and auditing to support investigations.
• CISA #StopRansomware Guide: offline encrypted backups, golden images, retained backup hardware, offline IaC templates, regular testing, and clean-network restoration by priority.
• NCSC: offline backups kept separate and ideally offsite, MFA for backup systems on a device not used to administer them, scanning before restore, and planning for rebuilds when onsite and cloud backups are unusable. The NCSC's principles for ransomware-resistant cloud backups set provider expectations.

Decision guidance: build, buy or simplify

• Small organisations: a full operational air gap is rarely justified. Use a cloud backup service with locked retention in a separate account or tenant, plus a periodic offline copy of identity and critical data, and an on-demand clean room plan. The priority is separate identity and tested restores.
• Mid-sized organisations: a logically air-gapped cloud vault for critical workloads, with multi-person approval in a recovery organisation, a documented clean room built from IaC, and an annual full rehearsal.
• Large and regulated organisations: a dedicated vault (operational air gap on premises, logical in cloud, or both) with its own staff and identity plane, a standing or pre-staged clean room, sector schemes where they apply, and quarterly rehearsals of the minimum viable business.
• Cost drivers: retained copies under a compliance lock are charged for their full term, cloud restores incur egress and compute, and standing clean rooms cost money every month. Size retention to the dwell time you need to survive, not to a round number.
• When not to vault: data that can be re-derived, regenerated from source systems or is low priority. Every extra terabyte slows the hunt for a clean copy.

Implementation: a phased approach

1. Define the minimum viable business: with business owners, list the services, dependencies, recovery time and recovery point targets, and the dwell time you must survive.
2. Choose the air gap model and identity plane: decide physical, operational, logical or a combination, and stand up the separate administration first.
3. Pilot with tier 0: vault identity, DNS and PKI first. Keep retention in a reversible mode (governance or unlocked) while sizing and testing.
4. Restore into a clean room: prove you can bring up the directory and one critical application in isolation before adding more data.
5. Lock retention: move to compliance or locked mode only after a successful restore and a second person has reviewed the values; rollback is only possible before the lock date.
6. Expand scope: add critical applications in dependency order, with golden images and IaC.
7. Automate testing: scheduled restore tests (AWS Backup restore testing, for instance, runs plans on a cron schedule, picks the latest or a random recovery point and deletes restored resources after a validation window of 1 to 168 hours; AWS recommends a dedicated account for it).
8. Rehearse: at least annually, a full cyber recovery exercise assuming production identity is lost. Microsoft calls this a "Recover from Zero" test.

Detection and measurement

Monitor the vault from the inside and from the outside: link state changes outside the window, failed or successful attempts to change retention or locks, new vault admins, replication volume anomalies (a sudden change in change rate often indicates encryption at source), and integrity analytics results on each new copy.

• Vault coverage: percentage of minimum viable business services with a current vaulted copy of data, configuration and images.
• Time to known good copy: measured in the last exercise, from declaration to an approved clean recovery point.
• Time to minimum viable business: end to end, from declaration to critical services restored, against the agreed recovery time objective.
• Retention versus dwell time: age of the oldest clean point compared with the dwell time assumed in the risk assessment.
• Rehearsal recency and pass rate: days since the last full exercise and share of restore tests that passed validation.
• Exposure window: hours per day the replication link is open, for operational air gaps.

Common failure patterns

• Vault administered from production: the vault console uses the production IdP, so the attacker who owns the domain owns the vault.
• Replication mistaken for a vault: continuous replication to DR copies encryption and deletion within seconds.
• Retention shorter than dwell time: every vaulted copy already contains the attacker's persistence.
• No clean room: vaulted data is restored straight into the compromised network and reinfected.
• Identity left out of scope: applications are vaulted, but the directory, PKI and DNS needed to run them are not.
• Never rehearsed at scale: single-VM restores pass, but nobody has measured how long the minimum viable business takes.

Lessons from incidents

• Destruction without decryption: in JADEPUFFER, the encryption key was never stored, so payment could not restore the data. Only isolated copies change that outcome.
• Cloud features as the weapon: in the Codefinger S3 ransomware campaign, stolen long-term keys were used to re-encrypt S3 objects with SSE-C and set lifecycle rules to delete them within seven days. A vault in a separate account with locked retention and no shared credentials is outside that blast radius.

Framework mapping

Practitioner checklist

• Agree the minimum viable business, its dependencies, and recovery time and point targets with business owners.
• Choose an air gap model (physical, operational, logical or combined) and document what can open each path.
• Run the vault from a separate identity plane with phishing-resistant MFA and multi-person approval.
• Lock retention for longer than the assumed dwell time, and keep keys in the vault or a recovery-only account.
• Vault identity, DNS, PKI, golden images, IaC, runbooks and security tooling, not just application data.
• Build or script a clean room and restore tier 0 into it before going wider.
• Scan and integrity-check every candidate copy, and rotate all credentials after restore.
• Automate restore tests and rehearse a full cyber recovery at least once a year.
• Report time to known good copy and time to minimum viable business to the board.

Standards and references

• NIST: SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events
• NIST: SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events
• NIST: SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events
• CISA: #StopRansomware Guide
• NCSC: Mitigating malware and ransomware attacks
• NCSC: Offline backups in an online world
• FS-ISAC: Sheltered Harbor
• AWS: Logically air-gapped vault

Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Ransomware Prevention Guide · Business Continuity and Disaster Recovery Guide · Backup Identity Isolation Guide · Privileged Access Management Guide