Most disaster recovery plans are a document. Somebody wrote it two years ago, it sits in a SharePoint folder, and nobody has opened it since the audit or customer that asked for it. The first time it gets read under real pressure is usually the worst possible time to discover it is wrong.

Microsoft has started closing part of this gap itself. Entra ID now has a built-in daily backup for core directory objects, users, groups, apps, Conditional Access policies, on a Microsoft Entra ID P1 or P2 license, and Microsoft 365 Backup covers Exchange, SharePoint and OneDrive natively with configurable retention up to two years. Both are useful, and neither is a disaster recovery plan on its own. The built-in Entra backup keeps seven days of history and only the object types Microsoft has chosen to cover so far. Microsoft’s own recoverability guidance says as much: use the built-in coverage as the primary path, then extend it with non-Microsoft solutions for anything outside that scope, longer retention, and full tenant reconstruction.

That extension layer is where the actual planning happens, and it is where most companies stop. A backup tool without a tested restore process, a defined recovery order and a business that has rehearsed it is a subscription, not a plan.

How it actually works

This follows the shape that recognised business continuity frameworks use, ISO 22301, NIST SP 800-34, the BCI and DRI International good practice guidelines: business impact first, then the gap, then a strategy, then implementation, then rehearsal. What changes from company to company is the detail inside each step, not the order. You are equally welcome to start with just one.

1. Business impact assessment and compliance requirements

Requirements start with a business impact assessment: what each system’s downtime actually costs, in money, time and obligation, and which compliance demands attach to it, GDPR, NIS2, DORA, ISO 27001, whatever your sector adds on top. That assessment is what produces defensible recovery time and recovery point targets. Backup tooling requirements come later, and get shaped by this, not the other way round.

2. The gap between target and actual capability

The recovery time and recovery point targets from the business impact assessment get compared against what you can actually deliver today. If a backup and recovery capability already exists, that comparison is straightforward: measure it. If nothing exists yet, the actual capability is zero by definition, and the gap is the entire target. Either way, the gap, not the target on its own, is what the rest of the plan is built to close.

3. Recovery strategy and solution selection

ISO 22301 calls this stage strategy and solution selection. Given the gap from step two, decide how to close it. That starts with a scan of what already exists in the market: an off-the-shelf backup and recovery product, an open-source configuration tool you build on, or a mix of both, and only then a build-or-buy decision, made on cost, control and what your compliance obligations actually require. The answer is not assumed in advance, and it is not always the same answer twice.

4. Implementation, the disaster recovery plan and the runbook

Whatever came out of step three gets implemented and configured, then two documents get written from it: the disaster recovery plan itself, and the technical runbook underneath it, which system depends on which, in what order they come back, and who owns each step. If the chosen route is configuration-based rather than a packaged product, that configuration gets stored as code and deployed through a version-controlled pipeline, so recovering from a bad change is a rollback rather than a manual rebuild. If the chosen route is an off-the-shelf product instead, the runbook documents that product’s own restore procedure just as precisely, tested the same way.

5. Rehearsal, then review

The plan is walked through as a scenario exercise with the people who would actually run it and the business owners who depend on the outcome, not filed away after sign-off. What the exercise reveals, a step that took longer than planned, an owner who has since left, a dependency nobody had mapped, gets fed straight back into the disaster recovery plan and the runbook from step four, not into a fresh requirements exercise. That rehearse-and-update loop runs on its own cadence, at least annually, or whenever the IT estate changes enough to matter. A disaster recovery plan that is never reviewed is just the same document quietly going stale until the next incident finds what changed.

What you end up with

If the full package is chosen (recommended)

• A business impact assessment behind every recovery target. Recovery time and recovery point objectives that are defensible, not guessed.
• A documented gap between those targets and what you can actually deliver today. Zero, if nothing is in place yet, that is a legitimate starting point, not a missing step.
• A recovery strategy and solution decision. Market-scanned, and a build-or-buy call made on cost and control, not on habit or on what a previous project happened to use.
• A disaster recovery plan and a technical runbook for whichever solution we land on. Named owners for each step, so recovery order is decided in advance, not improvised.
• A rehearsed plan that gets reviewed and updated on a cadence. Tested organisationally with the business, not left to decay until the next incident finds what changed.

Grounded in testing, not paperwork

I have run this exact sequence, business impact assessment, gap, strategy and solution, implementation, rehearsal, on real Entra ID disaster recovery work, validated through actual restore and configuration re-apply testing, then walked through with the business as a scenario exercise rather than left as a document nobody opens. The risk assessments behind that work have been run against CIS Controls, DORA, ISO 27001, NIST CSF and GDPR, the frameworks an auditor or a customer security questionnaire will actually ask about.

Worth a conversation?

Thirty minutes, no charge, no obligation. Bring whatever disaster recovery plan you already have, even if nobody has opened it since it was written. I will tell you what in it is actually tested and what still is not.

No pitch. No pressure. Just a conversation. Or send a message instead.