Notifications
Clear all
Topic starter
09/07/2026 3:29 pm
TL;DR: Recovery planning often fails not because teams lack documentation, but because plans are never validated in realistic conditions and break down when security, infrastructure, and operations must coordinate under pressure, according to Commvault. Evidence-based testing replaces hope with proof, which is the same governance lesson identity teams face for NHI, PAM, and lifecycle controls.
NHIMG editorial — based on content published by Commvault: the STRIVE episode on why recovery plans break down under pressure
Questions worth separating out
Q: How should security teams test recovery plans so they are actually reliable?
A: Security teams should test recovery plans under realistic pressure, with the same dependencies, time constraints, and cross-team coordination they would face in an incident.
Q: Why do documented recovery and identity workflows fail in real incidents?
A: They fail because documentation captures intent, not execution.
Q: What do organisations get wrong about recovery readiness?
A: They confuse having a plan with having evidence.
Practitioner guidance
- Test critical identity recovery paths end to end Exercise access restoration, privileged account recovery, and secret re-issuance under realistic failure conditions.
- Assign one accountable owner for each recovery chain Map every recovery step from trigger to completion, then assign a single owner for the full chain.
- Validate offboarding and revocation under pressure Rehearse leaver workflows for both human and non-human identities, including the revocation of access that crosses multiple systems.
What's in the full article
Commvault's full discussion covers the operational detail this post intentionally leaves for the source:
- The recovery exercise examples that show how documented steps fail when teams must coordinate in real time.
- The specific communication breakdowns that slow recovery across security, infrastructure, and operations.
- The practical approach for starting small with critical services before expanding recovery testing.
- The episode's broader discussion of how testing changes confidence from assumption to evidence.
👉 Read Commvault's discussion on why recovery plans fail without real-world testing →
Recovery plans under pressure: what IAM and security teams miss?
Explore further
09/07/2026 3:50 pm
Documented recovery is not proven recovery: A written plan only establishes intended behaviour, not operational durability. The article shows that real-world conditions expose dependencies, timing issues, and team friction that documentation cannot anticipate. For identity programmes, the same logic applies to access restoration and lifecycle handling, where the gap is between policy and actual execution. Practitioners should treat proof, not paperwork, as the control objective.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do teams prove that identity recovery and offboarding really work?
A: Teams prove it by running controlled exercises that include human users, privileged accounts, and non-human identities across the full lifecycle. The test should measure revocation time, restoration success, and whether ownership is clear when the process crosses multiple teams. Proof comes from repeated execution, not from policy approval.
👉 Read our full editorial: Recovery plans fail when they are never proven under pressure
