How to Write a Disaster Recovery RFP: DRaaS, Backup and Testing
Published on October 29, 2026 in RFP Guides
A disaster recovery RFP asks providers to propose how they will bring your systems and data back after an outage: disaster recovery as a service (DRaaS), backup with recovery services, or a recovery site. The structure is the same as any RFP (see how to write an RFP), but what you’re buying is a recovery you hope never to use, so the RFP has to make vendors prove it works. This guide covers the groundwork, scope, requirements, testing, pricing and scoring.
What a disaster recovery RFP is buying
Write the RFP around outcomes, not products: named systems running again within an agreed time, with no more data lost than you agreed. Replication software, backup storage and spare compute are only the means.
Framed this way, a DRaaS provider, a backup vendor with recovery services and a recovery site can all answer the same requirements, and you compare what they deliver. Also decide how much of the work to hand over. DRaaS is often sold in three models: self-service (you run the recovery on the provider’s platform), assisted (you share the work) and managed (the provider runs it). Say which you want, or ask vendors to price more than one.
Work to do before you write it
Vendors can’t quote a recovery you haven’t defined.
A business impact analysis
A business impact analysis (BIA) works out what each business process depends on and what happens when it stops. NIST’s SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, describes three steps: identify the processes a system supports and how long they can tolerate an outage, identify the resources recovery needs, and set recovery priorities. NIST publishes a free BIA template on the same page. It’s written for federal systems, but the method travels.
Systems listed by recovery tier
Turn the BIA into an inventory: every system, its owner, where it runs, what it depends on (identity, DNS, databases) and a tier, such as critical, important or deferrable. Vendors size and price against this list.
RTO and RPO for each tier
Two numbers define the recovery for each tier:
- Recovery time objective (RTO): the longest a system can stay down after a disruption.
- Recovery point objective (RPO): how much data you can afford to lose, measured as time back from the disruption to the last usable copy.
RTO decides how much of the recovery environment has to be running already. RPO decides how often data is backed up or replicated. Tighter targets cost more, so set them from the BIA, not by feel. Enterprise Techie’s RTO vs RPO guide explains how they fit together and how to set them. If you don’t yet have a written recovery plan, its disaster recovery plan template is a useful outline to fill in alongside the RFP.
What to put in scope
Leave any of these vague and every proposal will fill the gap differently.
- Which systems. Attach the tiered inventory, from virtual machines and databases to cloud workloads and SaaS data, and say what is out of scope.
- Failover and failback. Failover moves a system to the recovery site. Failback brings it home, with the changes made during the outage, once the primary site is fixed. Ask for both.
- Runbooks. Who writes and maintains the step-by-step recovery procedures, and in what order systems come back.
- Testing. State how often you’ll test, what kind of test, and who runs it (see below).
- Who declares a disaster. Name the roles on your side who can declare, how a declaration reaches the vendor, and what the vendor must do from that moment. The recovery clock should start at a defined event, not when someone at the vendor picks up the ticket.
- Network and access. Whether IP addresses and DNS records change on failover, and how users reach the recovery site.
Requirements by category
Mark each requirement Must-have or Nice-to-have, and ask for a response code on every line (standard, configuration, custom, third party, roadmap or not available) so a “yes” says how it’s met.
| Category | What to require or ask |
|---|---|
| Recovery objectives | The RTO and RPO the vendor commits to for each of your tiers; whether each is a contractual service level with remedies or only a target; when the clock starts and stops |
| Replication and backup | Replication method and frequency per tier; retention and recovery points kept; how corrupted or encrypted data is kept out of older copies; support for your platforms |
| Failover and failback | How failover is started and orchestrated; recovery order and dependencies; network identity after failover; how failback works and how long it takes; recovery capacity reserved for you, and what happens if many customers declare at once |
| Testing rights and frequency | The test schedule you set (for example, a full failover test of critical systems at a frequency you choose), whether tests disrupt production, what each test includes in the price, and the report you receive afterwards |
| Security and isolation | Immutable copies that can’t be changed or deleted before their retention ends; copies isolated from your production credentials; multi-person approval for destructive actions; encryption and key ownership; a clean, isolated environment to recover into after a cyber attack |
| Compliance evidence | Independent evidence of the vendor’s controls, such as a SOC 2 report or ISO/IEC 27001 certificate whose scope covers the service; data location; any regulatory requirements you must meet |
| Support and declaration process | How you declare, at any hour; who answers and how fast; escalation; the vendor’s role during recoveries and tests |
| Exit and data return | How your data, runbooks and configurations come back at the end of the contract, in what format and how quickly, and how the vendor certifies deletion |
For security purchases more broadly, including how to read SOC 2 and ISO/IEC 27001 evidence, see the cybersecurity RFP guide.
Making vendors prove recovery
A recovery that hasn’t been tested is an assumption. Before you award, run a test failover or a proof of concept with each of your two or three finalists, using your own workloads rather than the vendor’s demo environment. Pick a few systems that represent your tiers, with their dependencies, especially identity and DNS. Agree the success criteria in writing before it starts: the time from declaration to a working application, confirmed by the system owner; the age of the data recovered; and whether failback worked. Time it yourself.
After award, keep the right to test written into the contract, at the frequency you set in the RFP. Enterprise Techie’s backup restore testing guide covers what to measure and how often to test, by tier.
Pricing on your form
Vendors package recovery pricing differently. Require every vendor to use your pricing form, so you can compare totals over the contract term. Ask them to price:
- Protected capacity: per virtual machine, server, workload or terabyte, by tier, as the vendor bills it.
- Storage: replicated and backup storage, retention and immutable copies, with how the price grows as data grows.
- Compute during tests: what a test costs, how many are included, and the price of each extra one.
- Compute during a declared disaster: the rate once you declare, and for how long.
- Egress and network: data transfer out of the recovery site, including during failback, plus any bandwidth or connectivity charges.
- Declaration fees, if any: any charge for declaring a disaster.
- Services: onboarding, runbooks, and help during tests and recoveries.
Enterprise Techie’s DRaaS pricing brief explains how these lines make up a bill and which terms move it.
Scoring the proposals
Score the way the RFP evaluation criteria guide describes: a 1-to-5 scale with defined scores, weights agreed before proposals arrive, and a weighted score of score × weight ÷ 100. For disaster recovery, two adjustments help.
First, treat the recovery objectives for your critical tier as a Must-have gate. A vendor that can’t commit to them shouldn’t be rescued by a low price.
Second, base recovery scores on the test failover, not the proposal, and hold them back until it’s done. As an example only:
| Criterion | Example weight |
|---|---|
| Recovery proven in the test failover (RTO, RPO, failback) | 35 |
| Coverage of your systems, platforms and dependencies | 15 |
| Security, isolation and compliance evidence | 15 |
| Support, declaration process and testing terms | 15 |
| Cost over the contract term, from your pricing form | 20 |
Common mistakes
- Writing the RFP before the BIA. Without tiers and targets, vendors guess, and their proposals can’t be compared.
- One RTO and RPO for everything. Putting every system in the top tier makes the whole estate cost what your most critical systems cost.
- Accepting targets as guarantees. Check whether each objective is a contractual service level with remedies, and when its clock starts.
- Treating replication as backup. Replication copies corruption and encrypted files too. Require immutable, isolated copies alongside it.
- Leaving testing to the vendor’s calendar. Set the frequency yourself, price it on your form and write it into the contract.
Start from RFPhub’s free DRaaS RFP template, or the backup software RFP template if you’re buying the backup platform and running recovery yourself. The RFP process guide walks through issuing the RFP and reaching an award.
Frequently asked questions
What should a disaster recovery RFP include?
Your systems listed by recovery tier, the RTO and RPO for each tier, and a clear scope covering failover, failback, runbooks, testing and who declares a disaster. Add requirements by category with a response code on each, a pricing form, your scoring criteria and weights, and the right to run a test failover before you award.
What is a DRaaS RFP?
A DRaaS RFP asks providers to propose disaster recovery as a service: replicating your systems to the provider’s environment and recovering them there when you declare a disaster. It should cover recovery objectives, testing, security, support, pricing and exit, and say whether you want a self-service, assisted or managed service.
How often should disaster recovery be tested?
Set the frequency in the RFP from your own requirements, and test critical systems more often than less important ones. Some regulations and frameworks set a minimum for organizations they cover, so check which apply to you. Write the schedule and the cost of each test into the contract.
Should backup and disaster recovery be in the same RFP?
They can be, when one provider will run both or when one platform covers both. Keep the requirements separate inside the RFP, because backup is judged on what you can restore and how far back you can go, while disaster recovery is judged on how fast whole services come back.