How to Write a Backup Software RFP: Scope, Requirements and Proof

A backup software RFP asks vendors to propose how they will copy your data, keep the copies safe from failure and attack, and restore them when you need them. It follows the usual shape (see how to write an RFP), but every product claims coverage, immutability and fast restores, and each proposal means something different by those words. This guide shows how to set scope and recovery objectives, write requirements vendors can’t blur, and make them prove a restore.

What a backup software RFP has to decide

Most backup RFPs start with a trigger: a ransomware scare, a renewal quote, or a hypervisor change. Before the trigger becomes a feature list, settle four things.

• What you protect. An inventory by workload, with owners, sizes and locations.
• How much loss and downtime each workload can take. Recovery objectives by tier, agreed with business owners.
• Where the copies live. On-premises storage, a second site, cloud object storage, a vendor-run vault, offline media, or a mix. This sets cost, restore speed and how well copies survive an attack.
• Who operates it. Your team, a managed service, or a hybrid. Say which, or ask for prices on both.

Backup is about protecting and restoring data. Keeping whole services running through an outage is disaster recovery, covered in the disaster recovery RFP guide and the DRaaS RFP template. The two can share an RFP, but keep their requirements separate.

Define the scope by workload

For each workload, state how much there is and what vendors must demonstrate.

Say what is out of scope, and attach the inventory as an appendix so every vendor prices the same estate.

Recovery objectives per tier

Two targets define “recovered”. The recovery point objective (RPO) is how much data you can afford to lose, measured as time back from the failure to the last usable copy. The recovery time objective (RTO) is the longest a workload can stay unavailable. Enterprise Techie’s explainer on RTO vs RPO covers how to set them.

Give each workload a tier, such as critical, important or deferrable, with an RPO and RTO per tier. Then ask vendors, per tier, which backup method meets the RPO (scheduled jobs, snapshots or continuous capture) and which restore method meets the RTO (a full restore, an instant boot from backup storage, or a replica). Tighter targets cost more, so the tiers should get different answers.

Requirement areas, with lines you can paste

Mark each line Must-have or Nice-to-have, give it an ID, and ask for a response code on each (standard, configuration, custom, third party, roadmap or not available).

Coverage and agents

• The solution must protect every workload in Appendix [A] from one console.
• The vendor must state, per workload type, whether an agent is needed.
• The solution must restore a virtual machine to a different hypervisor or cloud.
• The vendor must list any workload covered only through a third-party product.

Backup copies and immutability

The 3-2-1-1-0 backup rule is a useful frame: three copies, two kinds of storage, one offsite, one immutable or offline, zero errors on a verified restore. Immutability (a write-once object lock, for example) stops anyone changing or deleting a copy before retention ends. An air gap limits who can reach it: physically, as offline media, or logically, through separate credentials and a management plane production admins can’t reach (see air-gapped backup).

• The solution must support the copy scheme in Appendix [B]: one offsite and one immutable or offline copy per tier.
• Immutable copies must use a lock no user, including our administrators and the vendor, can lift before retention ends; the vendor must state any override mode.
• The solution must support an air-gapped copy with its own credentials, separate from production identity.
• The solution must support cloud object storage, on-premises storage and tape as targets.

To bid the immutable tier or a vault separately, use the immutable backup storage and cyber recovery vault template.

Encryption and key management

• Backup data must be encrypted in transit and at rest, with the algorithms stated.
• We must be able to hold our own keys and rotate them without re-backing up data.
• Keys must not be stored with the data they protect.
• The vendor must state who at the vendor can access our data or keys.

Restore testing and verification

A green job status proves data reached a target, not that it comes back. Test failovers of whole services are in the disaster recovery RFP guide.

• The solution must run automated test restores on our schedule, booting backups in an isolated environment and checking the application starts.
• The solution must verify the integrity of stored copies and alert on failures.
• Test results must be reported per workload, with time taken and recovery point used.
• The vendor must state which workload types automated testing covers.

Ransomware recovery

• The solution must restore into an isolated recovery environment (a clean room) so systems can be checked before reconnecting.
• The solution must scan restore points for malware and indicators of compromise, and report which are clean.
• The solution must alert on anomalies in backup data, such as unusual change rates.
• The solution must back up and restore identity systems and configuration, not only application data.

Retention and legal hold

• Retention must be set per tier, by time period rather than a count of backups, with weekly, monthly and yearly long-term points.
• Authorized staff must be able to place a hold that suspends expiry for specific data, with an audit trail.
• The vendor must state how retention changes interact with immutable copies, which can’t be shortened.
• The solution must support deleting specific data from backups where law requires it, or state the recommended process.

Performance and scale

