Preparedness Is More Than Just Disaster Recovery

Prepare for disruption! Since 2004 the US has observed National Preparedness Month and the FEMA's 2026 campaign is centred on the idea of being prepared long before an emergency occurs. For enterprises, however, preparedness has become a more complicated proposition.

Disaster recovery (DR) remains an essential part of preparedness. Organisations still need reliable backups, recovery procedures, alternative infrastructure and tested restoration processes. But modern technology environments can create failure scenarios that do not resemble the recovery situations those plans were designed around.

A cloud service can become unavailable without the organisation's own internal infrastructure failing. An identity provider can disrupt access to otherwise healthy systems. A third-party SaaS platform can become inaccessible at a moment’s notice. A critical API can simply stop responding. A technology provider can change an integration’s functionality that a business process depends on.

The infrastructure may not be destroyed, but it can become unavailable, inaccessible, altered or unsuitable for the operating conditions the business now faces. The preparedness challenge becomes not only restoring what was disrupted, but also knowing what the business can still do when the environment no longer behaves as it’s presumed it would.

What Happens When The Recovery Scenario No Longer Fits?

Traditional disaster recovery is built around a relatively straightforward sequence: Something goes wrong → A system or facility is disrupted → The organisation activates its recovery plan → Data and services are restored → Normal operations resume

That model still works for many scenarios. But it becomes harder to apply when the technology supporting a business is distributed across providers and platforms, and the operating environment is constantly changing.

A recovery plan might explain how to restore an application after a server failure. It may be much less clear what to do when the application itself is functioning, but a service it relies on is unavailable and the original operating conditions cannot be restored immediately.

This is why Gartner's 2026 strategic roadmap for disaster recovery argues that programmes designed primarily around data-centre failures don’t provide adequate preparation for organisations when it comes to identity, cloud, SaaS and third-party disruptions. Its recommendation is to evolve DR towards a more continuously validated resilience capability.

The distinction matters. Recovery asks, “How do we restore the system?” But preparedness increasingly asks, “How do we continue when the system we expected to rely on is no longer available in the way we expected?” Those questions are related, but ultimately not the same.

The Risk Of Hidden Assumptions

During a disruption, the critical question may not be which system has failed, but whether the business capability that depends on it can still be delivered.

A business process may depend on its cloud environment remaining available, its identity provider authenticating users, its external APIs responding, its vendors remaining accessible and its employees retaining access to the systems they normally use. These assumptions can remain invisible until one of them stops being true.

When one of these assumptions fails, the organisation suddenly has to operate under different conditions. The useful preparedness question is not simply which assumption has changed, but whether the business capability can still be preserved. Leaders need to understand what that capability requires and what can be changed, substituted or done differently when one dependency is no longer available.

Preparedness needs to shift from asking what happens if a system fails to asking what the business can still do if a capability becomes unavailable, degraded or inaccessible. The focus is on preserving the business outcome even when the conditions required to deliver it have changed.

Preparedness Needs To Include Degraded States

A resilient or prepared enterprise cannot always wait for everything to be restored before it starts up operations again. Sometimes the business needs to be able to function with reduced capability.

A customer service team may need to work with limited access to customer data. A finance function may need to process transactions through an alternative route. A manufacturing operation may need to function at a slower pace. Employees may need to switch to different collaboration or communication tools.

These are not necessarily recovery scenarios in the traditional sense. They’re simply degraded operating states.

NIST's Cybersecurity Framework 2.0 explicitly recognises resilience objectives across different operating states, including normal operation, attack and recovery. It also emphasises identifying the most critical capabilities and services, as well as having an understanding of the impact of either a partial or complete loss.

That provides a useful way to think about preparedness. Instead of planning only for
normal operations → outage → recovery → normal operations, organisations now need to plan for normal operations → disruption → degraded operation → adaptation → recovery.

The degraded operation and adaptation stages are often the least defined parts of preparedness planning. They are also where the organisation may have to operate before full recovery is possible.

Think Beyond Backups: Build Usable Options

Backups are definitely still valuable because they give the ability to restore something, although they don’t necessarily preserve the ability to keep operating while the restoration is taking place.

That distinction becomes more important as organisations become dependent on platforms that cannot simply be rebuilt internally. An alternative only helps if the organisation can actually use it when it is needed. Having another option on standby is not the same as being able to switch to it during a disruption.

This applies to third-party services as much as internal infrastructure. A cloud provider, SaaS platform or managed service provider may have contractual commitments around availability and recovery, but those agreements do not determine how the business operates if the service becomes unavailable. The organisation still needs to understand what it can do if a supplier cannot recover within the timeframe the business can tolerate.

This is increasingly reflected in resilience guidance. Gartner's 2026 guidance recommends identifying dependencies on external providers and making sure response plans account for what happens if those dependencies fail. NIST's CSF 2.0 similarly emphasises understanding external dependencies and conducting response and recovery planning with suppliers and third parties.

IBM's 2026 research into technology infrastructure and AI readiness found that 88 per cent of organisations were attempting to move workloads between cloud providers, while only 25 per cent of those workloads were easily portable.

Having portability doesn’t automatically mean your organisation is resilient. An organisation doesn’t need to move every workload between providers simply because it can. But the finding highlights an important preparedness gap: an alternative only creates resilience if the organisation can actually activate it.

That means preparedness increasingly needs to consider questions like:

