How to write a technology disaster recovery plan that leadership will actually approve

Somewhere in most small businesses there is a technology disaster recovery plan that nobody has read. It is usually technically sound. Someone capable spent real time on it, documented the systems, wrote the restore order, listed the vendor contacts, and sent it to the owner or the CFO with a short note asking for a decision on the gaps it identified. That was eight months ago. It was never rejected. It was just never acted on, and now it describes a server that has since been replaced.

The reason is almost never that leadership does not care about the business surviving. It is that the plan was written for the person who would execute it rather than the person who would fund it, and those are two different documents with two different jobs. One has to be precise enough to follow at 2am with the building offline. The other has to be clear enough to approve in a twenty minute meeting by someone who will never touch the systems it describes.

The gap between them is a units problem. A technology disaster recovery plan written by technical people measures things in hours, terabytes, recovery points, failover targets, and snapshot retention. Leadership makes decisions in revenue, obligations, and exposure they can explain to a client, an insurer, an auditor, or a board. Neither side is wrong. But if nobody does the conversion, the plan sits in a folder and the business keeps carrying a risk it never actually decided to accept.

This article covers why technically correct plans get quietly declined, how to separate the board-ready summary from the implementation plan underneath it, how to calculate and present the cost of downtime for your own business, how to turn recovery targets into questions leadership can actually answer, what belongs on the one page that gets approved, how to run the meeting, what the pushback will be and what to say to it, and why approval is the start of the work rather than the end of it.

Short answer

Write two documents, not one. The technical disaster recovery plan stays technical and stays with the people who execute it. The document that goes to leadership is one or two pages and is shaped like a decision, not a description. Open it with what an hour of downtime costs this business, calculated from your own revenue in front of them rather than quoted from an industry report. State what you can actually recover today, measured by a real test and not by what the backup software reports. Name the gap between those two numbers in dollars and obligations. Then present three priced options including doing nothing, recommend one of them, and ask for a specific amount by a specific date. Leave out product names, architecture, and any term you would have to define. The plan gets approved when leadership can see that the business is already carrying the exposure and the only open question is whether to keep self-insuring it.

What leadership is actually deciding, at a glance

Question	Short version
Why do good DR plans get ignored?	They are written in units that do not convert into a business decision.
How long should the leadership document be?	One to two pages. The technical plan stays separate and stays long.
What goes on the first page?	The dollar exposure and the ask. Not the background.
Which number opens the conversation?	Cost per hour of downtime, calculated from your own revenue.
How many options should you present?	Three, and one of them is doing nothing, priced.
Should you make a recommendation?	Yes. Options without a recommendation read as avoiding accountability.
What is the most persuasive single item?	The result of a real restore test compared to what everyone assumed.
What gets a plan declined fastest?	A single option with a single price and no stated alternative.
What should never appear in the summary?	Product names, diagrams, and any term needing a definition.
When is the work actually done?	When a tested recovery has proven the money did what it promised.

Why technically correct DR plans get declined

Four things kill a plan that has nothing wrong with it.

It asks for money against an event with no date. Every other line item leadership approves has a date attached. Payroll is the fifteenth. The lease renews in March. The insurance premium is annual. A disaster recovery investment is protection against something that may never happen, and every budget cycle it competes against things that definitely will. Without a way to talk about that honestly, the plan loses to whatever has a deadline, every year, indefinitely.

It is written in units that do not convert. A four hour recovery time objective means something precise to the person who sized the infrastructure. To the CFO it is a number without a denominator. Four hours compared to what, costing what, versus what we have now? If the document does not do that arithmetic, the reader has to, and they will not.

It presents one option at one price. A single recommendation with a single number reads as a demand rather than a decision. Leadership’s role in the room is to choose, and a document that offers nothing to choose between puts them in the position of approving or refusing rather than deciding. Refusing is easier and costs nothing today.

It frames the spend as new rather than as a transfer. This is the subtle one. The plan usually reads as “here is a cost we do not currently have.” The accurate version is “here is an exposure the business is currently carrying for free, and here is what it costs to reduce it.” Those are the same proposal, but only the second one acknowledges that the business already made a decision, implicitly, by not making one.

The two documents, and why only one of them goes to leadership

