Most enterprises would say they have a cyber resilience strategy.
They back up data with platforms like Veeam, Rubrik, or Cohesity. Identity is managed through Okta or Microsoft Entra ID.
Cloud infrastructure lives across AWS, Azure, and Google Cloud. Network and edge configuration may sit in Cloudflare, Akamai, F5, or Fastly. Observability lives in Datadog, Splunk, Dynatrace, or Grafana.
Every layer has its own controls, its own team, and increasingly, its own recovery story.
On paper, that looks like coverage. In practice, it is fragmentation.
Recovery is a dependency problem
Cyber resilience is ultimately measured by how quickly the business can operate again. That is not the same as asking whether an individual platform can be restored.
A production application may run in AWS, use Okta for authentication, Cloudflare for DNS and edge routing, Datadog for monitoring, GitHub for deployment workflows, and ServiceNow for operational processes. Its data may be protected by a completely different backup platform.
Every one of those systems can be considered “protected” independently. But the application only works when the dependencies work together.
That is the structural weakness in today’s cyber resilience market. Recovery is divided by vendor category, while the business operates as one connected system.
The missing layer is configuration
The fragmentation becomes most obvious at the configuration layer.
Recovering Okta or Entra ID means restoring more than user records. Groups, roles, conditional access policies, application integrations, authentication rules, and permissions all need to return to a trusted state.
The same applies to networking. Restoring AWS workloads does little if Cloudflare DNS records, Akamai routing rules, F5 policies, or security configurations no longer match the environment they support.
Observability creates another dependency. An application may be running, but missing Datadog monitors, Splunk alerts, Dynatrace settings, or Grafana dashboards can leave incident teams without the visibility they need.
These systems are not separate pieces of the recovery process. Business recovery depends on restoring them together.
You can restore everything individually and still fail collectively
Imagine a major cyber incident. Rubrik restores the data. AWS workloads come back online. Okta, Cloudflare, and Datadog are running again. Every team reports that its systems have been recovered.
But the environment no longer fits together.
Okta policies are incorrect. Cloudflare is restored to the wrong point in time. AWS security groups changed during the incident. Critical Datadog monitors are missing. GitHub deployment permissions no longer match the production environment.
Every platform may be available, but the business may still be unable to operate.
That is the difference between platform recovery and business recovery.
Restoring individual systems does not create cyber resilience unless the dependencies between them are restored as well.
The recoverability gap sits between the tools
Traditional resilience strategies tend to ask whether each technology has protection.
- Is the data backed up?
- Can we recover identity?
- Do we have AWS disaster recovery?
- What is our SaaS backup strategy?
All important questions, but there is another question sitting between them:
Can we recover the configuration that makes all of these systems work together?
That includes the last known-good state of identity policies, network settings, cloud resources, observability rules, SaaS integrations, access controls, and third-party dependencies.
Today, those recovery points are often spread across different tools, native vendor histories, IaC repositories, scripts, tickets, documentation, and the memory of the people who built the environment.
That is the recoverability gap.
Cyber resilience requires coordinated recovery
Cyber resilience does not require replacing the platforms organizations already use for backup, identity, cloud infrastructure, networking, and observability. The challenge is ensuring those systems can be recovered together.
That requires visibility into configurations and dependencies across the environment, along with versioned recovery points that show what changed and when. Organizations also need to identify trusted states and understand which configurations can actually be restored after an incident.
This is particularly important for cloud configurations, where infrastructure, identity policies, network rules, and application dependencies can change continuously.
The goal is not simply to recover individual platforms. It is to restore the configurations and dependencies that allow those platforms to function together.
Fragmented protection Is not cyber resilience
Enterprises do not buy one technology stack anymore. They run hundreds of interconnected platforms.
AWS does one job. Okta does another. Cloudflare, Datadog and GitHub each own another critical piece of the operating environment.
That architecture is not going away.
But recovery strategies built around those same boundaries are becoming increasingly difficult to defend.
During an incident, the board does not care that the data backup succeeded, identity has been restored, and the network team is “almost done.”
The only meaningful question is whether the business can operate. A collection of successful recoveries can still produce a failed recovery.
Learn why prevention alone is no longer enough and organizations need to build operational resilience.