How to Write a DR and Backup RFP: 40 Questions to Ask Zerto, Veeam and VMware Live Site Recovery Vendors

Disaster recovery buyer's guide

A good disaster recovery and backup RFP for a VMware estate states your scope, your current estate, your RPO and RTO tiers, your compliance duties and your budget model, then asks every vendor the same structured questions so the answers can be scored side by side. This guide gives you that structure and 40 questions to put to vendors bidding Zerto, Veeam Backup & Replication 13 or VMware Live Site Recovery, with notes on what a good answer looks like.

We help UK organisations buy, build and test DR for vSphere and VMware Cloud Foundation, and we see a lot of RFPs. Most fail in the same few places: recovery targets nobody has agreed, questions that let every vendor answer "yes", and scoring that is decided after the price is known. The product details below come from each vendor's own documentation, linked in the sources. Where we give an opinion, we say so.

What should a DR and backup RFP contain?

An RFP is a request for vendors to propose a solution to a problem you have defined. The quality of the answers depends on how well you define the problem, so the first half of the document is about you. Vendors need five things from you before they can price and design anything sensible.

The current estate section deserves more detail than most buyers give it. A vendor cannot size journals, proxies, bandwidth or recovery-site storage without change rate figures, and an RFP that leaves them out invites guesses that come back later as change requests.

Table 1. Estate data to include in the RFP and where to find it.

Set recovery tiers before you name a product

Recovery tiers come from a business impact analysis. NIST SP 800-34 Rev. 1, the US federal contingency planning guide, is a widely used model for that process and ships with a BIA template. The aim is simple: agree with application owners how much data each service can lose (RPO) and how long it can be down (RTO), then group services with similar answers into tiers. Our guide to disaster recovery terms explains RPO, RTO and related terms if you need to brief stakeholders first.

Tiering also controls cost. Protecting every VM at Tier 1 is rarely affordable, and vendors will happily price it if you ask. Put each application in a tier before the RFP goes out, and tell vendors the VM count per tier.

How do Zerto, Veeam and VMware Live Site Recovery approach DR?

You do not need to pick a product before you write the RFP, but you should know how the main options work so you can tell a strong answer from marketing copy. The three products named in this guide take different routes to the same goal. We have compared them in more depth in VMware Live Site Recovery vs Zerto vs Veeam; this section covers what an RFP author needs.

Zerto, now a Hewlett Packard Enterprise company, installs a Virtual Replication Appliance (VRA) on each ESXi host. Its documentation says every write is copied and sent asynchronously to the recovery site while the write continues on the protected site. There it lands in a journal, one per protected VM, and a checkpoint is written to each journal every few seconds. Recovery means picking one of those crash-consistent checkpoints. VMs are grouped into Virtual Protection Groups (VPGs) so a multi-VM application recovers to the same point. Zerto's documentation lists journal history settings of up to 30 days. Older points come from Extended Journal Copy, which writes retention sets to a repository.

Veeam Backup & Replication 13 offers two replication methods for vSphere alongside its backup jobs. Standard replication uses VMware snapshots and changed block tracking, and Veeam recommends it for VMs that need an RPO of hours. Continuous data protection (CDP) uses vSphere APIs for I/O filtering (VAIO) to read I/O in transit without snapshots, which Veeam says allows a near-zero RPO. CDP keeps short-term restore points in a journal for a maximum of 168 hours (7 days) and can add long-term restore points beyond that.

VMware Live Site Recovery (formerly Site Recovery Manager) is an orchestration layer. Broadcom's documentation describes three ways to protect VMs: individual VMs with vSphere Replication, datastore groups with array-based replication through a storage vendor's Storage Replication Adapter (SRA), and storage-policy-driven vVols replication. Recovery plans set the start order, network settings such as IP addresses, and custom scripts, and you can test them using a temporary copy of the replicated data. With enhanced vSphere Replication the RPO can be as low as 1 minute. Broadcom's ransomware service, VMware Live Cyber Recovery, appears in current TechDocs as VMware Live Recovery Cloud and provides an isolated recovery environment on VMware Cloud on AWS.

