Topic starter
11/08/2026 3:13 pm
TL;DR: IDC’s latest ResOps research argues that cyber resilience breaks down less because of technical fragmentation than because security, infrastructure, IT, and business teams do not share recovery decisions before an incident, according to Commvault. The practical lesson is that resilience depends on operating model alignment, not just faster tooling or better backup technology.
Editorial analysis by NHI Mgmt Group, based on content published by Commvault: “The Most Dangerous Silos in Your Organization Aren’t Your Data Silos”.
Key questions
Q: What breaks when security and business teams have not aligned recovery decisions?
A: Recovery breaks because restore order, risk tolerance, and authorisation remain unresolved until the incident is already under way.
Q: Why does minimum viable business matter for cyber resilience?
A: Minimum viable business forces organisations to define the smallest set of capabilities that must continue operating during severe disruption.
Q: How can teams tell whether a resilience council is working?
A: Look for measurable control changes, not just meeting outputs.
Practitioner guidance
- Define recovery decision rights Document who can authorise application restore order, acceptable degradation, and business trade-offs before an incident begins.
- Build a minimum viable business model Map the small set of customer, revenue, and regulatory capabilities that must continue if major systems fail.
- Test cross-functional recovery decisions Run exercises that force teams to choose between competing restore paths, data sets, and service priorities.
Bottom line: Cyber resilience fails when recovery authority is fragmented across teams that never agreed on priorities before an incident.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 hours ago by NHI Mgmt Group
11/08/2026 3:27 pm
Resilience governance fails when decision rights are distributed but never reconciled. The article shows that organisations often treat recovery as a technical workflow even though it is really a cross-functional authorisation problem. Security, infrastructure, IT, and business teams each own part of the outcome, but if they do not agree on authority before an incident, the recovery process becomes self-defeating. Practitioners should treat governance design as a resilience control, not a support function.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Who should be accountable for resilience decisions in a cross-functional incident?
A: Accountability should sit with the leaders who own business continuity, operational recovery, and risk acceptance together, not with any single technical team. Security, infrastructure, IT, and business leaders each own part of the answer, but the organisation needs a shared authority model so the incident does not become a contest between functions.
👉 Read our full editorial: ResOps shows resilience fails when security and business stay siloed
This post was modified 6 hours ago by NHI Mgmt Group