This is part 2 of a 5-post series about ResOps (resilience operations). For part 1, see What Is ResOps – and Why Cyber Resilience Needs It. Please watch for the next post, which will discuss the control phase of ResOps. You can also download the complete guide: ResOps: An Executive Guide.
Key Takeaways
- Visibility is the foundation of ResOps (resilience operations): Know what matters most, know how it’s protected, and know how well you can recover it.
- Minimum viable company (MVC) defines the critical services an organization needs to keep operating.
- Critical services need named business owners and business-defined impact tolerances.
- Dependency mapping helps reveal what critical services will need to rely on in order to operate and recover.
- A critical service is only as recoverable as its dependencies.
The Dependency Challenge
Before you can plan for recovery, you need to know what matters most. And that answer isn’t always as obvious as it seems.
That’s why visibility is foundational to ResOps. Before teams design recovery strategies or test whether they work, they need a shared view of what the organization must keep running or restore first – and everything those critical services depend on.
That sounds straightforward, but in practice it often exposes some uncomfortable gaps:
- A service the business considers critical may depend on an application that receives far less attention.
- A cloud application may rely on a single identity provider.
- A seemingly self-contained service may share infrastructure with dozens of others.
ResOps helps bring those connections into view before a disruption does.
What Is Minimum Viable Company (MVC)?
Most organizations can name their important systems. It gets harder when you ask which ones the business simply can’t operate without.
Consider this question: If we lost everything tonight, what would have to come back first?
Answering that question helps define your MVC: the smallest version of the organization that can serve customers, generate revenue, and meet its most urgent legal, regulatory, safety, or mission obligations.
The point isn’t to label every important application as critical. It’s to prioritize around business outcomes.
Technology leaders cannot make that decision alone. Business owners, technology leaders, and legal and compliance teams need to agree on which services are truly critical and what the consequences would be if those services were unavailable or degraded.
Each critical service should also have a named business owner. That ownership helps connect technical recovery decisions to the people who understand what disruption means for customers, revenue, operations, and obligations.
How Much Disruption Is Too Much?
Once you know which services matter most, the next question is: How much disruption can the business tolerate?
In ResOps, each critical service carries a business-defined impact tolerance. That tolerance describes how much downtime, data corruption, degraded performance, incorrect output, or reliance on manual workarounds the business can absorb before the harm becomes unacceptable.
Consider a payment platform that is online, but processing only 20% of its normal transaction volume. Technically, it’s running. But from the business perspective, it may be failing.
That’s why impact tolerances should reflect the business outcome, not simply whether a system is up or down. Depending on the service, that might include revenue impact per hour, transaction thresholds, customer service levels, or regulatory obligations.
The exact thresholds will differ by organization. What matters is making the priorities explicit and revisiting them as the business changes.
How Dependency Mapping Can Reveal Recovery Roadblocks
Defining a critical service tells you what will need to be recovered. Dependency mapping tells you – in granular detail – what that critical service relies on to work for that recovery to happen.
Critical services rarely operate in isolation. They may depend on identity and access systems, databases, networks, cloud infrastructure, SaaS applications, third-party APIs, shared infrastructure, people, and other internal services.
Some of these dependencies are obvious. Others aren’t. That’s where recovery plans can break down. A Tier 0 service may depend on a lower-tier system that no one considers critical. Multiple applications may rely on the same identity provider. A service thought to be self-contained may share infrastructure with other workloads. A third-party service may sit directly in the recovery path even though your organization has little control over it.
Looking only at the critical services can hide these weak points. Mapping the dependency chain makes them visible. A Tier 0 designation means little if the service depends on a lower-priority system that can’t be recovered in time.
Understanding the full dependency chain is a prerequisite if teams are expected to identify where breakdowns could occur before a disruption exposes the gap.
Why You Need Visibility Before Recovery
Visibility isn’t about creating the most detailed technology map possible. It’s about knowing what matters most, what the business can tolerate, and where dependencies could put recovery at risk.
With that understanding, teams can focus recovery efforts where they matter. But before you can strengthen or test recovery, you need a clear picture of what you’re trying to recover, and what it will take to get there.
Learn More About ResOps
Commvault has published ResOps: An Executive Guide to give CISOs, CIOs, IT, security, resilience, and risk leaders a practical framework for implementing ResOps in their organizations.
Leaders will learn how to identify the services that matter most, validate recovery readiness with real evidence, and continuously test resilience. As a result, organizations can establish a single operating model that unites security, infrastructure, IT operations, and business leaders around evidence-based recoverability.
FAQs
Q: What does visibility mean in ResOps?
A: Visibility means understanding which services are critical to the business, how much disruption each can tolerate, and the dependencies each service needs to operate and recover.
Q: What is minimum viable company (MVC)?
A: MVC is the smallest version of an organization that can serve customers, generate revenue, and meet its most urgent legal, regulatory, safety, or mission obligations. It’s a critical component for understanding and practicing ResOps as it helps prioritize what must be protected and recovered, and in what order.
Q: How is impact tolerance different from recovery time objective (RTO)?
A: Impact tolerance describes how much disruption the business can absorb before harm becomes unacceptable. It can include data corruption, degraded performance, incorrect output, transaction capacity, and manual workarounds. RTO is a recovery planning target focused on time, rather than impact to productivity or mission.
Q: What should be included in dependency mapping?
A: Dependency mapping identifies what a critical service needs in order to operate and recover, including applications, data, infrastructure, identity systems, cloud and SaaS services, third parties, people, and other internal services.
Q: How often should critical services and dependencies be reviewed?
A: Review them regularly and when significant business or technology changes occur. New priorities, applications, providers, integrations, or AI systems can change the recovery path.
Michael Thelander is Senior Director of Product Marketing at Commvault.