• The solution must use change tracking so only changed data is read and stored after the first full backup.
• The solution must deduplicate and compress data, and state the effect on restore speed.
• The vendor must size the design against Appendix [A] and state the backup window per tier.
• The solution must support bandwidth throttling so backups don’t disrupt production.

Management and reporting

• One console must manage all workloads, sites and storage targets, with role-based access.
• The solution must report success, failure and RPO compliance per workload and tier.
• The solution must provide an API and alerts to our monitoring and ticketing tools.
• The solution must keep an exportable audit log of every administrative action.

Security of the backup platform itself

• Console and API access must require multi-factor authentication for every administrator.
• Roles must separate backup operation from deletion, retention changes and security configuration.
• Deleting backups or reducing retention must need a second administrator’s approval (four-eyes approval) and a delay.
• Backup servers and repositories must run outside the production identity domain, with their own credentials.

Licensing models and support

Backup is priced per protected workload, per unit of protected capacity, or per user for SaaS data, as a subscription or a perpetual license with maintenance. Each rewards a different estate, so every vendor prices your inventory on your form.

• The vendor must price Appendix [A] on the attached form over [X] years and define one licensed unit.
• The vendor must state how growth is charged and what happens to backups if a license lapses.
• The vendor must list everything the license excludes, such as storage and cloud egress.
• Support must meet the response times in Appendix [C], which we define, including during a recovery.

Vendor questions that separate products

• Restore live, on our data. In the demo or a proof of concept (step 8 of the RFP process guide), restore a virtual machine, a database to a point in time, and one mailbox, timed by us.
• Prove immutability. With administrator credentials, try to delete or shorten the retention of a locked copy, and show what happens.
• Explain the upgrade and migration path. Can backups written today be restored by next year’s version? Can it read our old backups, or must we keep the old product until their retention expires?
• Describe a hypervisor change. If we move hypervisor or cloud mid-contract, what changes in coverage, licensing and restores?
• Show the exit. In what format do the backups exist, and how would we restore them without the vendor?

Scoring the proposals

Score the way the RFP evaluation criteria guide describes: a 1-to-5 scale with defined scores, weights fixed before proposals arrive, and a weighted score of score × weight ÷ 100. Treat coverage of Must-have workloads and the immutability proof as gates, and base recovery scores on the restores you timed. As an example only:

An example timeline

Follow the RFP process guide‘s example schedule, about 17 weeks from kickoff to signed contract for a mid-sized software purchase with an RFI first: inventory and tiers in weeks 1-2, RFI and a shortlist of three to five vendors by week 5, the RFP open in weeks 7-9, scoring to two or three finalists in weeks 10-11, demos and timed restores in weeks 12-14, then negotiation and award. A renewal with a known shortlist can move faster. Treat it as an example, not a rule.

Common mistakes

• A feature checklist instead of an inventory. Without sizes and tiers, every vendor prices a different estate.
• One recovery objective for everything. It prices the whole estate at the level of the most critical system.
• Leaving the backup platform inside production identity. An attacker with domain admin rights then owns the copies.
• Forgetting SaaS data. The provider keeps the service running; recovering your data after a deletion or an attack may fall largely to you.

Start from RFPhub’s free Backup Software RFP Template, a Word file with the sections ready to fill in, or browse the IT templates.

Further reading on Enterprise Techie

• The 3-2-1-1-0 backup rule: what each digit requires.
• RTO vs RPO: definitions and how to set them.
• Air-gapped backup: physical and logical air gaps.
• Backup restore testing: types of test and what to measure.
• Backup retention policy: schemes and legal holds.
• Ransomware recovery plan: rebuild order and the clean environment.

Frequently asked questions

What should a backup RFP include?

An inventory of what you protect by workload; recovery objectives per tier; and requirements for coverage, immutability, encryption, restore testing, ransomware recovery, retention, performance, management, platform security, licensing and support. Add a pricing form, your scoring weights, and a demo in which vendors restore your own data.

How do you write backup requirements for an RFP?

Write each requirement as one testable sentence, give it an ID, and mark it Must-have or Nice-to-have. Ask for a response code on each line so a “yes” says how it’s met. Where a word can be stretched, such as immutable, define it and ask for a demonstration.

What is the 3-2-1-1-0 rule in an RFP?

It’s a copy scheme: three copies of the data, two kinds of storage, one copy offsite, one immutable or offline, and zero errors on a verified restore. In an RFP, turn it into requirements: name the copy targets, require an immutable copy no administrator can delete, and require automated restore tests.

Should backup and disaster recovery be one RFP?

They can share one RFP when one vendor will deliver both, but keep the requirements and scoring separate. Backup is judged on what you can restore and how far back; disaster recovery on how fast whole services come back. Mixing them lets a strong answer on one hide a weak one on the other.