If the policy answer to “how often do you test disaster recovery?” is “annually,” it matches the floor auditors and regulators ask about, and not much more. One test a year says little about how a real restore will go under pressure. The best-known rule here is also more specific than a one-line summary suggests: DORA, Regulation (EU) 2022/2554, has applied since January 17, 2025, requires yearly tests of the ICT systems behind critical or important functions at financial entities other than microenterprises, and reserves threat-led penetration testing every three years for the entities that competent authorities identify.
This brief sets out a starting cadence by workload tier, explains why the annual compliance-style test tends to produce the restore-time surprise it is supposed to prevent, and walks through the non-disruptive testing tooling from Veeam, Zerto, Commvault and DRaaS providers such as Expedient that makes testing more often than once a year practical.
What changed
Two things. First, regulation got specific. DORA’s Article 64 says: “It shall apply from 17 January 2025.” Article 24 requires financial entities “other than microenterprises” to run a resilience testing programme and to “ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions”: the systems themselves, not only the DR plan as a document. Article 25 lists test types from “scenario-based tests” to “end-to-end testing” and gives microenterprises a risk-based approach instead.
Article 26 adds threat-led penetration testing (TLPT), but not for everyone. Competent authorities “shall identify financial entities that are required to perform TLPT,” based on impact, financial stability concerns and ICT risk profile; microenterprises and the entities under Article 16(1)’s simplified framework are excluded. An identified entity must run TLPT “at least every 3 years,” the authority may ask it to “reduce or increase this frequency,” and each test “shall be performed on live production systems supporting such functions.” In EU financial services, “we have a DR plan” does not answer a request for test evidence.
Second, the testing itself got cheaper. A traditional full DR test meant a weekend, a change freeze and a conference bridge full of tired people. Today Veeam boots backups in an isolated lab on a schedule, Zerto runs failover tests while replication continues, and Commvault offers cleanroom sites for rehearsal. The cost argument for annual-only testing is far weaker than it was.
The takeaway for the meeting: regulators set the floor, and tooling has cut the cost of exceeding it. Annual-only testing is a choice, and an increasingly hard one to defend.
The cadence answer, by tier
Cadence should follow workload tier, not the audit calendar. The table is Enterprise Techie’s suggested starting point, not an industry benchmark: no rule cited here sets intervals by tier. NIST SP 800-34 Rev. 1 scales the exercise to impact level, up to a full-scale exercise with “a system failover to the alternate location” for high-impact systems, and leaves frequency “organization-defined.” The tiers match the RTO and RPO tier guide.
| Automated validation | Non-disruptive failover test | Full-scale exercise | |
|---|---|---|---|
| Tier 1 (revenue-critical) | Daily/nightly | Quarterly | Annually |
| Tier 2 (important, hours of tolerance) | Weekly | Twice a year | Annually |
| Tier 3 (deferrable) | Monthly | Annually | Sampled in the annual exercise |
| DORA-regulated critical or important functions | Not set by DORA | Appropriate tests at least yearly on all supporting ICT systems; test type not specified (Art. 24(6), entities other than microenterprises) | Response and recovery plans tested at least yearly, with switchover scenarios for entities other than microenterprises (Art. 11(6)); TLPT at least every 3 years only for entities identified under Art. 26(8) |
Diagnostics: if your tier-1 systems have never had a failover test outside the annual exercise, you are running on faith, not a recovery capability. If your automated backup validation is “the job completed successfully,” you have no validation at all: a completed job proves the backup wrote, not that it restores. And if the only person who has ever executed the runbook is the person who wrote it, your real single point of failure is a human.
Why compliance-style tests lie
The restore-time gap opens when a test is designed to pass rather than to find failures. The annual exercise is announced months ahead. The scope is trimmed to what is known to work. The most experienced engineer drives. Dependencies that would complicate the result, such as DNS, authentication and the third-party API nobody owns, are declared out of scope. The test passes, the attestation is filed, and the actual recovery capability remains unmeasured. NIST SP 800-34 asks for the opposite: a test scenario that should “mimic reality as closely as possible.”
Now picture a hypothetical real event in the middle of the night on a weekend. The senior engineer is on a plane. Active Directory comes up after the applications that depend on it. The restore that looked quick in the test runs far longer, because the test restored one application and the incident requires dozens, all contending for the same backup infrastructure. None of this requires bad luck. It is the predictable output of a test designed to produce a green checkmark.
Failure-style testing inverts the design: unannounced windows, second-string operators, deliberately broken dependencies, restore-at-scale rather than restore-one-VM. It produces uglier reports and a more honest measure of recovery. The verdict is simple: a DR test that cannot fail is not a test.
The tooling that removes the excuse
Veeam approaches testing through automated validation. SureBackup starts machines from backup in an isolated virtual lab, runs heartbeat, ping and application tests, and can run “automatically by schedule”; its application group first starts dependencies such as a domain controller and DNS server “in the required order.” Paired with Veeam Recovery Orchestrator for “one-click recovery plans for critical applications” and scheduled plan tests, it turns “did the backup work” into a routinely answered question. The honest limits: SureBackup proves machines recover from backup, not that a whole business service fails over across sites, and Recovery Orchestrator’s documented targets are vSphere, Azure and Hyper-V. It fits organizations that want continuous restore assurance from the backup platform they already run.
Zerto, now sold as HPE Zerto Software, approaches from the replication side: journal-based recovery on top of near-synchronous replication of every write. Its Failover Test operation creates test VMs “in a sandbox,” and “replication of the protected machines continues throughout the test,” so frequent tests don’t need a change-board fight. Where it is strong: tier-1, low-RPO workloads where you need to prove recovery to a recent checkpoint on demand. Where it is not: it is a replication product, not a backup platform, and “All packages are licensed per VM,” per Zerto’s license documentation, so the economics favor reserving it for the top tier.
Commvault aimed its testing story at the cyber scenario. Its Cleanroom Recovery environment “supports continuous testing, forensic analysis, and recovery,” including validating domain controllers “before bringing dependent applications back online,” and cleanroom sites can run in AWS, in Azure or fully on premises. That maps onto the post-ransomware question, whether you can restore clean, and it complements an isolated vault strategy; the cyber recovery vault comparison covers the vault side. The trade-offs: it presumes Commvault is already your data protection standard, and a cloud cleanroom runs on cloud capacity, so confirm how rehearsal time is billed before planning a frequent cadence.
Expedient represents the DRaaS answer: put recovery in a provider’s hands and make testing part of the service. Its DRaaS page lists “Guided testing,” an included runbook, and the ability to “Schedule testing and initiate failovers on your own timeline.” For teams without dedicated DR staff, a provider-assisted test can decide whether frequent testing happens at all. The limits are the DRaaS limits generally: every site on Expedient’s data center page is in a US city, which EU entities must weigh because DORA’s Article 30 requires contracts to state “the regions or countries” where services run and data is processed, and you are testing the provider’s runbook as much as your own. Test-failover inclusions differ by contract; the DRaaS pricing breakdown covers what to demand in the SLA.
What to do about it
- Publish a test calendar for the year with named owners: scheduled automated validation, regular tier-1 failover tests, and at least one full-scale exercise a year with an unannounced component.
- Rotate operators. If the same engineer runs every test, you are testing the engineer, not the capability. DORA’s Article 24(4) requires tests “undertaken by independent parties, whether internal or external.”
- Score tests on time-to-service-restored against your stated RTO, not on “completed or not completed.” Track the trend quarterly.
- If you are DORA-regulated, map every critical or important function to a dated test artifact; Article 24(5) also requires procedures to “prioritise, classify and remedy all issues revealed” by tests.
- Once a year, test at scale, with dozens of workloads contending for restore bandwidth, because that is the shape of a real event.
Frequently asked questions
How often should disaster recovery be tested?
As a starting point (Enterprise Techie’s suggestion): tier 1 gets quarterly non-disruptive failover tests, nightly automated backup validation and one full-scale exercise a year; tier 2 gets failover tests twice a year. Where a rule applies, once a year is the floor: CISA’s CPG 2.0 says “no less than once per year,” and DORA says “at least yearly.”
What does DORA require for resilience testing?
Since January 17, 2025, Article 24 has required financial entities other than microenterprises to test all ICT systems and applications supporting critical or important functions at least yearly; microenterprises follow Article 25(3)’s risk-based approach. Article 26 adds threat-led penetration testing at least every three years on live production systems, only for entities that competent authorities identify.
What is a non-disruptive DR test?
A test that exercises recovery, such as booting backups in an isolated lab or failing over to replicas on a test network, without touching production. Veeam SureBackup, Zerto’s Failover Test operation and Commvault Cleanroom Recovery are examples.
What should a DR test plan include?
Scope by tier, named operators and alternates, success criteria expressed as time-to-service-restored versus RTO, dependency order (identity and DNS first), an unannounced element, and a findings log with remediation owners and dates.
Enterprise Techie sends vendor-honest analysis like this once a week: get the brief by email, free.
Buying? Start from RFPhub’s free DRaaS RFP template.