Most disaster recovery plans get tested once a year, on a Saturday, with someone from IT quietly hoping nothing breaks. Then a ransomware operator encrypts the primary environment on a Tuesday afternoon and the team discovers the backups they were counting on were reachable from the same domain the attacker just owned. We've walked into that exact postmortem more than once. The tooling wasn't the problem. The architecture around it was.
Backup and disaster recovery used to be treated as the same conversation. They aren't anymore. A nightly backup job that succeeds every night for two years tells you almost nothing about whether you can actually bring a business back online after a coordinated attack that specifically targets your recovery infrastructure first. Modern ransomware groups do exactly that: they sit inside a network for days or weeks, map out backup repositories and domain controllers, and disable or encrypt recovery paths before triggering the main payload. If your DR design assumes a clean, cooperative failure — a disk array dying, a data center losing power — it will not hold up against an adversary who read the same architecture diagrams you did.
Recovery point and recovery time targets have to be set per workload, not per company
One of the most common gaps we find during a DR assessment is a single company-wide recovery time objective (RTO) and recovery point objective (RPO), applied uniformly across systems that have nothing in common. A core banking ledger and an internal wiki do not deserve the same four-hour RTO. Setting realistic targets means classifying systems into tiers first:
- Tier 0 — revenue and safety critical. Payment processing, authentication services, SCADA/OT control systems. RPO measured in seconds to minutes, RTO in minutes to low single-digit hours, usually backed by active-active or hot-standby architecture.
- Tier 1 — core business operations. ERP, CRM, primary databases. RPO in minutes, RTO in hours, typically warm-standby with automated failover.
- Tier 2 — supporting systems. Internal tools, reporting, non-customer-facing services. RPO in hours, RTO in a day or less, cold or pilot-light recovery is often acceptable.
- Tier 3 — archival and low-impact. Historical logs, decommissioned-but-retained data. RPO in days, RTO flexible.
Getting this classification wrong in either direction is expensive: over-tiering everything as Tier 0 burns budget on replication and standby capacity you don't need, while under-tiering a system that turns out to be a hidden dependency for something critical (a licensing server, an internal DNS resolver, an identity provider) turns a two-hour outage into a two-day one.
The 3-2-1-1-0 rule, and why the extra "1" matters more than people think
The old 3-2-1 backup rule — three copies of data, on two different media types, one offsite — was written before ransomware routinely went after backup infrastructure directly. The updated version we design against is 3-2-1-1-0: three copies, two media types, one offsite, one copy that is immutable or air-gapped, and zero verified errors on recovery testing.
The immutable or air-gapped copy is the one most environments still skip. It means a backup repository that cannot be modified or deleted even by an administrator account that's been compromised — object-lock storage with a retention policy set at the bucket level, a tape rotated out of network reach, or a backup vault on a separate identity domain with no trust relationship to production Active Directory or Entra ID. If your backup admin credentials and your production domain admin credentials trace back to the same identity provider, an attacker who gets one gets both.
Identity recovery deserves its own runbook
Restoring virtual machines and databases is the part of DR that gets rehearsed. Restoring identity — Active Directory, Entra ID, Okta, whatever ties authentication and authorization together — is the part that gets skipped, and it's usually the actual bottleneck during a real incident. If your domain controllers are encrypted along with everything else, you cannot log into the systems you just restored until identity comes back first. We build identity recovery as its own numbered step in every DR runbook we write, with its own tested restore path, isolated from the primary domain until it's confirmed clean.
This is also where a lot of current DR platform development is focused. Vendors across the space — Veeam, Rubrik, Commvault, Cohesity, and others — have all shipped identity-aware recovery features over the past two years specifically because customers kept restoring servers into environments where nobody could authenticate to them. That's not a coincidence; it's a direct response to how ransomware recovery actually fails in practice.
Clean recovery testing: restore into isolation before you restore into production
A recovery point that "looks" clean and a recovery point that is clean are different things. Modern DR practice — and modern DR tooling — increasingly builds in a step where you restore into an isolated, network-segmented environment first, scan it for indicators of compromise, and only then promote it to production. Skipping this step is how organizations have re-infected their own recovery environment mid-incident, restoring a backup that already contained the attacker's persistence mechanism.
DR maturity levelWhat it looks likeTypical gap
Backup-only
Nightly backups exist, no formal DR plan or documented RTO/RPO
No tested recovery path; RTO is "however long it takes"
Documented, untested
DR plan exists on paper, backups are offsite
Never actually restored end-to-end; identity recovery not addressed
Tested, not isolated
Annual or semi-annual DR test, restores succeed
Restores go straight into production network without IOC scanning
Resilient
Immutable/air-gapped copies, tiered RTO/RPO, isolated clean-room recovery, identity restored as its own step, quarterly testing
Ongoing cost and process discipline to maintain
Multi-cloud and hybrid recovery adds a coordination problem, not just a technical one
We're seeing more DR designs span AWS, Azure, and GCP simultaneously, which solves the single-provider-outage risk but introduces a coordination problem: replication tooling, IAM models, and network architectures differ enough between providers that a DR runbook written for one cloud rarely transfers cleanly to another without real rework. Terraform and other infrastructure-as-code tooling help here more than any single DR product does, because a documented, version-controlled infrastructure definition is itself a recovery asset — you can rebuild the target environment from code rather than relying entirely on image-based restores, which is often faster and gives you a known-good baseline to restore data into.
How often should you actually test a DR plan?
Annual testing is the default most organizations settle into, largely because a full failover exercise is disruptive and expensive to run more often. It's also not enough on its own. A yearly full-scale test tells you the plan worked once, under conditions your team controlled and scheduled around. It doesn't tell you whether the plan still works after six months of infrastructure changes, new applications, and staff turnover that nobody updated the runbook to reflect.
The pattern we recommend, and the one we build into DR programs for regulated clients, layers three types of testing at different frequencies:
- Tabletop exercises, quarterly. No systems are touched. The incident response and infrastructure teams walk through a scenario — ransomware hits the primary data center, or a cloud region goes dark — and talk through exactly who does what, in what order, referencing the actual runbook. This catches stale contact lists, unclear ownership, and steps that assume a person who no longer works there.
- Component-level recovery tests, monthly or per major change. Restore a single critical database or application from backup into an isolated environment and validate it boots and serves data correctly. This is cheap enough to run frequently and catches backup corruption or configuration drift long before a real incident would.
- Full failover exercise, annually or semi-annually. The complete cutover, including DNS/traffic redirection and identity recovery, executed end-to-end. This is the only test that validates the full RTO number is realistic rather than theoretical.
Skipping the middle tier — the frequent, low-cost component tests — is the most common corner-cutting we see, and it's the one that causes the most surprises during a real annual test, when three separate backup jobs turn out to have been silently failing for months.
What we check in a DR readiness assessment
When we run a disaster recovery assessment for a client — banking, telecom, or critical infrastructure environments in our own engagement history — the checklist looks roughly like this:
- Are RTO/RPO targets set per system tier, or is there one number for everything?
- Is there at least one backup copy that is genuinely immutable or air-gapped from production identity?
- Is identity/directory recovery documented and tested as its own step, separate from data restore?
- Has a full recovery been tested end-to-end in the last twelve months, including a restore into an isolated network segment first?
- Are infrastructure definitions (Terraform, Ansible, or equivalent) version-controlled and usable to rebuild environments independent of image backups?
- Does the DR plan account for the specific compliance regime the business operates under — PCI-DSS for payment environments, ISO 27001 controls for information security management, NIST CSF for critical infrastructure?
Most environments we assess pass one or two of these on the first review. That's normal. DR maturity is built incrementally, and the highest-leverage fix is almost always the identity isolation piece, because it's the one attackers exploit most reliably and the one most plans leave out entirely.
Aydahwa's Disaster Recovery and Resilience Services
Aydahwa Enterprise designs and implements disaster recovery architecture for regulated and high-availability environments — dual-site primary and DR failover for critical infrastructure programs, encrypted multi-region backup for banking and payments platforms under PCI-DSS and ISO 27001, and hybrid-cloud recovery designs spanning AWS, GCP, and Azure. Our engagements typically start with the readiness assessment checklist above, applied against your actual environment rather than a generic template.
If you want a second opinion on whether your current DR plan would survive an attack that specifically targets your backups first, request our free cybersecurity self-assessment or work through the readiness checklist to see where the gaps are before an incident finds them for you. For a full DR architecture review or hybrid-cloud migration and resilience engagement, get in touch with our team — and if you'd like practitioner-level breakdowns like this one delivered directly, subscribe to the Aydahwa newsletter for future architecture guides, incident case studies, and compliance updates as they're published.