Table 2. How the three products approach the main RFP topics, from vendor documentation (Zerto 10 vSphere guide, Veeam Backup & Replication 13 user guide, VMware Live Site Recovery 9.0 and VMware Live Recovery Cloud TechDocs). Check each against the version you are offered.

Which questions should you ask DR and backup vendors?

The 40 questions below are grouped into eight categories. Each category starts with why it matters and ends with what a good answer looks like. Ask every vendor every question in the same order and require answers in a fixed format (a response table with a word limit works well), so evaluators compare like with like.

Architecture and replication method

The replication method decides your RPO, your impact on production and what you have to deploy. Snapshot-based methods put load on VMs at each cycle, host-level and I/O filter methods add components to every ESXi host, and array-based methods tie you to matching storage at both sites.

1. Describe the replication method you propose for our estate (hypervisor-level, snapshot-based, I/O filter or storage array) and list every component that must be installed on our ESXi hosts, vCenter Server instances or arrays.
2. What appliances, proxies or agents run at each site, how are they sized for our estate, and what happens to protection if one fails?
3. Does the replication engine depend on VM snapshots? If so, how do you limit the impact of snapshot creation and consolidation on our busiest VMs?
4. Which vSphere, ESXi and VMware Cloud Foundation versions do you support today, and how soon after a new VMware release do you normally publish support?
5. How do you keep multi-VM applications consistent, so that web, application and database tiers recover to the same point in time?

A good answer names components, versions and limits and points to public documentation. Be wary of answers that describe the product in general terms without saying what will run on your hosts.

RPO, RTO and testing

Every vendor will claim a low RPO. The useful question is whether that RPO holds at your change rate over your links, and whether you can prove the RTO with a test that does not touch production. The NCSC's guidance on offline backups puts regular testing alongside regular backups for this reason.

6. What RPO can you sustain for our Tier 1 VMs at the change rate and WAN bandwidth in Section 2, and how will you demonstrate it during the proof of concept?
7. How far back can we recover, at what granularity, and where is that history held (journal, replica restore points, backups)?
8. How does a non-disruptive DR test work: is it isolated from production networks, does replication continue during the test, and what storage does the test consume?
9. What does a test or failover report show (actual recovery time per VM, errors, steps run), and is it suitable as audit evidence?
10. How do failback and re-protection work after a real failover, and how long would resynchronisation take for our largest VM?

A good answer gives RPO figures tied to your numbers, explains test isolation in detail and shows a sample report. Zerto's documentation, for example, says a failover test builds VMs in a sandbox on the test network, writes to scratch volumes, and keeps replicating while the test runs. That is the level of detail you want from every bidder.

Ransomware resilience and immutability

Ransomware changes the recovery problem. Broadcom's own ransomware recovery documentation says the most recent snapshots are likely compromised in an attack and recommends at least three months of snapshot retention, because attackers can sit in a network for weeks before they act. The NCSC's principles for ransomware-resistant cloud backups ask for backups that resist destructive actions, emergency access that an attacker cannot remove, restores from older versions when newer ones are corrupted, protected encryption keys, and alerts on privileged actions. They make a good checklist for this category.

11. Which copies of our data are immutable, what enforces the immutability (Linux file system flags, object lock, WORM storage, a vendor-managed vault), and what periods can be set?
12. If an attacker gains administrator rights on the backup server or DR management appliance, what stops them deleting replicas, backups or retention policies?
13. Do you detect suspicious encryption or unusual change activity, and how does detection help us choose a clean recovery point?
14. Where would we recover after a ransomware attack (an isolated recovery environment, a clean room, or production), and what network isolation and scanning tools are included?
15. How does your solution meet each of the NCSC principles for ransomware-resistant cloud backups, including alerts on privileged actions and protection of encryption keys?

A good answer names the mechanism. Veeam's hardened repository, for instance, makes backup files immutable for a set period so they cannot be moved, modified or deleted, and uses single-use credentials that are not stored in the backup infrastructure. Zerto's Encryption Detection inspects writes in real time and tags a "clean" checkpoint 10 minutes before the suspicious activity by default. VMware Live Recovery Cloud restores snapshots into an isolated recovery environment for analysis before anything returns to production. Answers that just say "immutable" without a mechanism should score low.

Recovery orchestration and runbooks