• Can a critical process operate if its primary platform or supplier is unavailable?
• Is there an alternative way to perform the most important business functions?
• How quickly could the organisation switch over?
• What would be lost or degraded during the transition?
• What happens if a supplier's recovery takes longer than the business can tolerate?
• Which decisions would need to be made manually?
• Have those alternatives been tested in the field?

The objective is not to build an expensive duplicate of every system or process. It’s to identify where the business needs optionality most, including where that optionality depends on an external provider.

Test The Business Capability, Not Just The Technology

A recovery test can establish that an application can be restored, but that does not necessarily prove that the business capability it supports can operate once recovery has been completed.

Imagine a critical customer-facing application is successfully recovered, but the identity service required to authenticate users remains unavailable. Technically, the application has been restored but operationally, the service may still be unusable.

This is why preparedness exercises need to centre on business capability rather than isolated infrastructure components. What does the organisation need to continue delivering? What outcome must be preserved? The technology, people, suppliers and processes supporting that capability are dependencies around it. What happens to the capability if one of those dependencies becomes unavailable?

This does not require organisations to predict every possible failure. It requires them to rehearse enough scenarios to expose where a critical business capability depends on an operating assumption that may not hold during disruption.

NIST's CSF 2.0 recommends exercises and tests that involve both suppliers and third party entities, with the lessons to be fed back into business continuity, disaster recovery and cyber incident response planning.

When it comes to modern infrastructure this is particularly relevant because an organisation may be unable to test resilience simply by testing the systems it operates itself. The disruption may begin somewhere else entirely.

Decision Authority When The Recovery Procedure No Longer Fits

When the environment enters an operating state the recovery procedure did not anticipate, someone needs the authority to decide what happens next. That means preparedness needs to define not only procedures, but which decisions people are authorised to make when those procedures no longer fit. They may need to ask:

• Which services take priority?
• Which customers are affected first?
• What can be temporarily switched off?
• When is a degraded service acceptable?
• When should an alternative process be activated?
• Who has authority to make that decision?

A recovery plan can definitely provide useful instructions to follow in the moment, but it cannot anticipate every decision that might become necessary, especially when a complex technology environment behaves differently from the expected or tested scenario. This makes decision-making itself part of preparedness.

Teams need to know not only what procedures exist, but which decisions they are authorised to make when those procedures no longer fit the situation. That may require clearer escalation paths, predefined priorities and cross-functional exercises focused on unfamiliar operating states.

The aim is not to eliminate uncertainty. It is to prevent uncertainty from becoming disabling and to reduce the risk of decision paralysis when the situation falls outside the recovery procedure.

Preparedness Has To Be Tested Against Change

A preparedness plan can be perfectly sensible when it is written, but the assumptions inside it can become outdated as the environment changes. Infrastructure, providers, processes, employees, software and dependencies may not be the same as when the plan was written.

New software is introduced. Old systems are retired. Workloads move between platforms. Automation changes how processes are performed. A preparedness plan shouldn’t be treated as a stagnant document that is done and dusted once approved the first time.

The plan needs to evolve alongside the environment. That does not mean running increasingly elaborate disaster simulations every month. It means periodically asking whether the assumptions underneath the existing plan still match the environment that exists now.

When reviewing your preparedness plan, look at the following:

• What has changed since the last exercise?
• Which critical services now depend on something new?
• Which fallback options have never actually been tested?
• Which recovery assumptions would be difficult to validate during a real disruption?
• Which business processes would become impossible if a key digital service disappeared for 24 hours?

This can reveal weaknesses without requiring organisations to predict the next major incident.

Don’t Aim to Predict The Next Disruption

Modern preparedness can’t be dependent on being able to forecast what will go wrong because there are simply too many possible combinations and outcomes to consider.

A cloud outage can coincide with a cyber incident. A supplier disruption can occur during a period of high demand. An identity service can become unavailable while employees are already working through another operational problem.

An interconnected environment cannot rely on an individualised recovery plan for every possible event. A more resilient approach is to prepare the organisation to adapt when the real disruption does not match the scenario the plan anticipated.

This can mean prioritising critical business capabilities, establishing acceptable levels of disruption, maintaining viable operating alternatives, testing whether those options can actually be used, and giving people the authority to make decisions when normal operating assumptions fail.

This is also why preparedness shouldn’t be confused with redundancy. Having two systems does not necessarily make an organisation resilient if both systems depend on the same provider, identity layer, network or operational process. More infrastructure can create more resilience but it can also create more complexity.

The goal is not to add another system as a backup. It is to understand where additional options genuinely preserve the business capability and reduce the consequences of a disruption.

Change Preparedness From Recovery Into Capability

Disaster recovery remains an important part of enterprise resilience. Organisations still need to know how to restore systems, recover data and return critical services to normal operation.

The harder challenge is continuing to operate when the environment no longer behaves as expected. A cloud service may be unavailable. An identity system may be inaccessible. A supplier may be unable to meet its normal service level. A critical process may have to operate with reduced functionality. A technology team may need to make decisions without having every piece of information available.

Preparedness therefore increasingly means building the ability to absorb disruption, adapt operations and preserve critical business outcomes while the underlying environment changes. The organisations that are best prepared for the next disruption may not be the ones with the most elaborate recovery plans.

They may be the ones that know which capabilities must continue, which assumptions those capabilities depend on, what alternatives exist when those assumptions fail, and how people will decide what to do next.

As infrastructure becomes more interconnected and less predictable, understanding how those systems, dependencies and operating conditions are changing becomes part of preparedness too. Keep that wider context in your sights with the latest infrastructure management developments with EM360Tech.