Notifications
Clear all
Topic starter
09/07/2026 3:32 pm
TL;DR: Clean-point identification is automated and the most recent uncorrupted file versions are assembled across backup estates, aiming to speed restores, reduce rollback, and avoid reinfection by excluding encrypted or malicious files before recovery begins, according to Commvault. The real shift is from manual recovery judgment to validated, machine-assisted resilience.
NHIMG editorial — based on content published by Commvault: Synthetic Recovery and clean cyber recovery in the Commvault Cloud Unity platform
Questions worth separating out
Q: How should security teams validate that a restore point is actually clean?
A: Teams should require a restore process that tests for known bad indicators, compares candidate versions across backup sets, and records why the chosen point was accepted.
Q: Why does ransomware recovery need identity governance input?
A: Because recovery systems are privileged.
Q: What breaks when organisations restore backups without clean-point validation?
A: They risk bringing encrypted or malicious files back into production, which can restart the incident and force another round of containment and rollback.
Practitioner guidance
- Define clean restore criteria before an incident occurs Document what qualifies as a clean-point candidate, which data sources are authoritative, and who can override the selection logic during an incident.
- Map recovery tooling to privileged access paths Review which backup operators, service accounts, and automation roles can read, select, and restore data across estates.
- Test reinfection resistance in restore exercises Run tabletop and technical recovery tests that include malicious files already present in backup sets, then verify that the restore process excludes them before production cutover.
What's in the full article
Commvault's full article covers the operational detail this post intentionally leaves for the source:
- AI-enabled multi-engine threat detection components used to score candidate files before recovery.
- The Cleanpoint identification and assembly workflow for building a curated restore point.
- Examples of how Synthetic Recovery is positioned across cloud, storage, and backup environments.
- FAQ detail on how the restore process reduces reinfection risk in practice.
👉 Read Commvault's article on Synthetic Recovery and clean cyber recovery →
Synthetic recovery for cyber recovery: are restore controls keeping up?
Explore further
09/07/2026 3:54 pm
Clean-recovery confidence is now a security control, not a backup convenience. When ransomware can sit dormant long enough to contaminate backup sets, the real control question is whether the organisation can identify a verifiable last-known-good state before restore. That is a resilience governance issue as much as a technical one, because recovery without validation simply replays the compromise. The implication is that recovery programmes must be measured by trustworthiness of the restored state, not by restore speed alone.
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, increasing the risk of accidental exposure according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: What should teams do before automating cyber recovery workflows?
A: They should define approval boundaries, evidence requirements, and exception handling for restore actions before automation is enabled. Automation should accelerate a governed process, not replace one. If the workflow can select, assemble, and restore data, then the control question becomes who can trust that action and who can challenge it. Suggested anchor: approval boundaries.
👉 Read our full editorial: Synthetic recovery changes what clean ransomware restore means
