The Six Pillars of a Modern Cloud Cyber Resilience Strategy

Most cyber resilience strategies still begin with technology.

What needs to be backed up? Which systems need redundancy? Where do we need immutable copies? How quickly can infrastructure be restored?

Those are important questions, but the first question teams should be asking is really, what is the Minimum Viable Business we need to recover?

During a major cyber incident, the goal is rarely to bring everything back at once. The goal is to restore the minimum set of business capabilities required to operate, serve customers, meet critical obligations, and begin rebuilding. Only after that is clear can the organization answer the technical question of what has to be recoverable to make that business possible.

That is where many cyber resilience strategies are still incomplete.

They protect individual systems. Businesses recover through dependencies.

TL;DR

• Cyber resilience should start with the business, not the technology. Define the Minimum Viable Business first: the critical services that must keep operating or recover first.
• Data recovery alone is not business recovery. Modern services also depend on identity, cloud infrastructure, network, security, SaaS, observability, and configuration.
• The six pillars are data, identity, configuration, dependencies, recovery readiness, and business priorities. Each one has to support the services the business actually needs.
• The biggest risk is the recoverability gap. A service may look recoverable on paper, but one slow or missing dependency can keep the business down.
• ControlMonkey helps close the configuration recoverability gap by giving teams visibility into what changed, preserving known-good configuration states, and helping recover the cloud and SaaS configuration required to operate.

Moving Toward Recovery Readiness

The market is already shifting in this direction.

In Gartner’s Hype Cycle for Backup and Data Protection Technologies, 2026, Gartner says heads of infrastructure and operations should use emerging backup and data protection technologies to improve enterprise recovery readiness. That wording matters. Protection and recovery readiness are not the same thing.

A backup can succeed while recovery still fails.

Rather than treating resilience as a collection of isolated technologies, Gartner recommends starting with critical business services, mapping the dependencies behind them, and comparing the recoverability of those dependencies with what the business actually requires.

Start With the Minimum Viable Business

A Minimum Viable Business, or MVB, defines the smallest set of business services an organization must be able to operate during a serious disruption.

It forces a different conversation between the CIO, CISO, business leaders, and recovery teams. 

• Which services absolutely need to come back first? 
• What can wait? 
• How degraded can a critical service become before the business can no longer operate? 
• And who owns those decisions?

When recovery objectives are defined by IT in isolation, organizations risk prioritizing the wrong services or investing inefficiently. The resilience strategy may look complete technically while failing to reflect what the business actually needs to survive.

The Recoverability Gap

A critical business service rarely depends on one system. A customer-facing application might depend on a database, cloud infrastructure, IAM, DNS, network configuration, security policies, observability platforms, SaaS services, third-party providers, and the configurations connecting all of them.

Recover most of those dependencies and the service may still be unavailable.

This is the recoverability gap, the distance between what the business believes it can recover and what the dependencies underneath that service are actually capable of recovering.

Closing it requires more than backup. It requires six different layers of resilience working together.

Pillar 1: Data Has to Be Recoverable

Data remains foundational. Organizations need trusted recovery points for critical databases, files, SaaS data, cloud storage, and other business information. Those copies need to survive ransomware, accidental deletion, malicious modification, credential compromise, and failures inside the production environment.

The industry has made significant progress here. Immutable backup, clean recovery points, anomaly detection, classification, and threat detection have all strengthened the data layer of cyber resilience.

But restoring the data answers only one question: can we get the information back?

It does not tell you whether the service surrounding that data can operate.

A customer database can be fully restored while the DNS configuration required to reach the application is gone. The infrastructure may be running while identity policies remain compromised. The application may be healthy while network or security configuration prevents customers from reaching it.

Data recovery is essential. BUT It is not a business recovery.

Pillar 2: Identity Has to Be Recoverable

Identity has become one of the most important control planes in modern infrastructure.

Organizations depend on human identities, machine identities, service accounts, roles, authentication policies, and permission relationships to determine who and what can access critical systems.

That makes identity an obvious target during a cyberattack.

But identity resilience cannot stop at detecting excessive privileges or preventing account compromise. Recovery teams also need to know what trusted identity looked like before the incident.

Which privileged accounts should exist? What permissions were correct? Which policies changed? Which identities were added by an attacker? Can trusted access be reconstructed without restoring compromised permissions?

Removing an attacker is only part of recovery. The organization still needs to restore trust.

Pillar 3: Configuration Has to Become Recoverable

This is the layer many cyber resilience strategies still underestimate.