The implementation plan already has a good shape. It covers what systems are critical, who is responsible, what order things come back in, how each system is actually restored, who to call, and how to communicate during the outage. That structure is covered in detail in how to write a disaster recovery plan for a small business, and nothing here replaces it. Five to ten pages, accurate, accessible, and executable under pressure. That document is for the people doing the recovery.

The leadership summary is a different artifact with a different reader. It is one to two pages, it contains no procedures, and its only job is to support a funding decision. It sits on top of the technical plan and refers to it, the way a loan application refers to a property survey without reprinting it.

Do not merge them. A merged document fails in both directions at once: too technical to approve, too summarized to execute. The specific failure is worse than it sounds, because a merged document usually gets skimmed by leadership and trusted by the team, so the business ends up with an unfunded plan that everyone believes is in place. Two documents that each do one job beat one document that does neither.

The summary should say, in a line, where the full plan lives and who maintains it. That sentence is doing real work: it tells the reader that the detail exists and has an owner, which is most of what they need to know about it.

Start with the number: what an hour of downtime costs you

Every persuasive DR summary opens with the same number, and it is not the cost of the solution. It is the cost of the problem.

The calculation is already laid out in how much business backup and disaster recovery costs, and the numbers there should be reused rather than reinvented, because a business that sees two different downtime figures from the same advisor stops trusting both. The basic formula:

Hourly downtime cost = Annual revenue / Business hours per year

For a business generating $2 million per year with 2,000 business hours, that is $1,000 per hour of downtime in revenue alone. On top of that sits idle labor, which for 20 employees at an average cost of $35 per hour is another $700 per hour of people being paid to wait. Then recovery labor, typically $100 to $200 per hour and often at urgency pricing. Then client impact, missed deadlines, and SLA penalties, which are real but harder to put a number on.

A realistic all in downtime cost for a 20 person business generating $2 million per year is $1,500 to $2,500 per hour. A full day costs $12,000 to $20,000. A week, which is not unusual for a business recovering from ransomware without good backups, costs $60,000 to $100,000.

Three rules make that number land instead of bounce.

Calculate it with their revenue, in front of them. A statistic about the average cost of downtime for mid-market businesses is an argument. A number derived from this company’s own revenue figure, written on the page while they watch, is a fact about them. The second one survives the meeting.

Say the assumptions out loud and invite the argument. Tell them you assumed 2,000 business hours and that revenue is evenly distributed, and that neither is exactly true. If they push the number down, let them, and use the number they landed on. A figure leadership edited is a figure leadership owns, and it will show up in their language later. A figure they had no hand in stays yours.

Give a range, never a point. A single number invites a debate about that number, which is a debate you cannot win because nobody knows the exact figure. A range moves the conversation to whether the low end is enough to act on, which is the conversation you want. If the low end of the range still justifies the spend, say so explicitly, because that is the strongest sentence in the document.

Then close the section with the framing that changes the room: the business is already carrying this exposure. Nobody chose it, but it is on the books. The proposal is not a new cost, it is a decision about whether to keep self-insuring an amount that would hurt.

Turn recovery targets into questions leadership can answer

Two numbers decide what any recovery setup has to look like, and they are defined in plain terms in RTO and RPO explained.

RTO, the recovery time objective, is the maximum amount of time your business can tolerate being down after an incident before the impact becomes unacceptable. It is not how long recovery actually takes. It is how long you can afford for it to take.

RPO, the recovery point objective, is the maximum amount of data loss your business can tolerate, measured in time. An RPO of one hour means backups run at least hourly, so the most you ever lose is sixty minutes of work.

Never ask a business owner what their RTO is. You will get either a blank look or the answer “zero”, and neither is usable. Ask two questions in their own language instead and do the conversion yourself.

If the billing system went down at nine on a Monday morning, at what point does this stop being annoying and start being something you have to explain to someone? The answer is the RTO, and the phrase “explain to someone” is doing the work, because it makes them think about the client or the regulator rather than about the inconvenience.

If we lost every change made since last night’s backup, whose day is gone, and can they redo the work? The answer is the RPO. People are far better at estimating lost work than at estimating tolerable data loss.

Then put the translation in the document so they can see their own answer converted:

What they said	What it means technically	What it requires
“By lunchtime we would be calling clients”	RTO of roughly 4 hours	Local restore capability, not cloud only
“We could limp through a day”	RTO of 24 hours	Standard managed backup is adequate
“Losing today’s entries would be a week of cleanup”	RPO under 1 hour on that system	Hourly backup or replication on that system only
“The file server can wait, the practice system cannot”	Two different RTOs	Tiered recovery, not one blanket policy

That last row matters more than it looks. Different systems legitimately have different targets, and saying so is what stops leadership from concluding that the whole proposal is priced for the worst case. Most of the money in a DR improvement goes to a small number of systems. Showing that you know which ones is what makes the number credible.

Build the impact table leadership already recognizes

The business impact analysis in business continuity versus disaster recovery lists critical business functions rather than IT systems, with the systems each one depends on, the maximum tolerable downtime, and the impact. Use that table exactly as it is defined there. Do not build a second one with different column names, because two impact tables that disagree is the failure mode that makes leadership stop reading either.

What the leadership version adds is two columns, and they are the two that turn a description into a decision:

Business function	Systems it depends on	Max tolerable downtime	Cost per hour down	What actually happens today
Client-facing operations	CRM, scheduling, email	4 hours	$1,400	26 hours, tested
Billing and invoicing	Accounting, email	48 hours	$300	26 hours, tested
Internal communication	Email, Teams, phone	4 hours	$700	2 hours, tested
Payroll processing	Payroll system, file access	72 hours	Low unless payday	26 hours, tested
New client intake	Website, CRM, email	8 hours	$400	26 hours, tested

Two columns, and the argument makes itself. The first row is the whole proposal: a function that cannot be down more than four hours, costing $1,400 for every hour it is, that currently takes twenty six hours to bring back. Nobody needs the rest of the document explained to them after that.

The right hand column has one hard requirement. It must be the result of an actual restore, not an estimate, not a vendor specification, and not what the backup console reports. That distinction is the subject of how to test your business backup, and it is the single highest leverage piece of preparation before the meeting. An estimate is an opinion that leadership can discount. A measured result from last month is evidence, and it changes what kind of conversation you are having.

The exposures that are not revenue

Downtime cost opens the conversation, but for many small businesses it is not the largest number on the page. Four other exposures are worth naming, and each one belongs in a single sentence rather than a section.

Client contracts and service commitments. If you have signed SLAs, uptime language, or data handling commitments, an outage is not only lost revenue, it is a contractual event. Pull the actual clauses from your two or three largest client agreements and quote them. An owner reading their own contract language back to themselves is a different experience than being told that SLA exposure exists in general.

Regulatory obligations. Some industries require documented recovery capability, not merely backups. Healthcare businesses handling protected health information need contingency planning as part of HIPAA requirements, and financial services often face similar expectations. In regulated environments, an auditor asking for evidence of tested recovery is a matter of when, not whether, and “we have backups” is not evidence.

Cyber insurance conditions. Policies increasingly ask about backup configuration, offline or immutable copies, and testing, and the answers given at application time are what the insurer will hold you to at claim time. What cyber insurance covers and what it does not is worth reading against your own policy before the meeting, because discovering a gap between what was attested and what is true during a claim is considerably more expensive than closing it now.

Buyer and enterprise client diligence. Any larger client’s vendor security questionnaire and any acquirer’s diligence checklist will ask about recovery capability and testing evidence. For an owner who expects to sell the business, or who is trying to win larger accounts, this argument frequently carries more weight than the downtime math does, because it affects revenue they are trying to get rather than revenue they might lose.

Worth keeping in proportion: downtime is only part of the total. The full cost of a data breach includes forensics, legal, notification, and reputation, and it dwarfs the recovery figure. But downtime alone is usually enough to justify the investment, so lead with it and mention the rest briefly. A document that stacks every possible consequence reads as alarmist and gets discounted as a whole.

Write the gap statement in two columns

The most effective page in any DR proposal is the one that contrasts what the business believes with what is true. Two columns, five or six rows, no commentary:

What the business assumes	What is actually the case
“We have backups”	Backups run nightly. The last successful restore test was never.
“We would be back the same day”	Measured full restore of the practice system: 26 hours.
“Everything is backed up”	Microsoft 365 data has no backup outside the tenant’s own retention.
“The backup is offsite”	The offsite copy is reachable with the same admin credentials as production.
“Our provider handles it”	The agreement covers backup monitoring. Recovery time is not committed.

