TL;DR: Recovery is becoming a governed security workflow, not a backup-only exercise, according to Commvault. Cleanroom Recovery adds automated isolated recovery, runbook workflows, and on-premises cleanroom options to help organisations test recovery plans, scan backups, and validate clean data and apps before production restoration.
NHIMG editorial — based on content published by Commvault: Cleanroom Recovery and the next phase of cyber resilience
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should teams validate ransomware recovery plans before an incident?
A: Teams should test recovery plans in isolated environments that simulate contaminated backups, broken dependencies, and delayed approvals.
Q: Why does cyber recovery need identity governance as well as backup tooling?
A: Because the identities that restore systems can also reintroduce risk.
Q: What breaks when recovery runbooks are not tested end to end?
A: Teams lose the ability to trust the order of operations, the dependency map, and the clean-state decision points.
Practitioner guidance
- Inventory privileged recovery identities Map every account, token, and service principal that can touch backups, hypervisors, directory services, or recovery orchestration.
- Test recovery runbooks against contaminated-state scenarios Run exercises that assume backup sets, metadata, or restore dependencies may already be compromised.
- Apply time-bounded privileged access to recovery operations Use just-in-time approval for restoration tasks so elevated access exists only for the duration of a validated recovery step.
What's in the full article
Commvault's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step cleanroom deployment and orchestration details for cloud and on-premises environments.
- Runbook configuration options for critical assets, including optional manual steps and recovery validation flows.
- Expanded workload support covering Active Directory forest recovery alongside VMs and files.
- Threat scanning and forensic workflow specifics for pre-recovery and post-recovery validation.
👉 Read Commvault's analysis of Cleanroom Recovery and cyber recovery validation →
Cyber recovery cleanrooms: are your recovery tests realistic enough?
Explore further
Cleanroom recovery is becoming an identity control, not just a resilience feature. Once backup validation, privileged restoration, and threat scanning share the same workflow, the question is no longer whether data can be copied back. The question is whether the identities that can perform recovery are governed tightly enough to avoid restoring trust in compromised state. Practitioners should treat recovery environments as governed access domains.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: Who should own privileged access for cyber recovery workflows?
A: Ownership should sit across resilience, IAM, and PAM, because recovery privileges are part of the privileged estate. The business owner defines restoration objectives, but identity teams should control who can access backup systems, who can approve emergency restore actions, and when that access expires.
👉 Read our full editorial: Cyber recovery cleanrooms are reshaping ransomware readiness