Most backup RFPs score features such as deduplication ratios and backup speed, while the question that matters after ransomware is whether an attacker holding domain administrator rights can delete the backups, and whether you can restore clean systems in days rather than weeks. This template is a ready-to-issue request for proposal for a backup and cyber recovery platform. Its requirements are numbered, scorable and testable, with most of the weight on immutability, separation of the backup control plane from production identity, isolated and clean room recovery, malware-aware restore, and evidence from recovery testing. It is vendor-neutral and works for software, appliance, SaaS or managed service bids. It is written for infrastructure and resilience leads, security architects and procurement. For how the market is shaped, read the Backup and Cyber Recovery Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [RTO] and [workloads], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example BR-IM-02) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational.
- Weights, retention periods and recovery targets in brackets are illustrative. Derive recovery targets from your business impact analysis before issue, and do not change weights after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID and a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a backup and cyber recovery solution. The solution must protect [Organisation]'s data and systems so that backups survive a privileged attacker, can be checked for compromise before use, and can be restored into a clean environment within agreed recovery time and recovery point objectives.
- In scope: backup of [virtual machines, physical servers, databases, file and object storage, Kubernetes, Microsoft 365 or Google Workspace, other SaaS]; immutable and isolated copies; recovery orchestration; clean room or isolated recovery environment; recovery testing and reporting.
- Out of scope: [high availability and synchronous replication for disaster recovery]; [archiving for legal hold]; [endpoint backup], unless priced as an option.
- Contract term: [five] years, aligned to hardware life where appliances are proposed.
- Drivers: [ransomware resilience]; [audit or regulator findings on recovery testing]; [DORA, NIS2 or sector requirements]; [cyber insurance questionnaire answers]; [end of support for the current product].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Protected data | [front-end TB], [annual growth %], [change rate per day] |
| Workloads | [hypervisors and VM count], [physical servers], [databases by engine], [NAS and object storage], [Kubernetes clusters], [SaaS applications] |
| Sites and cloud | [data centres], [cloud providers and regions] |
| Recovery tiers | [Tier 1 services, RTO and RPO], [Tier 2], [Tier 3] |
| Identity | [Active Directory forests], [identity provider], [PAM] |
| Current tooling | [current backup product], [targets], [tape or offsite copies], [last full recovery test and result] |
| Retention | [daily, weekly, monthly, yearly copies and periods]; [regulatory retention requirements] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; shortlist and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now; available with configuration; available with custom development; third-party product required (name it); roadmap (with a committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Architecture: provide a diagram showing production, backup control plane, primary and immutable or isolated copies, the identity used by each component, and the network paths between them.
- Edition: state which edition, licence or module each answer depends on and confirm it is in the Appendix B price.
4. Functional requirements
4.1 Coverage and backup operations
| ID | Requirement | Type |
|---|---|---|
| BR-CV-01 | Protects every workload in section 2 with application-consistent backups for [databases and named applications]. State supported versions. | M |
| BR-CV-02 | Meets the RPO for each tier, with backup frequency and retention set by policy and applied automatically to new workloads by tag or location. | M |
| BR-CV-03 | Reports unprotected workloads: assets present in [hypervisor, cloud account, SaaS tenant] with no successful backup within the policy window. | M |
| BR-CV-04 | Backs up configuration needed to rebuild: hypervisor and cloud configuration, infrastructure as code templates, identity provider configuration and the backup platform's own catalogue. | S |
| BR-CV-05 | Encrypts backup data in transit and at rest with keys held in [customer key management service or HSM], and documents how keys are recovered if production key services are lost. | M |
4.2 Immutability and deletion protection
| ID | Requirement | Type |
|---|---|---|
| BR-IM-01 | Keeps at least one copy immutable for a defined retention period during which no user, administrator, support engineer or API call can delete, shorten or overwrite it. State the mechanism (write once read many storage, object lock, hardened repository, logical air gap) and what can still change it. | M |
| BR-IM-02 | Protects the backup clock: retention cannot be bypassed by changing system time or time sources on appliances or repositories. | M |
| BR-IM-03 | Requires multi-person approval (quorum) for destructive actions on any copy: deleting backups or policies, reducing retention, disabling immutability, removing storage targets. | M |
| BR-IM-04 | Delays deletion requests with a recoverable holding period of at least [days] and alerts security on every destructive request. | S |
| BR-IM-05 | Maintains an isolated copy that is offline or logically separated, reachable only from the backup system through a controlled, time-limited path. Describe the isolation and how it is verified. | S |
| BR-IM-06 | State the compliance status of the immutability mechanism for [regulations relevant to you] and any independent assessment of it. | I |
CISA's #StopRansomware Guide recommends offline, encrypted backups and delete protection or object lock, and also warns that immutable storage does not meet compliance criteria for certain regulations: BR-IM-06 asks bidders to address that directly. See the Backup Security and Immutable Backup Guide.
4.3 Control plane identity and access
| ID | Requirement | Type |
|---|---|---|
| BR-ID-01 | Backup administration can run in an identity domain separate from production Active Directory and [identity provider], so that compromise of production administrators does not grant backup control. | M |
| BR-ID-02 | All administrative access requires phishing-resistant MFA, including console, API and break-glass accounts, with granular roles separating backup operation, restore, policy change and security administration. | M |
| BR-ID-03 | Service accounts and credentials the platform uses to reach production (hypervisor, database, cloud and SaaS) are least privilege, documented per integration, stored encrypted and rotatable without outage; short-lived or federated credentials are supported where the source allows. | M |
| BR-ID-04 | Restore to original location and bulk restore can be restricted to named roles with approval, to limit misuse of restore as an exfiltration path. | S |
| BR-ID-05 | Bidder support staff access to the customer environment is disabled by default, granted per case by [Organisation], time-limited and logged. | M |
See the Backup Identity Isolation Guide and Recovering IAM and PAM After Ransomware or Domain Compromise.
4.4 Threat detection and clean restore
| ID | Requirement | Type |
|---|---|---|
| BR-TD-01 | Detects anomalies indicating encryption or mass deletion in protected data (change rate, entropy, file extension changes, sudden backup size changes) and alerts [SIEM] with the affected workload and time. | S |
| BR-TD-02 | Scans backup copies for malware and indicators of compromise supplied by [Organisation] before restore, without restoring into production. | S |
| BR-TD-03 | Identifies the last known clean recovery point per workload, using detection results and customer-supplied incident dates, and shows the evidence. | S |
| BR-TD-04 | Supports granular and staged restore: files, databases, single virtual machines, whole applications in dependency order. | M |
4.5 Isolated recovery and clean room
| ID | Requirement | Type |
|---|---|---|
| BR-IR-01 | Restores into an isolated recovery environment [on-premises vault, separate cloud account or subscription] with no network path to production, for investigation and rebuild. | M |
| BR-IR-02 | Can recover the identity tier first (Active Directory forest or identity provider configuration) into the isolated environment, then dependent services in a defined order. | S |
| BR-IR-03 | Orchestrates recovery runbooks: ordered steps, network remapping, scripts, checkpoints and approval gates, with timings recorded. | S |
| BR-IR-04 | Stores golden images and rebuild artefacts (operating system images, infrastructure as code templates, application binaries) in protected copies, so systems can be rebuilt rather than restored where compromise is suspected. | S |
| BR-IR-05 | States the sustained restore throughput achievable from the immutable or isolated copy (not only the primary copy) for the Tier 1 data volume, and the evidence for it. | M |
See the Cloud Recovery and Clean Room Guide and the Minimum Viable Company and Critical Service Recovery Order Guide.
4.6 Recovery testing and reporting
| ID | Requirement | Type |
|---|---|---|
| BR-RT-01 | Runs automated restore tests on a schedule [weekly for Tier 1], booting restored systems in isolation and checking application health, with pass or fail per workload. | M |
| BR-RT-02 | Reports achieved recovery time and recovery point per test against the tier targets, with history suitable as audit evidence. | M |
| BR-RT-03 | Reports backup success rate, immutable copy coverage, unprotected workloads and policy drift on one dashboard and through an API. | S |
| BR-RT-04 | Logs all administrative, restore and destructive actions with actor and time, streamed to [SIEM] and retained for [one year minimum]. | M |
For what to test and how often, see the Backup and Recovery Testing Checklist.
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| BR-SEC-01 | Appliances and repositories are hardened by default: no default credentials, minimal services, signed updates, and a documented patch commitment with the time to fix critical vulnerabilities. | M |
| BR-SEC-02 | Management interfaces can be restricted to a dedicated management network and are never exposed to the internet by default. | M |
| BR-SEC-03 | Provide a current ISO/IEC 27001 certificate with in-scope service or SOC 2 Type II report, data residency options, sub-processor list and a completed [SIG or CAIQ] questionnaire. | M |
| BR-SEC-04 | Describe your vulnerability disclosure process and list security advisories for the product in the last [24] months with fix dates. | S |
| BR-NF-01 | Meets backup windows and restore throughput for section 2 volumes with [growth %] headroom over the contract term. | M |
| BR-NF-02 | Backups remain readable after contract end for the retention period, or the bidder provides a documented migration path and the licence needed to restore. | M |
6. Implementation, services and support
- Approach: phases, deliverables and acceptance criteria for [Tier 1 workloads first, then immutable copy, isolated recovery environment and automated testing] within [months], including running old and new products side by side until retention overlaps.
- Recovery services: describe incident recovery support: availability, response time, on-site options and whether it is included or chargeable.
- Team: named roles and experience with estates of similar size; split between bidder, partner and [Organisation] effort.
- Support: tiers, hours, response targets by severity, and escalation during an active recovery.
- Third parties: if a managed service provider operates the backups, the obligations in sections 4 and 5 apply to it and are written into the contract, as the #StopRansomware Guide advises.
- References: [two or three] customers of similar size, at least one that has recovered from a real destructive incident or full-scale test using the product.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per front-end TB, per workload, per socket or per user; how SaaS users and Kubernetes namespaces are counted |
| Storage | Capacity included, data reduction assumptions stated separately, and cost of immutable or isolated copies, including cloud egress and retrieval |
| Hardware | Appliances, support term and refresh, if proposed |
| Modules | Which section 4 requirements need add-ons (anomaly detection, malware scanning, clean room, orchestration, automated testing) |
| Implementation and recovery services | Fixed price or day rates; cost of incident recovery assistance |
| Growth, renewal and exit | Price for [growth %]; renewal cap; cost of keeping backups readable after exit |
8. Evaluation method and proof of concept
[Organisation] will check mandatory requirements first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|---|---|
| Immutability and control plane identity (4.2, 4.3) | [25%] | Proof of concept attack tests, architecture review |
| Isolated recovery and restore speed (4.4, 4.5) | [25%] | Timed restore from the immutable copy |
| Coverage and operations (4.1) | [10%] | Proof of concept, compatibility list |
| Recovery testing and reporting (4.6) | [10%] | Automated test run |
| Platform security and assurance (5) | [10%] | Assurance reports, advisories history |
| Life-cycle cost (7) | [20%] | Appendix B over five years |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a proof of concept of [three to four] weeks covering at least:
- Protect a representative set: [a domain controller, a database server, a file share, a Kubernetes namespace, a SaaS tenant].
- Using a production-equivalent administrator account in a test domain, attempt to delete backups, shorten retention, disable immutability and change appliance time. Every attempt must fail or be held for quorum approval, and each must raise an alert.
- Simulate encryption of the file share with a benign test tool approved by [Organisation] and show anomaly detection and the last clean recovery point.
- Restore the domain controller and database into the isolated recovery environment from the immutable copy, in order, and record the achieved time against the Tier 1 RTO.
- Run one scheduled automated restore test and produce the audit report.
- Show the audit log for all of the above in [SIEM].
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Test as the attacker: the deletion test in step 2 is the most important result in this procurement. Run it with an account that mirrors what a real domain administrator or cloud owner can do.
- Time restores from the protected copy: restore speed from a fast primary copy says little about recovery from an immutable or isolated tier. Score BR-IR-05 on timed results only.
- Read "immutable" carefully: ask what an administrator, a bidder support engineer and the storage owner can each still do. Score a mechanism whose retention can be shortened by an administrator lower than one that cannot.
- Plan identity recovery first: without a working directory, restored applications cannot authenticate. Require BR-IR-02 if Active Directory is a Tier 1 dependency.
- Check data reduction claims: model Appendix B with no data reduction and with the bidder's claim, and prefer bids that guarantee capacity.
- Control proof-of-concept credentials: issue test accounts and production integration credentials that expire, record them and revoke them at the end.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Backup coverage and encryption (4.1) | CP-9, CP-9(8), SC-28 | PR.DS-11 |
| Immutability and isolated copies (4.2) | CP-9, CP-6 | PR.DS-11 |
| Control plane identity (4.3) | IA-2, AC-6 | PR.AA-05 |
| Clean restore and recovery (4.4, 4.5) | CP-10 | RC.RP-01, RC.RP-03 |
| Recovery testing (4.6) | CP-4, CP-9(1) | PR.DS-11, ID.IM-02 |
| Audit logging (4.6) | AU-2 | PR.PS-04 |
| Supplier assurance (5, 6) | SA-9, SR-6 | GV.SC-06 |
After award, carry requirement IDs into the statement of work and make the step 2 and step 4 tests part of acceptance and annual retesting. For the policy that governs the tool, use the Backup and Recovery Policy Template.
Standards and references
- CISA: #StopRansomware Guide
- NIST: SP 800-209 Security Guidelines for Storage Infrastructure
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Backup and Cyber Recovery Buyer's Guide · Ransomware Response and Recovery Guide · NIST IR 8374 Rev 1 Ransomware Risk Management Profile Guide · Security Vendor Evaluation and RFP Guide · SaaS Backup Buyer's Guide