Disaster recovery as a service (DRaaS) was designed for fires, floods and failed data centres, and many services faithfully replicate ransomware-encrypted or backdoored systems to the recovery site within seconds. DRaaS keeps copies of your servers continuously replicated to a provider or cloud region and lets you start them there, in an orchestrated order, when the primary site is lost. For a cyber incident you also need recovery points from before the compromise, an isolated environment to check them in, and recovery that does not depend on the identities the attacker controlled. This vendor-neutral buyer's guide is for infrastructure, resilience and security teams evaluating DRaaS. Backup, immutability and data protection are covered in the Backup and Cyber Recovery Buyer's Guide; this page covers replication, orchestration, clean room recovery, testing and contract terms.
Key takeaways
- Replication is not protection from ransomware. Continuous replication copies encryption and implants too; what matters is the depth and immutability of point-in-time recovery points and how far back you can go.
- Orchestration determines real recovery time. Recovery plans that sequence tiers, re-map networks and run scripts turn a pile of replicated disks into working services.
- A clean room is needed for cyber recovery. You must be able to start recovery points in an isolated network, scan and validate them, and only then promote them to production.
- Separate the control plane from your identity estate. If the DRaaS console uses the same directory and admin accounts the attacker took, the attacker can delete your recovery.
- Contract for tested outcomes. Service levels should cover recovery time per tier, drill frequency, capacity guarantees in a regional event and support during an incident, not only platform uptime.
Define requirements
- Tiered application list: each application with its recovery time objective (RTO), recovery point objective (RPO) and dependencies, taken from your business impact analysis. See the Business Continuity and Disaster Recovery Guide.
- Source platforms: physical servers, VMware, Hyper-V, other hypervisors, cloud instances, databases and SaaS that DRaaS will not cover and must be handled elsewhere.
- Scenarios: site loss, regional cloud outage, and ransomware or destructive attack, with the last requiring recovery from a known-good point after investigation.
- Target model: provider-managed DRaaS, self-service cloud disaster recovery in your own cloud account, or a hybrid; and who runs failover on the day.
- Change rate and bandwidth: daily data change per server and available network capacity, which bound achievable RPO.
- Retention depth: how far back you need clean recovery points, informed by how long intrusions typically go undetected in your environment.
- Regulatory and residency limits: where replicas may be stored and which regulators expect evidence of recovery testing.
Capability areas
| Area | What to look for |
|---|---|
| Replication | Continuous or frequent replication with stated intervals per platform, compression and bandwidth throttling, monitoring of replication lag and alerts when it breaks |
| Recovery points | Many point-in-time recovery points retained for days or weeks, application-consistent options for databases, protection from deletion by any customer or provider admin within a lock period |
| Orchestration | Recovery plans that group machines, set boot order, wait conditions, scripts and manual steps; network and IP re-mapping; DNS and load balancer changes |
| Clean room recovery | Isolated recovery network with no route to production, ability to run malware scanning and integrity checks on recovered machines, forensics access, controlled promotion |
| Testing | Non-disruptive test failover that does not pause replication, scheduled drills, automated reports with actual recovery times |
| Failback | Reverse replication to the rebuilt primary site, with change tracking so only differences are sent |
| Control plane security | Separate administrative identity, phishing-resistant MFA, multi-person approval for destructive actions, audit logs exported off-platform |
| Capacity and support | Guaranteed compute in a regional event, named contacts and incident support hours |
Recovery from a cyber attack also needs rebuilt identity systems before applications. See the Cloud Recovery and Clean Room Guide and Recovering IAM and PAM After Ransomware or Domain Compromise.
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Achieved RTO and RPO | Measured recovery times per tier within objectives, not vendor estimates | Run a timed failover of your tier 1 service | [20%] |
| Ransomware recovery | Deep, deletion-protected recovery points and an isolated clean room with scanning | Recover a seeded "infected" machine into the clean room | [20%] |
| Orchestration | Multi-tier service starts in correct order with network changes automated | Recover a three-tier application end to end | [15%] |
| Control plane security | Independent admin identity, MFA, approvals for deletion, off-platform logs | Try to delete recovery points as a single admin | [15%] |
| Testing and evidence | Frequent non-disruptive drills with reports usable for auditors | Schedule a drill and review its report | [10%] |
| Contract terms | Service levels on recovery outcomes, capacity guarantees, exit terms and data return | Legal and procurement review of the draft | [10%] |
| Cost | Clear charges for steady-state replication, storage, drills and actual failover compute | Model a year with four drills and one real failover | [10%] |
Weights are illustrative: set them before responses arrive.
Decision guidance: provider-managed DRaaS suits organisations without in-house DR skills or a second site, accepting dependency on the provider's people during an incident. Self-service cloud disaster recovery in your own cloud account gives more control and lower steady-state cost but leaves orchestration and testing to you. Organisations already running in one cloud often use cross-region replication native to that platform; the cyber requirements (clean room, protected recovery points, separate admin identity) still apply. Smaller organisations may find well-tested immutable backups with documented rebuild procedures meet their RTO at lower cost.
Questions to ask vendors
- What replication interval do you achieve for each of our source platforms, and how do you alert when replication falls behind?
- How many recovery points do you keep, for how long, and can anyone, including your own staff, delete them within the retention period?
- Show recovery of a machine into an isolated network, malware scanning of it, and promotion to production.
- How is your console authenticated, and can it be fully separated from our corporate directory?
- Which actions require more than one approver, and are console audit logs exportable in real time?
- How do you guarantee compute capacity if many customers fail over in the same regional event?
- What recovery times have customers of our size measured in drills, and can we see an anonymised drill report?
- What exactly do you do, and what do we do, during a declared disaster, and at what hours?
- How do we fail back, and how do we exit the contract and retrieve our data?
Red flags
- Recovery points measured in hours of retention, or only the latest replica.
- No way to test without pausing replication or affecting production.
- Console sign-in through your production identity provider only, with no break-glass path.
- Service levels that cover platform availability but say nothing about recovery time or capacity.
- Failover drills charged so heavily that you would run them rarely.
- "Clean room" meaning a separate subnet that still routes to production.
Proof of concept
- Protect one representative multi-tier application, including a database, from two source platforms.
- Measure initial seeding time, steady-state replication interval and bandwidth use over two weeks.
- Run a timed test failover using an orchestrated recovery plan and record actual RTO and data loss.
- Simulate a cyber recovery: select a recovery point from several days earlier, start it in the clean room, scan it, validate the application and promote it.
- Test control plane security: attempt recovery point deletion as a single administrator and confirm approvals and alerts fire.
- Fail back to the source and confirm only changed data is sent.
- Review the drill reports with your auditors and continuity team.
Agents, replication appliances and API keys used by the DRaaS service are non-human identities with broad access to your servers: inventory, scope and rotate them. See the Backup Identity Isolation Guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Backup and Cyber Recovery Buyer's Guide · Ransomware Response and Recovery Guide · Disaster Recovery Plan Template · Business Continuity Management Software