Who Owns Disaster Recovery When Everyone Owns a Piece?

Most organizations know who owns backup.

The infrastructure team owns the cloud environment. Security may own identity systems such as Okta or Microsoft Entra. Network teams own DNS and connectivity. Application and data teams have their own backup and recovery responsibilities.

In almost every conversation I have with CIOs, CTOs, CISOs, and resilience leaders, that part is relatively clear. People know their systems. They know their tools. They know what their team is responsible for protecting.

The problem starts when I ask a different question: How do all of those teams recover together?

Disaster recovery is not the recovery of individual systems. It is the recovery of all the systems and dependencies the business needs – together, correctly, and in the right order.

That is where the ownership model starts to break.

I call this the DR Ownership Gap: the gap between distributed ownership of individual backup and recovery responsibilities and coordinated ownership of the disaster recovery outcome.

Everyone Owns a Piece. Disaster Recovery Has to Join the Pieces.

The problem is not that organizations lack owners. Modern technology has simply created more of them.

A critical business service may depend on data protected by a traditional backup platform, infrastructure running in AWS or Azure, identity in Okta or Microsoft Entra, DNS and security policies in Cloudflare, observability in Datadog, and several SaaS and third-party systems.

Each one can have a different technical owner. Each can also have a different backup mechanism, recovery point, RTO, runbook, and restoration process.

Gartner describes this fragmentation in its 2026 Hype Cycle for Backup and Data Protection Technologies. Backup responsibility now extends across teams including ITOps, CloudOps, DevOps, SecOps, Digital Workplace, and application teams. Gartner also warns that decentralized backup operations can lead to inconsistent protection, testing practices, and hidden recovery exposures.

None of this means the operating model is wrong. I would not expect the network team to stop owning networking or the identity team to stop owning identity.

The issue is that disaster recovery starts where those individual ownership boundaries meet.

Backup Ownership Is Not Disaster Recovery Ownership

Take a customer-facing application.

The data team restores the database. The cloud team restores the underlying infrastructure. The identity team restores the required access policies. The network team restores DNS and connectivity.

Every team may complete its task successfully. The application can still fail to return.

Maybe the database was restored to 9:55 a.m., while the infrastructure represents configuration from the previous evening. Maybe an identity policy changed shortly before the incident. Maybe DNS has been restored, but nobody is certain whether a critical rule was changed by an administrator or by the attacker.

That is the difference between component recoverability and business recoverability.

Gartner’s Cloud Application Infrastructure Recovery research makes the same underlying point. Cloud application recovery requires understanding the infrastructure services, dependencies, data, and configurations required to rebuild and recover the application. Gartner specifically identifies configuration drift, incomplete Infrastructure as Code, and dependent cloud services as factors that can disrupt recovery.

A backup can therefore succeed while disaster recovery still fails.

Recovery Breaks at the Handoffs

I was reminded of this recently in a conversation with the VP of Resilience at a large U.S. financial services company.

He described the attack pattern he worries about in three stages: first, attackers take away visibility; then they target backups; then they move toward the systems the business cannot afford to lose.

What stayed with me was not only the attack sequence. It was what that sequence does to recovery.

As the incident spreads across systems, the organization moves from individual technical recovery into a coordination problem. The questions suddenly become much harder:

• Which identity state can we trust?
• Which network configuration should come back?
• Did that cloud change happen before the attack or during it?
• Are the application, infrastructure, data, identity, and network recovery points compatible?
• Which dependency has to recover first?
• Who decides when a service is safe to return to the business?

Those are not backup questions. They are disaster recovery questions.

This is where I see many DR plans become fragile. The weakness is not necessarily inside AWS, Okta, Cloudflare, the database, or the backup platform. It is in the handoffs between them.

Every team can do its job correctly and the overall recovery can still fail.

If those relationships are being worked out for the first time during the incident, the organization is learning its recovery architecture at the worst possible moment.

Recovery Has an Order

Disaster recovery is not only about what comes back. It is also about what comes back first.

Identity may need to be trusted before administrators can safely access other systems. Core networking and DNS may need to return before applications become reachable. Infrastructure has to exist before many services can run. Observability may need to recover early enough that teams can validate whether the restored environment is healthy.

The exact sequence will differ between organizations and applications. But the principle does not.

Dependencies determine recovery order.

NIST makes this explicit in its recovery guidance. The NIST CSF 2.0 Resource & Overview Guide tells organizations to understand who has recovery responsibilities, know who has the authority to make recovery decisions, and prioritize recovery tasks.

NIST’s contingency-planning guidance goes deeper. Its Business Impact Analysis process identifies critical business processes, the resources and interdependencies needed to resume them, and then the recovery priority of those resources.

That matters because a folder full of good runbooks is not yet a recovery plan.

Somebody has to understand how those runbooks connect.

Start With the Business, Then Work Backward – MVB

This is also why I don’t think recovery priorities should begin inside IT.

The business needs to decide what must operate and how quickly. Technology teams then determine what must recover to make that possible.

Gartner makes this distinction clearly in its 2026 research on cyber resilience. It recommends starting with a Business Impact Analysis to establish critical service priorities, RTOs, and RPOs. Gartner also warns that when IT defines those priorities independently, the resulting recovery objectives may not reflect what the business actually needs.