Restoring VMs is the easy part. A real recovery also needs the right start order, new IP addresses or DNS records, network mapping and application checks. Orchestration decides whether one tired engineer can run the recovery at 3am from a runbook.

16. How are recovery plans built: start order, dependencies, delays, re-IP and custom scripts?
17. Can a plan map VMs to different networks at the recovery site (NSX segments or port groups) and update DNS?
18. Who can run a test and who can run a real failover, and how are those rights separated and logged?
19. Can recovery plans be started and monitored through a documented API or automation tools?
20. How do we keep plans in step with the estate when VMs, datastores or networks change, and how are unprotected VMs reported?

A good answer is a live demonstration of a recovery plan running, with role separation shown in the product. Watch for limits too: Veeam's failover plans start a maximum of 10 VMs at the same time and queue the rest, which matters for large Tier 1 groups.

Scale and performance

A design that works for 50 VMs can stall at 1,500. Ask for documented maximums and for the overhead protection adds to production.

21. What are your documented maximums per management server or site pair (protected VMs, protection groups, recovery plans, concurrent recoveries)?
22. How many VMs can be recovered in parallel, and what limits recovery speed at scale?
23. How much bandwidth does our change rate need, and do you compress, deduplicate or WAN-optimise replication traffic?
24. What overhead does protection add to production hosts and storage (CPU, memory, IOPS, latency)?
25. How much storage does the recovery site need for journals, replicas, test volumes and retention, and how did you calculate it?

A good answer quotes published limits. Broadcom publishes them for VMware Live Site Recovery 9.0: for example 5,000 protected VMs per server across all replication types and 250 recovery plans. Zerto points to its own Scale and Benchmarking Guidelines for maximums. If a bidder cannot point to a published figure, ask them to commit to the number in the contract.

Security and compliance

DR software has administrator access to your whole estate and a copy of all your data, which makes it an attractive target. Treat it with the same scrutiny as your identity platform.

26. How is data encrypted in transit and at rest, and who holds and rotates the keys?
27. Which identity sources and MFA methods are supported, and can roles be scoped per site, application or tenant?
28. Which certifications and assessments apply to the software or service (for example ISO/IEC 27001, Cyber Essentials Plus or FIPS validation), and can you provide current evidence?
29. If you host any part of the service, where is the data stored, which jurisdictions apply, and how do you support our UK GDPR obligations?
30. What audit logs are produced, how long are they kept, and can they be forwarded to our SIEM?

A good answer supplies certificates and documents with dates, names the hosting regions, and states data residency in the contract. Ask each bidder to list security prerequisites (network encryption, certificate requirements, firewall ports) so you can check them at design time.

Licensing and commercial model

The licensing metric often decides the total cost more than the list price does, and some of the features vendors lead with sit in higher tiers. Broadcom is an example: its own blog says legacy Site Recovery Manager licence keys limit vSphere Replication to a 5-minute RPO, and the 1-minute level needs VMware Live Recovery subscriptions. If you are also renewing VCF, read our VCF 9.1 core licensing guide alongside this section.

31. What is the licensing metric (per VM, per socket, per core, per TB or a bundle), and what counts towards it, including VMs at the recovery site?
32. Which features in your proposal need a higher edition or a separate licence (lowest RPO, immutability, ransomware tooling, orchestration, cloud recovery)?
33. What is the five-year total cost for our estate, including recovery-site infrastructure, storage, cloud consumption, data egress and professional services?
34. How are prices set at renewal, and what caps or protections will you commit to?
35. What happens at exit: notice periods, data export formats, and how we restore from retained copies after the contract ends?

A good answer maps every feature in the technical response to a line in the price schedule. Any feature that appears in the solution but not in the price is a future change request.

Support and services

You find out how good a vendor's support desk is during a real incident, so support terms, partner skills and test services deserve as much scoring weight as features.

36. What support hours, severity definitions and response times apply, and is 24x7 support included?
37. During a declared disaster, how do we reach an engineer quickly, and what is the escalation path?
38. Who will implement the solution, what certifications do they hold, and what is in and out of the implementation scope?
39. Do you or your partner offer managed DR testing or a managed DR service, and what does a test report contain?
40. Provide two references with a comparable VMware estate who have run a real failover or an audited DR test in the last 12 months.

