Attackers who reach the backup platform can delete or encrypt backups before deploying ransomware, so a product chosen for convenient file restores can fail exactly when it is needed most. Products differ less in whether they copy data than in whether those copies survive a privileged attacker, whether you can find a clean restore point and how fast a whole estate comes back. This vendor-neutral guide is for infrastructure, security and resilience leads running an RFP for backup software, appliances, backup as a service, cloud-native or SaaS backup: what to define, what to score, what to ask and a proof of concept that tests recovery rather than backup. For architecture and hardening of what you already run, see the Backup Security and Immutable Backup Guide.
Key takeaways
- Buy for recovery, not for backup. Score measured restore time at your scale, finding the last clean recovery point and orchestration, not backup speed or deduplication ratios.
- Immutability has to survive an administrator. Ask whether retention can be shortened or recovery points deleted by anyone with console or API access, including the vendor and a cloud account root user, and whether the lock is reversible.
- Isolation is a design property, not a label. A vault in the same account, domain and identity provider as production is not isolated.
- The backup platform is a privileged non-human identity. Its service accounts and API keys reach every hypervisor, database and SaaS tenant you protect, so score how they are scoped, stored and monitored.
- Test restores in the proof of concept. Seed test malware, destroy the lab copies and time a full recovery against your recovery time objectives.
Define requirements
Recovery objectives should come from the business, not the product. Agree these before talking to vendors.
- Recovery objectives by tier: recovery time objective (RTO), recovery point objective (RPO) and maximum tolerable downtime for each service tier, taken from a business impact analysis of the kind NIST SP 800-34 describes. Include identity services (Active Directory, Entra ID, DNS), which must come back first. See the Business Continuity and Disaster Recovery Guide and the Identity Recovery Guide.
- Estate in scope: hypervisors and virtual machines, physical servers, databases, file shares, Kubernetes, cloud workloads, object storage and SaaS applications (collaboration suites, CRM, source code repositories), plus golden images and infrastructure as code templates, which the CISA #StopRansomware Guide advises maintaining, with templates backed up offline.
- Cyber recovery scenario: assume an attacker with domain admin and cloud administrator rights, present for weeks, who has deleted or encrypted primary backups. Write requirements for recovery from that position.
- Retention and compliance: retention periods by data class, legal hold, deletion obligations and any record-keeping rules. CISA warns: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations", so check that locked retention does not conflict with erasure duties.
- Control obligations: NIST CSF 2.0 PR.DS-11 ("Backups of data are created, protected, maintained, and tested"), RC.RP-03 ("The integrity of backups and other restoration assets is verified before using them for restoration") and RC.RP-05; CIS Controls v8.1 Control 11 Data Recovery, Safeguards 11.1 to 11.5, including 11.3 (protect recovery data), 11.4 (isolated instance of recovery data) and 11.5 (test data recovery); ISO/IEC 27001:2022 Annex A 8.13 (information backup) and 5.30 (ICT readiness for business continuity); and NIST SP 800-209 on storage data protection, isolation and restoration assurance. Ask which reports evidence these.
| Delivery model | Strengths | Trade-offs to test |
|---|---|---|
| Backup software on your own infrastructure | Broad workload coverage, control over storage targets and data location | You harden and patch the servers, proxies and repositories; isolation depends on your design; backup servers often joined to the production domain |
| Integrated backup appliance | Hardened operating system, built-in immutable storage, simpler operation | Capacity planning and refresh cycles; vendor-controlled support access; check what "hardened" removes (shell, remote management) |
| Backup as a service | Copies outside your identity and network boundary by default; no infrastructure to run | Restore speed over the network for large volumes; vendor platform security becomes yours; egress and retrieval charges |
| Cloud provider native backup | Deep integration, policy-based protection, native vaults with locked retention | Same provider and often the same organisation as production; coverage differs by resource type; separate tooling per cloud |
| SaaS application backup | Point-in-time restore of mailboxes, sites, records and repositories beyond native retention | Coverage of objects and metadata varies widely; the backup holds an app registration with broad read access to the tenant |
Size changes the answer. A small organisation can often meet its objectives with backup as a service plus SaaS backup, provided the admin console and service accounts are locked down. A large enterprise usually needs a primary platform for fast operational restores, a logically isolated vault with separate credentials and an isolated recovery environment where restored systems are checked before they rejoin the network. Mixed models need named owners for the gaps between them.
Evaluation criteria
Weight these to your requirements. An illustrative split is 25% immutability and isolation, 20% recovery speed and orchestration, 15% identity and administrative controls, 15% clean recovery (scanning and integrity), 15% coverage, 10% platform security and cost; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Immutability | WORM or object lock enforced by the storage layer; locked retention that no administrator, vendor engineer or cloud root user can shorten; soft delete for recovery points and whole vaults; retention set by time period rather than a number of copies | "Immutable" means a software flag an admin can switch off; retention reducible from the console; immutability only on some storage tiers |
| Isolation and vaulting | A copy in a separate account, tenant or site with its own identity plane; offline or logically air-gapped vault; replication that a production administrator cannot reach or reconfigure | Vault in the same cloud account or Active Directory domain as production; "air gap" that is only a network rule managed from production |
| Administrative controls | MFA on every console and API; multi-person approval for destructive actions (delete, retention reduction, disable immutability, change encryption); role separation between backup operators and security; local accounts independent of the production directory | Single global admin role; approvals that the same admin can grant; console authenticated only through the production identity provider |
| Anomaly detection and alerting | Alerts on mass deletion, stopped jobs, retention or encryption policy changes, admin account changes and unusual change rates or entropy in backed-up data; delivery to SIEM and an out-of-band channel | Alerts only in the backup console; no alert when backups simply stop |
| Clean recovery | Malware and indicator scanning of recovery points; a way to find the last clean point per system; integrity verification before restore; restore into an isolated environment | Scanning only at backup time with yesterday's signatures; no way to search recovery points for an indicator of compromise |
| Recovery orchestration and speed | Runbooks in dependency order (identity, DNS, databases, applications); parallel restores; instant mount for virtual machines; measured throughput at your scale | Speed quoted for a single VM; one-at-a-time manual recovery |
| Coverage | Every workload in scope, including SaaS metadata (permissions, versions, sharing), Kubernetes state and application-consistent databases | SaaS permissions and configuration not restored |
| Encryption and keys | Encryption at rest and in transit; customer-managed keys held outside the production account; key backup out of band; documented behaviour if a key is disabled or deleted | Keys stored on the backup server; no answer to "what if the key is deleted?" |
| Testing and reporting | Scheduled automated restore tests of latest and random recovery points, with restore duration reported against RTO | "Job succeeded" treated as proof of recoverability |
| Platform security and cost | Published advisories with fast fixes; audit log of admin actions; transparent pricing for storage, egress, retrieval and scanning | No advisory history; restore and egress charges discovered during an incident |
Provider documentation shows the level of detail to demand. In AWS Backup Vault Lock, governance mode can be removed by users with sufficient IAM permissions, while compliance mode becomes immutable after a grace time of at least three days and prevents early deletion even by the root user; a logically air-gapped vault is always compliance-mode locked and can be shared to, and restored from, a separate account. For Azure Backup, Microsoft states that "Immutability locking is irreversible" and that "Immutability doesn't apply to operational backups for resources like blobs, files, and disks", so snapshots beside the source are not your immutable copy; soft delete keeps deleted data for 14 to 180 days. Google Cloud describes its backup vault as providing "isolated, immutable, and indelible storage", where after the lock "no one (not even a Project Owner) can decrease the retention period". Ask each vendor to show the equivalent setting and who can change it.
The NCSC's principles for ransomware-resistant cloud backups are worth putting into the RFP verbatim, starting with "Backups should be resilient to destructive actions"; the NCSC adds that exceptions to blocked destructive requests should be authorised out of band, so an attacker must compromise a second system. For clean room design and recovery sequencing, see the Ransomware Response and Recovery Guide.
Where identity fits
Backup platforms hold some of the most powerful non-human identities in the estate: service accounts with administrator rights on hypervisors and databases, cloud roles that can snapshot every resource, app registrations with tenant-wide read access to SaaS data, and API keys for scripts. Score how the product scopes these, where it stores them and whether you can rotate them without breaking jobs. The Commvault Metallic breach shows the risk on the vendor side: an attacker in a backup service's cloud environment reached customers' Microsoft 365 app secrets. Backup copies are a target too: in the LastPass breach, stolen DevOps secrets unlocked cloud backups, and in the GoTo breach encrypted backups were taken together with their key. For administrators, the NCSC advises that "backup accounts and solutions should be protected using Privileged Access Workstations (PAW)" and that "the MFA method should not be installed on the same device that is used for the administration of backups". Native multi-person controls show what to ask for: Azure Backup multi-user authorisation places a Resource Guard, ideally in a different subscription or tenant, in front of disabling soft delete and, optionally, operations such as reducing retention or disabling immutability, and backup admins hold no rights on it. See the Service Account Security Guide, the Privileged Access Management Guide and the Secrets Management Guide.
Questions to ask vendors
- Which actions can delete a recovery point or shorten retention before expiry, who can perform them (our admins, your support staff, a cloud root user) and what approval does each need? Show it.
- Is immutability enforced by the storage layer or by your software, is the lock reversible, and does it cover every storage tier and snapshot type we would use?
- Where does the isolated copy live, which identity provider and credentials control it, and what can a domain admin or cloud administrator in our production environment do to it?
- What credentials does the platform hold for each workload and SaaS tenant, with what permissions, where are they stored and how are they rotated? Can it use short-lived federated credentials rather than static keys? See the API Key Management Guide.
- How do we find the last clean recovery point for a given server after a compromise that started weeks ago, and can we search recovery points for a file hash or other indicator?
- What restore throughput have you measured at our scale, and how do runbooks handle dependency order across hundreds of systems?
- For each SaaS application on our list, which objects, metadata and permissions do you restore, and what is not covered?
- What happens to our backups if our encryption key is deleted, our cloud account is suspended or your company stops trading?
Red flags
- Immutability that a single administrator, or vendor support, can disable or bypass by reducing retention.
- An "isolated" vault administered through the same directory, accounts and MFA as production.
- Backup servers or proxies that must be domain joined with domain admin rights, or service accounts that need standing global administrator access to SaaS tenants.
- Recovery claims based on single-VM demos, with no tested bulk restore figures.
- No malware scanning or integrity checks on recovery points, so you restore the attacker with your data.
- Snapshots in the same account presented as the ransomware copy. In the Codefinger S3 ransomware campaign, stolen keys were enough to encrypt buckets in place.
- No published security advisory history, or slow patches for internet-facing backup components. The NCSC advises patching backup products so attackers cannot exploit known vulnerabilities.
Proof of concept
- Scope it: one hypervisor cluster or cloud account, a production-like database, a file share, one SaaS tenant and a domain controller, all in an isolated lab. Agree pass criteria, RTO and RPO targets and weights before the first demo.
- Connect with least privilege: create dedicated service accounts and app registrations with named owners, record every permission each requests, and store their credentials in your secrets manager or PAM tool.
- Attack the backups: with a test administrator account, try to delete recovery points, shorten retention, disable immutability and change encryption. Record what was blocked, what needed a second approver and which alerts reached the SIEM.
- Seed and scan: plant benign test malware files (such as the EICAR test file) and a known file hash in older recovery points, then ask the product to find the last clean point for each system.
- Recover at scale: destroy the lab production copies and run a full recovery into an isolated environment in dependency order: identity first, then core databases, then applications. Time each step against RTO and check data currency against RPO.
- Restore SaaS: delete mailboxes, sites, records and permissions in the test tenant, restore to a point in time and check metadata and sharing came back.
- Measure cost: capture storage, egress, retrieval and scanning charges and extrapolate to a full-estate recovery.
- Roll back: remove the test service accounts, app registrations and keys, confirm jobs stop, and get written confirmation that trial data held by the vendor has been deleted.
Carry these measures into production: share of in-scope systems with a successful backup in 24 hours and an immutable or isolated copy; restore test pass rate and restore time against RTO per tier; time to detect a backup deletion or policy change; age of the oldest unrotated backup credential; and people able to take destructive backup actions without a second approver. Prevention controls upstream of the backup platform are covered in the Ransomware Prevention Guide.
How NHI Mgmt Group can help
We provide independent market analysis, requirements definition and RFP support for backup and cyber recovery programmes, including how backup service accounts, app registrations and API keys are governed. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Ransomware Response and Recovery Guide · Business Continuity and Disaster Recovery Guide · SaaS Security Buyer's Guide · PAM Buyer's Guide