I have written about this before in the context of the Minimum Viable Business. Before asking how to restore the entire company, leadership has to agree on the minimum set of services required to operate after a major incident.

Once that is defined, you can work backward.

Which applications support those services? What data do they require? Which identity systems provide access? Which network services make them reachable? Which security controls need to be restored? Which SaaS and third-party platforms are dependencies? Which monitoring capabilities are required to operate them safely?

Gartner’s pipeline model follows a similar logic. It starts with critical business services, maps the dependencies behind them, and compares the actual recoverability of those dependencies against the RTO agreed by the business.

The business defines the recovery outcome. The technology organization has to make that outcome achievable.

This Does Not Mean the CISO Should Own Everything

There is a temptation to solve fragmented ownership by putting one executive in charge of everything.

Usually, that executive is the CISO.

I don’t think that is the answer.

Gartner’s August 2026 Top Trends in Cybersecurity — 2H26 makes an important distinction here. As cyber resilience expands the CISO’s remit, Gartner argues that this should not automatically translate into direct ownership of adjacent domains such as IT resilience. Instead, CISOs should influence, orchestrate, and coordinate across CIOs, risk leaders, business leaders, and other owners.

That is much closer to the model I see working.

The cloud team should own cloud recovery. The identity team should own identity recovery. The network team should own networking. Application and data teams should own their systems.

What needs to exist above those individual responsibilities is coordinated recovery accountability.

Someone has to make sure the recovery objectives are understood, the dependencies are mapped, the sequence is clear, and the individual recovery plans have actually been tested together.

That is very different from asking one team to own every technology involved in DR.

Configuration Makes the DR Ownership Gap Bigger

There is one layer where this ownership problem becomes even more obvious: configuration.

Data usually has an established protection model. Configuration often does not.

Who owns the recovery point for an Okta policy? Who owns the previous known-good version of a Cloudflare rule? Who protects an IAM role changed directly in AWS? Who makes sure the Datadog monitors needed during an incident can be reconstructed?

The answer can change from system to system.

Configuration is also spread everywhere. Some of it lives in Infrastructure as Code. Some was created manually. Some exist inside SaaS platforms. Some changed through APIs, scripts, automation, or AI-assisted workflows.

Yet this configuration determines whether recovered systems can actually operate together.

A database can be restored but inaccessible. An application can be deployed but unreachable. Users can exist but be unable to authenticate. Datadog can be online while the dashboards and alerts the recovery team relies on are gone.

Restoring the component is not the same as restoring its operating state.

Gartner’s Cloud Application Infrastructure Recovery research identifies this problem directly. Traditional cloud and third-party backup may protect underlying application data without protecting all of the dependent cloud services required for recovery, while incomplete IaC and configuration drift can interfere with recovery to a known state.

This is the hidden configuration layer inside the DR Ownership Gap.

From Backup Ownership to Recovery Readiness

The answer is not to take ownership away from individual teams. It is to connect those owners around one business recovery plan.

When I talk to organizations about recovery readiness, I increasingly think the important questions are not simply whether backups exist. I want to know whether the organization can answer:

• What does the business need back first?
• Which technical dependencies are required?
• Who owns each dependency?
• Is each one protected and recoverable?
• What is its last known-good state?
• What is its expected recovery time?
• What has to recover before it?
• Have those dependencies actually been tested together?

Those questions expose something that a green backup dashboard cannot.

They show whether the organization is ready to recover, rather than simply ready to restore individual assets.

The Configuration Layer Has to Become Recoverable

Thi s is the part of the problem we are focused on at ControlMonkey.

Traditional data backup remains essential. ControlMonkey does not replace it.

But modern disaster recovery also requires the configuration behind cloud infrastructure, identity, networking, observability, SaaS, and third-party systems to be recoverable.

ControlMonkey’s approach to Cloud Configuration Disaster Recovery continuously discovers those configurations, captures versioned recovery points, provides historical context into what changed, and enables supported configurations to be restored from known-good states.

The goal is not to replace the teams that own those systems. It is to give those teams, and the people coordinating DR, a reliable view of the configuration recovery layer across them.

During an incident, teams should be able to answer what existed, what changed, what the last known-good state was, what is protected, what can be restored, and what is still exposed.

Those answers turn configuration from another recovery dependency into something the organization can actually manage.

Who Owns Disaster Recovery?

After enough conversations with technology and resilience leaders, I no longer think the interesting question is, “Who owns backup?”

Most organizations can answer that.

The harder question is whether all of those owners can recover together.

Cloud, identity, network, applications, data, SaaS, and observability can all have capable teams behind them. Six teams can successfully restore six different systems and still fail to bring the business back.

That is the DR Ownership Gap.

Closing it does not require putting every recovery responsibility under one team. It requires the business to define the outcome, domain owners to make their dependencies recoverable, and resilience leadership to coordinate and validate how those pieces come back together.

Because after a major incident, nobody is going to ask whether every team completed its runbook.

They are going to ask: Is the business back?

That is cyber resilience. Everything else is preparation for that moment.