Is Your DR Plan Ready? What a DR Readiness Assessment Checks

Most organizations we talk to already own the right disaster recovery tools. Backups run every night. Critical servers replicate to Azure. A third-party backup platform sits alongside it all. On paper, recovery is covered.

Then someone asks a simple question: if the main site went dark this afternoon, who would do what, in what order, and how long would it take? That is where the answers usually get vague. An untested DR plan is a hope, not a plan. A DR readiness assessment is how you find out which one you have.

Tools in Place Is Not the Same as Ready

Backup and replication protect data. Recovery is a different job. It depends on things the tools don't decide for you:

• Recovery objectives nobody signed off. Recovery time and recovery point objectives (RTO and RPO) are often set by whoever configured the replication policy, not agreed with the people who run the business.
• Dependencies nobody wrote down. An application server that fails over before identity, DNS, or its database is a server that boots and doesn't work.
• Network paths that only exist in someone's head. How users and systems reach the recovered workloads (DNS changes, VPN or ExpressRoute routes, firewall rules) has to be designed before the day you need it.
• Access that fails with the site. If the accounts needed to start a failover depend on the systems that are down, recovery stalls before it starts. Break-glass access has to be planned.
• Runbooks written for the person who wrote them. Notes that make sense to one senior engineer don't help the person on call at 2 a.m.
• No rehearsal. A plan that has never been walked through, let alone tested, hasn't been proven.

What a DR Readiness Assessment Checks

A useful assessment looks at how the environment actually behaves, not how the documentation says it should. In practice it covers six areas.

1. Inventory and dependencies

Which servers and applications matter most, what each one depends on, and the order they need to come back in. This is the foundation for everything else.

2. Recovery objectives, agreed with the business

RTO and RPO per application tier, validated with stakeholders instead of assumed. If the business needs payroll back in four hours and the design delivers it in a day, that gap should surface in a meeting, not during an outage.

3. A gap analysis against a recognized standard

Comparing current practice against a published framework keeps the review honest. Common references include NIST SP 800-34 Rev. 1 for contingency planning, the CSA Z1600 standard for emergency and continuity management in Canada, and the reliability guidance in Microsoft's Azure Well-Architected Framework.

4. The recovery architecture

Replication approach and policies, failover paths between sites and Azure, DNS and connectivity, role-based and break-glass access, and backup storage choices. Existing tools should be factored in, not replaced by default.

5. Runbooks your team can follow

Step-by-step procedures for planned and unplanned failover, failback, re-protection, and restores from a single file to a full virtual machine, plus who decides, who acts, and who gets told (RACI, escalation, and communication templates).

6. Knowledge transfer

The people who will run the recovery walk through the design and the runbooks before they need them, and leadership gets a clear view of the findings and the priorities.

What This Looks Like in Practice

We recently did this work for a Canadian group of companies running two sites with Azure Site Recovery, Azure Backup, and Commvault already in place. The tools were there. What was missing was a design and a set of runbooks the team could own.

The engagement ran in four phases: discovery and assessment, Azure DR architecture design, runbook development, and knowledge transfer. It covered 10 critical servers across both sites, with ExpressRoute providing the hybrid connectivity for the recovery paths. The result was one hybrid DR architecture, documented recovery procedures, and an IT team trained to run them. Building out the design and running live failover tests were scoped as a later phase. You can read the full story in A Recovery Plan the Team Can Run.

Testing Is Where a Plan Becomes a Capability

An assessment and a set of runbooks get you to a plan. Testing proves it. A sensible order is:

• Tabletop first. Walk the runbook as a group, out loud, and fix the steps that don't hold up.
• Test failover next. Azure Site Recovery supports test failovers that don't affect ongoing replication or production, using a network isolated from your recovery network, so you can rehearse without risk to live systems.
• Then failback and rollback. Coming back is part of recovery. Practise it too, and time both directions.
• Repeat on a schedule. Environments change. A plan tested once, two years ago, is a plan for a different environment.

That's the sequence we recommend: runbooks first, then a tabletop, then test failover and failback, with your own team doing the work.

Five Questions to Ask Your Team This Week

• When did we last restore a full server, not just a file, and how long did it take?
• Are our RTO and RPO targets written down, and did the business agree to them?
• Could someone other than the person who built our DR setup run a failover today?
• Do we know which systems have to come back first for everything else to work?
• If our primary site's sign-in systems were down, could we still start a recovery?

If any answer is "not sure", that's the place to start.

Talk to Our Team About DR Readiness

In a DR readiness review, we'll go through what you have in place, where the gaps are likely to be, and what a practical next step looks like for your environment.

Talk to our team and we'll set up a time.