For years, disaster recovery was built around a relatively simple question: How quickly can we get the business back online?
That question still matters. But for today’s CIO, it is no longer enough.
Enterprise technology environments have become too dynamic to define recovery simply as restoring applications, reconnecting infrastructure and resuming operations. Applications span on-premises infrastructure, cloud environments and SaaS platforms. Identities and permissions are constantly changing. Employees introduce new tools and automation into workflows, sometimes without IT knowing about them. AI is accelerating that pace of change even further.
As a CIO, I see this complexity firsthand. My organization is navigating its own transformation while modernizing the technology that supports the business. One challenge I believe CIOs increasingly share is what I call “complexity sprawl,” the accumulation of technologies, applications, identities, integrations and processes that makes it increasingly difficult to understand what exists, how everything connects and, most importantly, what normal actually looks like.
That creates a different recovery problem. When something goes wrong, how do you know what you are actually trying to recover to?
Restoring a system does not necessarily mean restoring a trustworthy system. A compromised identity may still have inappropriate access. A configuration may have been changed. An attacker may have created another way back into the environment. A dependency may have shifted since the recovery plan was last tested. Getting everything running again is only part of the job. CIOs also need confidence that what they are bringing back is something the organization can trust.
Know what ‘good’ looks like before something goes wrong
That confidence starts with visibility long before an incident occurs.
Most large organizations do not operate within one neat technology environment. They have infrastructure accumulated over years, systems introduced through acquisitions, cloud services adopted by different business units, SaaS applications and legacy platforms that remain critical to day-to-day operations.
That complexity is not inherently bad. Much of it exists because the business evolved, and the technology evolved with it. The problem comes when an organization loses the ability to understand the environment as a whole.
I have seen how difficult it becomes to maintain a single source of truth as environments grow more fragmented. As a CIO, I do not want my team trying to reconstruct that environment for the first time while we are already managing an incident. We need that understanding before the pressure is on. What systems are critical? What depends on what? Who and what have access? What changed recently? If we cannot answer those questions while the environment is healthy, we are going to have a much harder time answering them during recovery.
That is why I view inventory and dependency mapping as recovery capabilities, not simply documentation exercises. CIOs need a continuously updated understanding of critical systems, applications, identities and dependencies. The goal is not to eliminate complexity. It is to make that complexity visible enough that we can distinguish the environment we intended to build from the environment that actually exists.
Recovery is a decision-making challenge
The challenge becomes even greater when you consider how much legitimate change occurs inside an enterprise every day. Employees change roles. Applications are updated. Permissions evolve. Automation executes actions across systems. AI tools and agents are introducing new workflows and interactions at an even faster pace.
Shadow IT is not new. CIOs have dealt with it for years. What has changed is the speed at which employees can now introduce technology into the business. Someone can adopt an AI tool or build an automated workflow without going through the traditional processes that might have given IT visibility into it.
I am navigating that reality in my own organization. I want people experimenting. I want teams finding better ways to work. The CIO cannot become the person who simply says no every time the business wants to try something new. But giving people room to innovate also requires maintaining enough visibility and governance to understand what is operating within the environment, what data it touches and what risk it introduces.
That matters enormously during recovery. When thousands of legitimate changes coexist alongside potentially malicious ones, you cannot assume the answer is simply to roll everything backward. You need to understand what changed, when it changed and whether that change belongs in the recovered environment.
This is where recovery becomes as much a decision-making challenge as a technical one.
One thing you learn quickly as a CIO is that some of the hardest decisions during an incident are not purely technical. Technology teams can tell you whether something can be restored. The harder questions are whether it should be restored, which systems need to come back first, what dependencies have to be in place and when the organization has enough confidence to safely resume operations.
Establish decision rights before the pressure is on
Those decisions cross cybersecurity, identity, infrastructure, cloud, data, applications and business operations. Restoring one system may depend on another. Reinstating an identity or permission may introduce risk elsewhere. Returning an application to production may have downstream implications for customers or business operations.
The CIO should not be making every one of those decisions personally. Our responsibility is to make sure the organization has established the priorities, ownership and decision rights necessary to make them quickly when the pressure is on.
That means asking difficult questions in advance. What does a trusted state look like for our most critical environments? Which systems and identities need to be restored first? What dependencies have to exist for them to operate safely? Who has the authority to determine whether an environment is trustworthy enough to return to production?
An active incident is the wrong time to answer those questions for the first time.
Test the organization, not just the backup
It is also why I put so much value on testing. I have spent enough time managing large technology environments to know that what is written in a recovery plan and what exists in the environment can diverge surprisingly quickly. Technology changes. People change roles. Applications are replaced. New dependencies emerge. A process that worked six months ago may rely on assumptions that are no longer true.
A meaningful recovery exercise therefore has to test more than whether a backup can technically be restored. It should test whether the organization can identify the right recovery point, understand its dependencies, make decisions under pressure and determine whether the restored environment can actually be trusted.
I also view testing as an organizational exercise. Do people understand their roles? Are escalation paths clear? Does the organization have the expertise necessary to make decisions quickly? Are critical dependencies documented, or does that knowledge reside primarily with a handful of employees?
The skills question is becoming increasingly important. One of the challenges I think about constantly is how quickly technology is changing relative to our ability to keep people current. That is difficult under normal circumstances. During a recovery event, a gap in expertise can quickly become an operational gap.
You can have the right technology and the right process on paper, but if the expertise required to execute that process sits with one or two people, you still have a resilience problem.
Testing exposes those weaknesses when the stakes are lower. It creates operational muscle memory and gives teams experience making the kinds of decisions they may eventually have to make under much greater pressure. In that sense, recovery is not a document sitting on a shelf. It is an organizational capability that has to be continually exercised.
Redefining what successful recovery looks like
I do not expect enterprise environments to become less complex. AI agents, automation and machine identities will introduce even more activity into environments that many CIOs are already working hard to understand. Businesses will continue adopting new technologies, modernizing legacy systems and connecting environments that were never originally designed to work together.
The CIO’s job is not to eliminate that complexity. It is to make sure we maintain enough visibility and control to manage it.
For recovery, that means understanding what exists and how it connects before an incident happens. It means knowing what is changing and whether those changes are legitimate. It means establishing ownership and decision rights before teams are operating under pressure. And it means testing whether the organization can actually execute the plan it has put on paper.
Speed will always matter. Every CIO wants to restore operations as quickly as possible when something goes wrong. But speed without confidence is not resilience.
Ultimately, the most important recovery question may no longer be, “How quickly can we get back?”
It may be, “How do we know what we’re getting back to?”
CIOs who can answer that question before an incident occurs will be in a much stronger position when something inevitably goes wrong.