A good answer names the team, includes a sample statement of work, and offers references you can call without the vendor on the line.

How should you score DR and backup RFP responses?

Agree the weights with IT, security, finance and the business owners before the RFP is issued, and write them into the evaluation plan. Score each answer on a fixed scale, for example 0 (no answer) to 5 (fully meets the requirement with evidence), then multiply by the category weight. The model below is an example only. A regulated business might give security and compliance more weight; a small IT team might weight orchestration and support higher.

Table 3. A worked example for one fictional vendor. Weighted score = raw score ÷ 5 × weight. The figures are illustrative.

Two rules make scoring fair. First, score each category independently, ideally with two evaluators who then agree a moderated score. Second, set pass marks for must-have requirements. A vendor that cannot meet your Tier 1 RPO should be out, whatever its total.

How to run the evaluation, step by step

In our experience a mid-sized RFP for a VMware estate takes 8 to 12 weeks from requirements to award, with the proof of concept taking the longest. Allow more time if a hosted recovery site or cloud contract needs legal review.

1. Run the business impact analysis

   Agree tiers, RPO and RTO per application, retention periods and the scoring weights. Get sign-off from the business owners.

2. Build the long list

   Scan the market and, if you are unsure who can meet the brief, send a short RFI. Aim for four to six credible bidders.

3. Issue the RFP

   Include the five context sections, the 40 questions, a response template, a pricing schedule and a clear timetable with a clarification window.

4. Shortlist and run scripted demos

   Give two or three shortlisted vendors the same script: protect a three-tier app, run a test failover, find a clean point after simulated encryption, fail back.

5. Prove it in a PoC

   Protect a sample of real VMs over your real WAN for at least two weeks. Measure achieved RPO, test recovery time and production overhead.

6. Score, check references and negotiate

   Moderate the scores, call the references yourself, and settle SLAs, renewal caps and exit terms before signature.

What are the most common DR RFP mistakes?

We see the same problems again and again, whether the buyer is a 200-VM manufacturer or a public sector body with several sites. The smaller-estate version of these issues is covered in our BDR for SMBs guide to requirements, tests and cost traps.

Immutability questions are where many RFPs go wrong. They ask "Do you support immutable backups?" and get a yes from everyone. Ask instead what enforces immutability, who can shorten the period, and what an attacker with full admin rights on the backup server could still delete. Those answers separate products far better.

Before you issue the RFP

• Recovery tiers, RPO and RTO per application signed off by the business
• Estate data attached: VM counts per tier, capacity, change rate, WAN figures, versions
• Compliance, retention and data residency requirements written down
• Scoring weights and pass marks agreed and recorded
• Response template with word limits and a pricing schedule
• Proof of concept success criteria defined, including a real failover test
• Exit, renewal and support terms included in the draft contract

If you are also writing an RFP for a managed service or a migration, our managed IT services RFP template and migration RFP builder follow the same structure.

Frequently Asked Questions about DR and backup RFPs

Sources

• Zerto: How Zerto Recovery Works (Administration Guide, vSphere, 10.0 U5)
• Zerto: The Zerto Solution Architecture
• Zerto: The Test Failover Process
• Zerto: Encryption Detection
• Zerto: Extended Journal Copy overview
• Zerto: Advanced Journal Settings (journal history range)
• Veeam: Continuous Data Protection (CDP) for VMware vSphere (Veeam Backup & Replication 13)
• Veeam: Replication for VMware vSphere
• Veeam: Hardened Repository
• Veeam: SureBackup
• Veeam: Failover Plans
• Broadcom: Overview of VMware Live Site Recovery 9.0
• Broadcom: Operational Limits of VMware Live Site Recovery 9.0
• VMware blog: Protecting VMware Cloud Foundation 9, upgrade to enhanced vSphere Replication
• Broadcom: Ransomware Recovery with VMware Live Recovery Cloud
• Broadcom: Ransomware Recovery and Disaster Recovery
• Broadcom: VMware Live Recovery Cloud snapshots
• NCSC: Offline backups in an online world
• NCSC: Principles for ransomware-resistant cloud backups
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems

Written by the Consult Circle disaster recovery team. Last reviewed 3 November 2026.