Every row has to be specific and checkable. A gap statement full of general concerns is a complaint, and a complaint gets an argument back. A gap statement full of measured facts about this environment gets questions, and questions are how a decision gets made.

Two of those rows are worth expecting. Microsoft 365 is the most common one, because the assumption that a cloud platform backs itself up is nearly universal and built-in retention is not a backup. The credentials row is the one that changes minds fastest, because it is the mechanism by which ransomware reaches the backups and turns a bad week into an existential one. If your offsite copy can be deleted by the same account that manages production, you have one copy in two places.

And be precise about what you have not tested. If you have measured the file server restore but not the line of business application, say so in the column rather than implying coverage you do not have. A proposal that admits the boundary of its own evidence is more credible than one that does not, and the admission costs nothing, because the untested system is itself an argument for the work.

Always present three options, never one

Three, with prices, and one of them is doing nothing:

Option	What changes	Annual cost	Resulting recovery time
Do nothing	Nothing. Current exposure continues.	$0 direct, $12,000 to $20,000 per day of outage	26 hours, unverified going forward
Close the worst gap	Microsoft 365 backup, immutable offsite copy, one tested restore per quarter	$6,000 to $9,000	8 to 12 hours on critical systems
Full managed DR	Above, plus defined recovery targets, documented procedures, cloud standby for critical systems	$12,000 to $18,000	4 hours on critical systems

Those figures are grounded rather than invented. Managed backup and DR for a small business typically runs $8,000 to $18,000 per year in total, with monthly tiers of roughly $300 to $800 for managed backup only, $500 to $1,200 with quarterly DR testing, and $1,000 to $3,000 for full managed DR with defined recovery targets. Microsoft 365 backup is $2 to $5 per user per month. Adding a cloud replication component to an existing local backup is typically $50 to $200 per month and closes the largest single gap in most small business setups. Use your own quotes when you have them, and keep them consistent with anything you have told the same client before.

Pricing the do nothing row is the move that makes the table work. Left blank, it looks free, and free wins. Filled in with the exposure it carries, it becomes what it actually is: the most expensive option with the lowest upfront cost, which is a trade leadership is entirely capable of evaluating once someone writes it down.

The middle option deserves care, because it is the one that usually gets chosen. Make it genuinely defensible rather than a strawman placed there to make the top option look reasonable. If leadership picks the middle option, you want to have improved the situation materially, not to have sold a compromise you do not believe in.

Then recommend one. Options presented without a recommendation look like an unwillingness to be accountable for the advice, and leadership notices. Say which one you would choose and why in two sentences, and say what would change your mind. Being willing to name a condition under which you would recommend less is what makes the recommendation credible.

What a board-ready DR summary looks like

Seven blocks, one to two pages, in this order:

1. The exposure, in one sentence with a number. “An extended outage of the practice management system currently costs this business $1,400 per hour, and the last measured recovery took 26 hours.”

2. What we can recover today, measured. One short paragraph with the test date and the result. If it has not been tested, say that plainly, because an untested backup is the finding.

3. The gap in business terms. The two column table above, or three lines of prose. No technical detail.

4. The options. The three row table, with cost and resulting recovery time.

5. The recommendation. Which option, why, and what would change the advice.

6. The ask. A specific amount, a specific decision, and a date by which the decision is needed. “Approval of $14,000 annually, effective at the next renewal on March 1.”

7. How we will prove it worked. The test schedule and what evidence will be produced. This block is what separates a proposal from a request for trust.

What to leave out is equally specific. No product or vendor names, because they invite a procurement conversation before the decision has been made. No architecture diagrams. No acronym you would have to define, which in practice means writing “a copy that cannot be altered or deleted, including by an administrator” rather than the word immutable. No appendix. If the reader wants depth, they will ask, and the technical plan is one sentence away.

One formatting note that is not cosmetic: put the ask on page one. A document that builds carefully to a request on page three gets read to page two.

How to run the meeting

Twenty minutes, not sixty. A DR proposal that needs an hour is not ready.

Lead with the number rather than the background. The temptation is to explain what disaster recovery is before asking for it, and that is the order that loses the room. Start with what an hour costs, then what recovery takes today, then the ask. Background goes at the end, if there is time, for whoever wants it.

