Why Tier 0 Is the Layer Your Disaster Recovery Plan May Be Missing

Your Recovery Test Passed. That Doesn’t Mean You Can Recover.

Picture the drill. 

Four applications restored. Every dashboard green. High-fives in the war room. Recovery objectives met, and the team is ready to declare success.

Then someone opens the core database.

Every backup has been restored cleanly. Every checksum matches. But none of the data can be read.

Silence…

The encryption keys needed to access the data are held in a vault that was never included in the recovery scope. Nobody listed it as a critical dependency. After all, a Key Vault isn’t a business application.

A perfect backup, and no way to open it.

That’s not recovery. That’s a screenshot of one.

Welcome to Tier 0: the most critical and highly privileged layer of an organisation’s technology environment. It typically includes identity, directory services and privileged access, alongside other foundational services and dependencies, such as key and secret management, that help secure and enable recovery.

It is the layer that determines who can access systems, what they are allowed to do, and whether protected data can be used. It may not run the applications your business relies on every day, but it can determine whether those applications can be securely administered and recovered.

Yet these foundational services can be overlooked when recovery testing focuses mainly on individual applications.

The systems behind the systems

Here’s the uncomfortable part.

Your data depends on the keys.

The keys depend on the vault.

The vault may depend on identity and access services.

And the recovery plan assumes the tools needed to restore these dependencies are already available.

What happens when they aren’t?

A recovery process can become stuck waiting for a service that depends on another service that has not yet been recovered. Emergency access may exist on paper but prove difficult to use in practice. A component may pass its individual recovery test while the wider environment remains impossible to restore as planned.

The problem is not necessarily that a backup has failed. It is that the organisation has not accounted for everything needed to make that backup usable.

These dependencies can create a recovery loop: the systems needed to restore an environment may themselves depend on parts of that environment.

Test each piece alone, and it may pass.

Test them together, in the right recovery sequence, and you may discover a locked room with the key inside.

So, what should we be testing?

Resilience testing needs to go beyond the number of applications successfully restored. It must also examine whether the foundational systems that enable recovery can themselves be recovered securely and in the right order.

Start by asking the harder questions:

• Do we know what our Tier 0 actually includes, and what it depends on?
• Have we tested the recovery sequence, or just the individual components?
• Can we restore access to the keys and secrets needed by dependent systems?
• Does break-glass access actually work when normal authentication and administration routes are unavailable—or does it just exist on paper?

A useful exercise is to start with a business-critical application and work backwards. Identify the identity services, administrative privileges, certificates, keys, secrets and infrastructure it needs—not just during normal operation, but during restoration. Then ask which of those dependencies can be recovered independently, who has authority to do so, and where the recovery credentials are held.

The answers will help teams establish a sequence that is both technically possible and secure. The exact components will vary by architecture; the objective is to make the dependencies visible before the next recovery test.

Answering these questions requires more than checking recovery documentation. It means mapping dependencies, validating recovery procedures and testing realistic scenarios in which expected services are unavailable.

These tests are harder, messier and less comfortable than a standard recovery drill.

That’s the point.

Resilience begins before recovery

Better to discover a hidden dependency on a Tuesday afternoon during a planned exercise than in the middle of a real crisis, when production, logistics and customer commitments may be at stake.

Tier 0 may not always be visible in day-to-day business operations. It rarely gets the same attention as the applications employees use or the systems customers interact with.

But when it fails, its absence can change what the organisation is capable of recovering.

The question isn’t simply:

Can we recover the application?

It’s:

Can we recover what we need to recover everything else?

And even that isn’t the finish line.

Technology recovery only matters if it enables the business to keep running. Knowing which systems must be recovered is one challenge. Knowing which business capabilities must survive the disruption is another.

That’s where the Minimum Viable Company comes in.

More on that next.

When did you last test your foundational systems together—not just individually—under realistic recovery conditions?