Kubernetes Backup RFP Template (Free): Data Protection & DR

How to run a Kubernetes Backup RFP

A Kubernetes backup evaluation involves platform engineering, storage, security and the teams that own stateful applications. The proof of concept matters more than the written answers, because a restore either works on your clusters or it doesn't. The example schedule in this template runs about 10 weeks from kickoff to contract award; allow longer if you need to prove restores across several clouds or regions.

1. Take inventory and set protection tiers (weeks 1-2). List your clusters, distributions and Kubernetes versions, the namespaces and stateful applications to protect, the storage classes and CSI drivers behind them, and the volume of persistent data. Group applications into tiers with RPO, RTO and retention targets, and write down the recovery scenarios you must prove: a deleted namespace, a lost cluster, a region outage and a ransomware attack.
2. Assemble the buying team. Include platform engineering or SRE, the backup and storage team, security, the owners of your most important stateful applications (often the database team), and procurement and legal. Decide early who will own backup policies, a central team or the application teams themselves, because that shapes the RBAC and self-service requirements.
3. Decide whether you need an RFI first (weeks 2-3). If you haven't decided between extending your current backup platform and adopting a Kubernetes-native product, or your long list has more than five vendors, send a short RFI. Ask which distributions, Kubernetes versions and CSI drivers each vendor supports, whether the management plane is self-hosted or vendor-hosted, and how licensing is counted, then shortlist three or four vendors.
4. Tailor and issue the RFP (weeks 3-6). Delete requirements that don't apply, adjust priorities, and add your clusters, storage platforms and backup targets to Section 1. If you run several Kubernetes distributions or managed Kubernetes services, list each one with its version, so vendors confirm support for every one rather than in general. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
5. Score the responses (weeks 6-7). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' against the vendor's published support matrix, and note whether each feature is generally available today or still on the roadmap.
6. Run a proof of concept with two vendors (weeks 7-9). Use a non-production cluster and your real stateful applications. Delete a namespace and restore it, restore an application into a new cluster with a different storage class, try to delete backups using cluster-admin credentials, and time backups and restores at realistic data volumes. Check the resource footprint of the in-cluster components, and call a reference customer of similar size.
7. Negotiate and award (weeks 9-10). Use the pricing table to compare like for like, including how licenses are counted as clusters autoscale and for standby disaster recovery clusters. Settle the renewal cap, and exit terms that keep your backups restorable, before you sign.

Kubernetes Backup RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

Technical and architecture

Integration

Security and compliance

Implementation and support

Commercial and pricing

Questions to ask Kubernetes Backup vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

1. Demonstrate a backup of a stateful application (a database with its secrets, config maps and persistent volume claims) and its restore into a new, empty cluster. What, if anything, had to be recreated by hand?
2. How do you make databases consistent at backup time? Which databases have prebuilt hooks or templates, and what do you recommend for one that doesn't?
3. Which CSI drivers and storage platforms have you validated for both snapshot and restore? How do you back up volumes whose driver can't take snapshots, and what privileges does that need?
4. How soon after a new upstream Kubernetes minor release do you support it on each distribution we run? Give the support dates for the last three releases.
5. How do you restore an application that an operator or a GitOps controller manages, without the controller and the restore working against each other?
6. What happens during a restore when the target cluster has different storage classes, a different Kubernetes version or a different image registry? Which transformations are built in, and which need scripting?
7. If the cluster running your software, or your management plane, is lost, how do we get back to our backups? Show us.
8. An attacker gains cluster-admin rights on a protected cluster. Which backups can they delete, encrypt or expire early, and what stops them?
9. How does your retention setting interact with object lock on the backup target, and what happens when the two conflict?
10. Show a disaster recovery plan that brings [number] applications up in a set order on a standby cluster in another region. How do you measure and report the recovery time achieved?
11. What do you detect in backup data or backup activity that may signal ransomware or mass deletion, and how do you help us find the last clean restore point?
12. Which in-cluster components need privileged or host-level access, and what CPU, memory and storage do they use at our scale?
13. How do you count licenses for clusters that autoscale, short-lived clusters, non-production clusters and standby disaster recovery clusters?
14. Which features in your proposal are generally available today, and which are in preview or on the roadmap? Give dates for the roadmap items.
15. Provide a reference customer with a similar number of clusters that has restored an application to a different cluster or cloud in production.

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Scoring scale

• 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
• 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
• 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
• 2 Weak: misses one or more Must-haves, or the answer is vague.
• 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should a Kubernetes backup RFP include?

Your environment (clusters, distributions, storage platforms, CSI drivers and stateful applications) and protection tiers with RPO, RTO and retention targets; requirements for application-consistent backup, CSI snapshots, restore granularity, cross-cluster restore and migration, immutability, encryption, RBAC and policy-as-code, each marked Must-have or Nice-to-have; questions that make vendors demonstrate restores; support and pricing terms; and the rubric you'll score with. This template includes all of them.

Do you need Kubernetes backup if you use GitOps?

Yes, for anything stateful. Git holds the desired state of your manifests, but not the data in persistent volumes, secrets you keep out of Git, or resources that operators and controllers create at runtime. Rebuilding from Git also doesn't give you a point-in-time copy to roll back to after data corruption or ransomware. The two work together: keep your backup policies in Git as well, and use backups to recover data and whole applications.

Is a CSI volume snapshot a backup?

Not on its own. A CSI snapshot usually stays with the storage system or cloud account that holds the original volume, so it can be lost or compromised along with them. It's a fast way to capture a consistent point in time; a backup platform should then copy that data to a separate, preferably immutable target, together with the Kubernetes resources needed to restore the application.

Can existing backup software protect Kubernetes, or do you need a dedicated tool?

Either can work. Some general-purpose backup platforms include Kubernetes protection, and some products are built only for Kubernetes. Send this RFP to both kinds and score them against the same requirements, paying particular attention to application consistency, restore into a new cluster, support for your distributions and CSI drivers, and how policies fit your GitOps workflow.

How long does a Kubernetes backup RFP take?

The example schedule in this template runs about 10 weeks from kickoff to contract award, including three weeks for vendor responses and about three weeks for a proof of concept. Allow more time if a short RFI comes first, or if you need to prove restores across several clouds or regions.

Further reading

• Kubernetes Backup in 2026: Kasten, Portworx, or Velero?
• Kubernetes Backup in 2026: Veeam Kasten vs. Rubrik

Related RFP templates

• Immutable Backup and Cyber Recovery Vault RFP Template
• Backup Software RFP Template
• Disaster Recovery as a Service (DRaaS) RFP Template