Bring the technical plan into the room but keep it out of the deck. Having it on the table, physically, and saying “the full procedures are here and Dana maintains them” answers the depth question without spending the meeting on it.

Be direct about probability, because someone will ask. You do not know whether it will happen. What you do know is what it would cost if it did, that the business is currently carrying that cost uninsured, and that recovery without a documented plan takes two to three times longer than recovery with one. Those three facts are defensible without a probability estimate, and reaching for one you cannot support is what turns a credible proposal into a sales pitch.

Name the decision date and what happens if it slips. Not as pressure, but because an undated decision is the one that does not get made. “If this is not decided before the March renewal, we auto renew the current arrangement for another year” is a real consequence and a fair thing to say.

What leadership will push back on, and the answer

The objection	The answer
“We already have backups.”	We do, and they run. What we have never confirmed is how long a restore takes and whether it works. The last test measured 26 hours against an assumption of four.
“What are the odds this happens?”	Unknown, and I would not trust anyone who gave you a precise figure. What is known is the cost if it does, and that we currently carry it in full.
“Can this wait until next fiscal year?”	It can. The exposure continues for twelve more months, and the renewal in March is the cheapest point to make the change.
“Doesn’t insurance cover this?”	Partly, and the policy asks about tested backups. Our current answer to that question would not match what we attested.
“Our IT provider handles it.”	They monitor the backups, and they do that well. The agreement does not commit to a recovery time, which means the four hours we assume is not something anyone has promised.
“This seems like a lot for a business our size.”	It is roughly one day of the outage it is meant to prevent. If the low end of the estimate is right, it pays for itself the first time.
“Can we do a cheaper version?”	Yes, and that is the middle option. It gets critical systems to eight to twelve hours instead of four. Whether that is enough is the actual decision.

The pattern in every row is the same: concede the true part of the objection first, then add the specific fact it does not account for. Arguing with the premise puts leadership in a position of defending it, and someone defending a position does not approve a budget.

A worked example

A 40 person medical billing company, roughly $6 million in revenue. Their office manager had put together a disaster recovery plan the previous year with help from their IT provider. It was eleven pages, accurate, and covered all six sections a plan should. It asked for approval of an upgraded backup arrangement. The owner read the first two pages, said it looked thorough, and nothing happened for fourteen months.

The second version was one page. It opened with the arithmetic: $6 million over 2,000 business hours is $3,000 per hour in revenue, plus roughly $1,400 per hour in idle staff, for an all in range of $4,000 to $5,000 for every hour the billing platform is unavailable. The owner argued the revenue distribution, because their volume is concentrated at month end. They agreed on $3,500 as a conservative working figure, and used that number themselves for the rest of the meeting.

Then the finding. The provider had run a full restore test three weeks earlier, at the office manager’s request. Bringing the billing platform back from the most recent backup took 31 hours, mostly because the offsite copy had to come down over their internet connection before anything could start. Everyone in the room, including the provider, had assumed four to six. That single measured number did more than the previous eleven pages had.

The exposures section ran four lines. Two of their largest client contracts contained data availability language. As a business associate handling protected health information, they would be asked for evidence of tested recovery in any audit, and had none. Their cyber policy application had been answered “yes” to a question about tested backups. And their largest prospect’s vendor questionnaire, already sitting in someone’s inbox, asked for recovery time commitments they could not truthfully provide.

Three options, priced. Do nothing at $0 and 31 hours. A local appliance plus immutable cloud copy and quarterly testing at $9,000 a year and roughly ten hours. Full managed DR with cloud standby for the billing platform at $14,000 a year and four hours.

They approved $14,000, which is inside the normal band for a business that size, and the reason was not the downtime math. It was the prospect questionnaire. The owner wanted to answer it truthfully within the quarter. The downtime number got the proposal read, the test result made it credible, and a revenue opportunity closed it. That order is common enough to plan for: the loss argument earns attention, and a gain argument often finishes the decision.

The part that mattered most came after. The first quarterly test ran in April, produced a four hour and ten minute recovery, and was reported to the owner on one page with the time on it. The following year’s renewal took a single email.

Common mistakes

1. Sending the technical plan and expecting a decision. It is the right document for the wrong reader. Nothing about it is wrong except who it was addressed to.

2. Leading with what disaster recovery is. By the time the definition is finished, attention is gone. Lead with the number and define terms only if asked.

