A fixed-price, two-week engagement that produces the document your insurer, auditor, and board keep asking for: a written business continuity and disaster recovery plan. IT Partner inventories your workloads and their dependencies, quantifies what downtime costs per tier, proposes recovery-time and recovery-point targets that your leadership decides, and authors a plan whose every procedure maps to a control that actually exists in your environment — Azure Backup jobs, Azure Site Recovery replication, Microsoft 365 data protection — with an honest gap register where one does not. Then we test it: one facilitated tabletop exercise with the people named in the plan, and the findings folded back in. We author and test the plan; the business owns every decision inside it. $3,950 fixed.
The request rarely comes from IT. It comes from the cyber-insurance renewal that now asks whether you have a written, tested disaster recovery plan. From the SOC 2 auditor working through availability criteria. From an ISO 27001 or CMMC-aligned assessment expecting continuity and contingency evidence. From a board member the week after a competitor spent four days offline. The demands differ in wording but converge on the same artifact: a written plan, current, with named owners, that has actually been exercised. An untested plan is a theory — and experienced auditors and underwriters treat it as one. We build the real thing in two weeks. First, evidence: we inventory your workloads and their dependencies, tier them by criticality, and put numbers on what an hour or a day of downtime costs each tier — because recovery targets pulled from the air are the first thing a tabletop exposes. From that we propose recovery-time and recovery-point objectives per tier, and your leadership decides them; RTO and RPO are business decisions about money and risk, and the plan records who made them. Then we author the plan itself: activation criteria and who is authorized to declare a disaster, roles and an escalation contact tree, step-by-step recovery procedures, communication templates for staff, customers, and — where relevant — regulators, and interim workarounds that keep people productive while systems recover. What makes the document worth its price is the mapping: every recovery procedure points at a concrete mechanism that exists today — the actual Azure Backup vaults and jobs, Azure Site Recovery replication if you have it, Microsoft 365 data protection, and your vendors' documented procedures for non-Microsoft systems. Where a target has no control behind it, the plan says so in a gap register with concrete close-out options, instead of papering over it. Then we test it. One facilitated tabletop exercise — a structured, scenario-driven walkthrough with the people the plan names, using injects built from your actual topology — surfaces the broken assumptions, the missing phone numbers, and the decisions nobody realized they owned. The findings go into an exercise report and the final plan, which is what turns 'we have a document' into 'we have a tested plan' on a questionnaire. Two boundaries, stated plainly: implementing DR tooling is separate work (that is what the Site Recovery implementation and backup services are for), and we do not give insurance-coverage advice — whether a specific policy's terms are met is a question for your broker and counsel. What we hand you is the tested artifact those conversations require.
Interviews with your leadership sponsor and system owners, plus a read-only review of the environment. Workloads, dependencies, vendors, and existing protections are inventoried — the plan gets built on what exists, not on what a template assumes.
Downtime impact is quantified per criticality tier and RTO/RPO targets are proposed with that evidence. Your leadership decides the targets; the decision and its owner are recorded.
The plan is written and every procedure is mapped to a verified control. Anything without a control behind it goes to the gap register — honestly, with close-out options.
Your stakeholders review the draft; corrections, missing dependencies, and organizational realities are folded in before anyone exercises it.
A facilitated, scenario-driven session of roughly two hours with the people named in the plan. Injects escalate the scenario; decisions, hesitations, and gaps are captured as findings.
Exercise findings are folded into the final plan, the maintenance schedule and owner are set, and the finished plan is walked through with your leadership.
We cannot promise any specific insurer's or auditor's acceptance, and you should distrust anyone who does. What we can say from doing this work: what carriers and auditors consistently ask for is a written plan that is current, has named owners, and has been exercised — and that is exactly what you receive, including the dated exercise report that answers the 'tested?' checkbox with evidence rather than a yes. If a particular questionnaire or framework is driving you, give it to us at kickoff and we write toward its evidence requirements.
Templates produce documents in which 'restore from backup' maps to no actual backup job and 'failover to the secondary site' describes a site that does not exist — and experienced reviewers spot boilerplate in minutes. The value here is not the document structure, it is the verification: every procedure in this plan points at a control we confirmed exists in your environment, and everything that does not exist is in the gap register where you can see and price it. A template cannot do that, because a template has never looked at your tenant.
You do — deliberately. Recovery targets are business decisions about money: how much downtime and how much data loss each tier can absorb before the cost becomes unacceptable. We bring the evidence (what an hour of downtime costs each tier, what your current controls can actually deliver, what tighter targets would cost to achieve) and propose numbers. Your leadership decides, and the plan records who decided — because 'IT picked four hours' impresses no auditor and holds up in no post-incident review.
A tabletop is a facilitated, scenario-driven walkthrough: the people named in the plan work through an escalating incident — built from your real topology — and make the decisions they would make on the day, while we capture what works and what breaks. It tests the human layer: authority, communication, sequence, assumptions. A real technical failover tests the infrastructure layer, and it belongs to the tooling engagements — our Azure Site Recovery implementation ends with exactly such a test. Mature programs do both; this engagement delivers the first and tells you precisely how to get the second.
The opposite — the plan is how you avoid buying the wrong tooling. It establishes which workloads actually matter, what targets they need, and what your current backups can genuinely deliver; the gap register then becomes a prioritized, costed shopping list instead of a vendor's guess. Buying replication before knowing your targets is how companies end up protecting the wrong servers to the wrong standard. Plan first, implement second — and we sell both in that order for a reason.
Activation criteria and who is authorized to declare a disaster; roles with named people and deputies; an escalation contact tree; per-tier recovery procedures mapped to the real controls behind them; communication templates for staff, customers, and where relevant regulators; interim workarounds to keep people productive during recovery; the RTO/RPO matrix with its sign-off record; the gap register; and the maintenance schedule. Delivered as editable working files — it is your plan, in formats you can maintain, not a locked PDF.
Roughly: a one-hour kickoff with the sponsor, 30-60 minutes with each key system or department owner during week one, a review pass on the draft, and about two hours together for the tabletop. Call it a working day in total, spread across two weeks, concentrated on the people who would run a real incident. The engagement is designed so we carry the writing load and your people carry only the decisions.
Yes. The inventory covers everything the business depends on — the line-of-business app on a vendor's cloud, the phone system, the payment processor — and the plan includes them with recovery procedures that reference your vendors' documented mechanisms and support paths. Our verification goes deepest on the Microsoft stack because that is what we can inspect and implement directly; for third-party systems we document honestly what the vendor commits to, which is itself frequently a revealing exercise.
It is structured to serve the continuity evidence that SOC 2 availability criteria, ISO 27001's continuity controls, NIST-aligned contingency-planning expectations, and cyber-insurance questionnaires consistently ask for. Alignment is not certification: if you are heading into a formal audit, our dedicated readiness assessments — ISO 27001, SOC, NIST CSF, or CMMC and NIST 800-171 — cover the full control landscape, and this plan slots into them as the continuity artifact.
Review it on every significant change — new critical system, restructure, key departure — and at least annually; re-exercise it annually as well, which is also the cadence insurer questionnaires increasingly assume. The plan ships with this schedule and a named owner written in, because an unowned plan decays silently. If you want the annual review and exercise run for you, we offer that as a separate arrangement — but the plan is deliberately built so you can do it yourselves.
Then the engagement has done its job while it is still cheap. Findings land in the exercise report and the gap register with options: relax the target knowingly, or close the gap with a concrete control — replication for the tier that needs minutes, better backup for the tier that needs days — each pointing to a separately quoted engagement you are free to take to us or to anyone. What we will not do is quietly rewrite the target so the paper looks clean. Better that a tabletop finds the truth than an outage does.
No — related discipline, different document. Incident response governs how you detect, investigate, and contain a security compromise; business continuity and disaster recovery govern how the business keeps operating and how systems are restored, whatever the cause — cyber, hardware, fire, or vendor failure. A ransomware event invokes both. This plan references your IR arrangements at the right junctions and covers the continuity side properly, rather than doing both halves badly in one binder.