Modern businesses run on configuration.

Cloud infrastructure, networks, DNS, firewalls, IAM policies, security controls, SaaS settings, observability monitors, Kubernetes configuration, deployment systems, and countless other services depend on configuration to operate.

Those configurations determine how systems communicate, who can access them, where traffic flows, which security policies are enforced, and what operators can see during an incident.

And they change constantly.

Some changes happen through Terraform or another Infrastructure as Code workflow. Others happen through APIs or directly in cloud and SaaS consoles. Some systems have partial code coverage. Others may have no code representation at all.

That becomes a recovery problem very quickly.

An organization may restore an application and its data only to discover that its DNS configuration is gone. It may rebuild cloud infrastructure while firewall rules and routing policies remain unavailable. Production may come back while the observability dashboards and alerts the operations team depends on during the incident are missing.

This is why configuration resilience needs to become a first-class part of cyber resilience.

Organizations need to know what configuration exists, what changed, what the last known-good state was, and whether that state can actually be restored.

You cannot recover what you cannot see.

Pillar 4: Dependencies Have to Be Recoverable Together

Protecting data, identity, and configuration individually is not enough. Recovery happens through a dependency chain.

Consider a payment service. Its application may depend on a database. The database depends on cloud infrastructure. The infrastructure depends on IAM and network policies. Customer traffic depends on DNS and CDN configuration. Operations depend on observability. Security teams depend on their own platforms and policies.

Every component can have its own recovery mechanism. That does not mean the payment service is recoverable.

Gartner’s pipeline model recommends assessing the effect that dependency failure would have on critical service delivery, then comparing the recoverability of that dependency with the recovery time required by the business.

The research includes a simple example: a critical service has a required RTO of five hours, but one dependency requires ten hours to recover. On paper, the business has a five-hour target. Operationally, it has a five-hour recoverability gap.

Cloud creates the same problem across many more dependencies.

If the database can recover in one hour but IAM takes six hours to reconstruct, the business does not have a one-hour recovery. If the application can recover in two hours but DNS takes eight, the service is not back in two hours.

Your RTO is only as credible as the slowest critical dependency required to meet it.

Pillar 5: Recovery Readiness Has to Be Known Before the Incident

“Backup is an activity. Recovery readiness is an outcome” is what I hear a lot from many CISO and CIOs.

There is a major difference between knowing that something was backed up and knowing that it can actually be recovered when the organization is under pressure.

For every MVB service, teams need to understand whether the required dependencies are known, whether trusted recovery points exist, whether configuration history is available, whether restoration workflows exist, and whether those dependencies can recover within the timeframe the business requires.

This is where recovery planning has to become measurable.

A strong resilience program should be able to show not only what is protected, but what is actually recoverable, what has been tested, and what remains exposed.

That creates a more useful standard: MVB Recovery Readiness.

Instead of asking whether the organization has a disaster recovery plan, leadership can ask whether the Minimum Viable Business is actually recoverable.

That is a much harder question. It is also the one that matters.

Pillar 6: Recovery Priorities Have to Come From the Business

The final pillar determines the other five. Prioritization.

It is impossible to protect everything equally. More importantly, trying to do so can distract teams from the services that matter most.

Gartner argues that perfect resilience is not achievable and recommends building a defensible strategy around the critical services that matter most to the organization. Resources should be focused on the dependencies that have the greatest effect on service delivery.

This is ultimately what the MVB provides. It gives recovery teams a business-defined order of operations.

Instead of saying “restore AWS” or “restore production,” the organization can say: restore the ability to process customer transactions.

Then work backward.

• What application supports that capability?
• What data does it require?
• Which identities need to function?
• What network paths are required?
• Which security controls need to exist?
• What SaaS platforms and third parties are part of the dependency chain?

Once those questions are answered, recovery becomes much less ambiguous.

Configuration Is the Hidden Recovery Layer

For years, disaster recovery focused heavily on infrastructure and data.

That made sense when much of the operational environment was relatively static and organizations controlled most of the systems involved. Cloud changed that.

The operational state of the business is now distributed across constantly changing configurations spanning cloud providers, identity systems, network platforms, security tools, observability platforms, SaaS services, and third-party systems.

Some of those configurations live in code. Many do not.

That creates a hidden recovery layer. Unless that layer is continuously discovered, captured, versioned, and made recoverable, the organization may have no reliable way to reconstruct the state it needs after an attack.

This is Cloud Configuration Disaster Recovery.