Notifications
Clear all
Topic starter
09/07/2026 3:30 pm
TL;DR: ResOps reframes recovery around clean, trusted data rather than simple uptime, with Mean Time to Clean Recovery emerging as a better measure than RTO and RPO in ransomware scenarios, according to Commvault. The shift matters because recovery programmes that restore compromised data can preserve attacker impact instead of breaking it.
NHIMG editorial — based on content published by Commvault: ResOps and clean recovery in modern cyber resilience
Questions worth separating out
Q: How should organisations measure recovery when restored systems may still be untrusted?
A: Organisations should measure recovery against verified trust, not just system availability.
Q: Why do RTO and RPO fail as the only recovery metrics in ransomware scenarios?
A: RTO and RPO measure speed and data loss tolerance, but they do not measure whether the restored state is clean.
Q: What breaks when recovery teams restore infrastructure before identity state is validated?
A: Restoring infrastructure before validating identity state can bring back service accounts, tokens, certificates, and access paths that still carry compromise or privilege risk.
Practitioner guidance
- Define clean recovery criteria for identity state Document the validation steps required before restored environments can reuse service accounts, tokens, certificates, and privileged access paths.
- Replace pure speed metrics with trust-based recovery measures Track how long it takes to restore verified clean data, validated credentials, and approved access paths, then compare that against RTO and RPO.
- Align security, infrastructure, and DevOps on a shared recovery runbook Make each team accountable for a defined trust checkpoint, including backup integrity, identity review, and application readiness, so no group can declare recovery complete on its own.
What's in the full article
Commvault's full post covers the operational detail this analysis intentionally leaves for the source:
- The full STRIVE discussion on how Stephen Foskett and Darren Thomson frame resilience operations in day-to-day practice.
- The episode-level examples behind Mean Time to Clean Recovery and how teams can use it alongside RTO and RPO.
- The cross-functional workshop approach Commvault describes for aligning security, infrastructure, and DevOps.
- The discussion of how organisations distinguish clean data from compromised data during recovery planning.
👉 Read Commvault's discussion of resilience operations and clean recovery →
ResOps and clean recovery: are your recovery metrics enough?
Explore further
09/07/2026 3:51 pm
ResOps is really a trust-recovery model, not an uptime model. Traditional recovery thinking assumes that a restored system is a usable system, but that assumption breaks once attackers can tamper with data, credentials, or privilege state before restoration. The relevant unit of recovery is no longer availability alone, it is whether the recovered environment is trustworthy enough for business action. Practitioners should treat recovery as a governance problem over state integrity, not just a restore procedure.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
- In the same survey, 88% of security professionals are concerned about secrets sprawl, which shows how widely unmanaged secret state already affects recovery and trust decisions.
A question worth separating out:
Q: Who is accountable when clean recovery fails across security and operations teams?
A: Accountability should sit with the recovery governance model, not a single tool owner. Security, infrastructure, and DevOps each own a trust checkpoint, and executive leadership should define who can declare a system clean enough to resume use. Without that clarity, teams can restore availability while leaving business trust unresolved.
👉 Read our full editorial: ResOps changes recovery from uptime to clean data trust