3. Using an industry statistic instead of their revenue. A general figure about downtime costs is an argument. A figure derived from their own P&L is a fact about them, and it is the version that gets repeated back to you later.

4. Presenting a single option. It removes the decision and leaves only approval or refusal, and refusal costs nothing today.

5. Leaving the do nothing option unpriced. Blank reads as free. Fill it in with the exposure it carries and it becomes the expensive choice it actually is.

6. Presenting estimates as if they were tests. “Should restore in about four hours” and “restored in four hours on March 12” are different claims, and mixing them destroys the credibility of both. If you have not tested, the finding is that you have not tested.

7. Overstating probability to create urgency. Every inflated number invites a fight about the number, and losing that fight loses the proposal. The exposure is enough on its own.

8. Writing for the smartest person in the room. Precision and jargon are not the same thing. “A copy that cannot be altered or deleted, including by an administrator” is more precise than the word immutable and needs no glossary.

9. Treating approval as the finish line. The money is the beginning. The tested recovery is the deliverable, and without it you will be making the same case again next year with the same evidence.

10. Never reporting back. A one page result after the first test, with the measured time on it, is what makes the second request easy. Silence after approval teaches leadership that the spend produced nothing observable.

How a vCIO handles this for a client

This is a large part of what the vCIO function exists to do. The translation between technical reality and a business decision is difficult to do well from inside the IT function, and not because of ability. An internal IT person or provider proposing DR spending is proposing their own budget increase, and everyone in the room knows it, which discounts the argument no matter how sound it is.

In practice the work is: run or commission a real restore test and get a measured number, build the impact table with actual per hour costs from the company’s own financials, translate recovery targets into the two plain questions and convert the answers, price three genuine options, write the one page, and present it without the implementation detail. Then own the test schedule afterwards and report the results in the same format every quarter, which is what turns a one time approval into a standing line item nobody argues about.

The distinction from day to day IT ownership is covered in vCIO versus IT manager, and DR funding is one of the clearest examples of the split. Building and running the recovery capability is operational work. Getting it funded is not, and it tends to stay undone in businesses where nobody holds that second job.

One thing worth asking of anyone in that role, including us: ask whether they have ever recommended spending less on recovery than a client expected. A DR recommendation is unusually easy to inflate, because nobody wants to be the person who argued for less protection. Someone who can point to a case where they said the current setup was adequate is someone whose recommendation to spend means something.

How this fits the rest of your IT

DR funding sits at the intersection of two things covered elsewhere in this series. It is a risk conversation, and it is a budget conversation. On the budget side, a recovery improvement belongs in the annual technology budget cycle rather than arriving as an emergency ask, and whether the total is reasonable for a business your size is the separate question answered in how much should you spend on IT. A DR item that appears in the roadmap a year before it needs approval is far easier to fund than one that appears the month it is needed, which is one of the quieter arguments for keeping an IT roadmap at all.

On the risk side, the underlying capability is the subject of backup and disaster recovery services for small business, and the specific numbers behind any proposal come from what backup and DR actually cost. What recovery looks like in practice, and why it takes longer than anyone expects, is set out in how long it takes to recover from a ransomware attack, which is useful background for anyone preparing to answer the “how bad could it really be” question.

It also connects to the operational work in this cluster more directly than it first appears. You cannot write a credible impact table without knowing what software the business runs and who depends on it, which is what a software inventory produces. Recovery commitments you can hold are partly a function of what your providers have actually agreed to, which is a question of how you evaluated and contracted those vendors. And the whole exercise is an instance of the general pattern in aligning IT strategy with business goals: a technology decision made in isolation from the business context is the one that either does not happen or happens at the wrong size.

What is next in this series

The next article takes the same translation problem into security: how to present an IT security report to non-technical leadership. Why technical security reporting fails to drive any action, how to frame posture and risk in terms leadership can act on, what belongs in a board-level security summary as opposed to a vulnerability scan, how to make the ask specific enough to approve, and how a vCIO produces and presents that reporting on a client’s behalf.

How Sequentur can help

If you have a disaster recovery plan that has never been funded, or a backup arrangement nobody has tested, the useful first step is measuring what a recovery actually takes today. We run the test, put the result next to what an hour of downtime costs your business, and give you the one page version to take to whoever signs off. Schedule a call.