A FinTech company had the disaster recovery plan every auditor wants to see: a two-hour RTO, multi-region redundancy and regular backups. Then an IAM misconfiguration triggered a cascading production outage.

The data backups were fine but the infrastructure-as-code was out of date. 

Reapplying old Terraform templates introduced conflicts, rollbacks failed, and the two-hour RTO turned into an eleven-hour recovery.

Under the Digital Operational Resilience Act (DORA), that gap is something an auditor can find. Here’s what DORA expects from recovery, what the ECB added in July 2026, why backups can't carry the load on their own, and how to recover the whole cloud environment.

TL;DR

  • DORA requires financial institutions to define their recovery objectives and prove they can meet them, with evidence, under realistic conditions.
  • In July 2026 the ECB asked every significant euro-area bank for an AI cyber action plan. The letter asks banks to assume breach and expects regularly tested recovery aligned with DORA.
  • A backup restores data. A running service also needs IAM roles, networking, Kubernetes secrets, load balancer rules, DNS and observability, and none of that lives in a database snapshot.
  • If your actual recovery time doesn't match your documented RTO, that gap is what an auditor will find.
  • Disaster Recovery-as-Code makes recovery a redeployment. Every layer is codified, so you can test recovery on demand and log every run.
  • Firefly rebuilds complete environments from code into a clean region or account and keeps audit-ready evidence for DORA, NIS2, SOC 2 and ISO 27001.

What is the Digital Operational Resilience Act (DORA)?

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is the EU regulation that holds financial institutions accountable for the resilience of their digital operations. For anyone running cloud infrastructure at a bank or investment firm, its practical meaning is blunt: untested disaster recovery plans no longer hold up. Regulators want proof that you can recover critical systems, repeatedly and under pressure.

Engineering teams know DORA as the DevOps metrics, one of which is mean time to recovery (MTTR). Regulatory DORA asks you to prove that number.

Two features set the regulation apart from the frameworks that came before it:

  • Accountability stays with you. If your cloud provider has an outage, or your backup vendor's tool goes down, regulators still expect you to recover. Vendor SLAs don't substitute for your own ability to come back. The ECB's July 2026 letter makes the same point: banks remain fully accountable for risks from outsourced ICT services.
  • Evidence beats documentation. A runbook that promises two hours is a claim. A tested, logged recovery is proof, and DORA asks for the proof.

What DORA requires for response and recovery

For the engineers who will do the work, DORA's recovery expectations come down to four obligations:

  1. Define specific RTOs and RPOs, and prove you can meet them.
  2. Test recovery plans regularly, not once a year.
  3. Demonstrate that you can migrate workloads if a cloud provider fails.
  4. Accept full accountability, with no pointing at cloud vendors.

The implication is clear: meeting an RTO depends on how fast the whole function is running again: data, infrastructure, identity, networking and every dependency between them. The clock stops when customers can transact.

Most organizations have never measured their real recovery time under production conditions. RTO is the number in the plan. MTTR is what happens between "everything is on fire" and "we're operational." DORA forces teams to find out what that second number is.

What the ECB added in July 2026

On 7 July 2026, the ECB wrote to every significant euro-area bank about AI-enabled cyber threats. Its point: AI is shrinking the time between finding a vulnerability and exploiting it. Each bank owes its Joint Supervisory Team an action plan by 31 October.

The letter says DORA's requirements remain highly relevant. It asks banks to assume the perimeter will be breached, and calls for regularly tested backup, failover, restoration and recovery aligned with DORA, including exercises for ransomware and cloud service disruption.

Mapping DORA recovery requirements to your environment

Each obligation should become an artifact someone owns, so you can show an auditor how recovery works.

Can you prove your DORA recovery readiness today?

Most teams can show a recovery procedure. Far fewer can show a validated RTO for a complete environment. If your perimeter is breached tomorrow, how fast can you rebuild your cloud, and when did you last test it?

Take the Cloud Resilience Assessment to see where your recovery gaps are.

Why data backup alone fails the DORA recovery test

A database snapshot is not a recovery plan. Backups protect your data, but when an outage hits, your services go down, and backups alone won't bring them back. That is where DORA compliance breaks.

The layers a backup never captures

Modern cloud applications are webs of microservices, Kubernetes clusters, IAM policies, networking rules, secrets and dependencies across more than one cloud provider. Your database is backed up. Now ask what happens to everything around it:

  • The IAM roles that grant services access
  • The VPC configurations that route traffic
  • The Kubernetes secrets
  • The load balancer rules
  • The DNS records
  • The observability stack that tells you whether recovery worked

Legacy backup tools capture state at a point in time. They don't capture the configurations, dependencies and policies that make an application function. When teams find this gap mid-outage, recovery turns into days of manual reconstruction from Slack threads and tribal knowledge.

Why rebuilding from Terraform isn't a plan either

The FinTech in our opening had infrastructure-as-code. It didn't help, because the code no longer described production. Runbooks drift out of date. Terraform configs stop matching what's running. Manual steps live in the heads of three people, and one of them has left the company.

IaC is the right foundation for recovery. Stale IaC is a liability: redeploying it rebuilds an environment that no longer exists.

The recovery category Gartner tracks: CAIRS

Gartner tracks this space as Cloud Application Infrastructure Recovery Solutions (CAIRS). The category covers tools that recover an application's infrastructure along with its data: configuration, service dependencies, access policies and network topology.

Bear in mind that if your recovery tool is built on your cloud provider's own tooling, it goes down when the provider does. DORA's accountability principle means you need to recover independently. Firefly runs as an independent control plane outside the failing environment, so recovery still works when the primary cloud doesn't.

How to recover the whole cloud environment

The answer is Disaster Recovery-as-Code. 

With it, every layer of your infrastructure becomes code: IAM policies, networking, Kubernetes manifests, service dependencies. All of it is version-controlled, tested and deployed through automated pipelines, so when disaster strikes, recovery is a redeployment. These five steps turn DORA's obligations into a recovery you can run on demand and defend in an audit.

Step 1: Discover everything into one system of record

You can't recover what you can't see. It's also where the ECB starts: identifying ICT assets is the first short-term priority in its July letter. Begin with a complete, real-time inventory across every cloud, account and region, plus Kubernetes and SaaS. Firefly scans your cloud into a live system of record, so the dependency map regulators expect comes from what's actually running.

Step 2: Codify every resource and keep the code honest

Turn every resource into deployable IaC, including the ones created by hand in a console. Then keep that code in sync with production: detect drift as it happens and remediate drift and policy violations, so nothing broken or out of date reaches the recovered environment. This is the step our FinTech skipped.

The same discipline lets you patch fast without breaking production, which the ECB expects banks to prepare for.

Step 3: Score recovery readiness and validate RTO before an incident

Set RTOs and RPOs against full-environment recovery, then check them continuously. Firefly's Cloud Resilience Posture Management (CRPM) scores recovery readiness, validates backups, replication, dependencies and failover paths, and exposes single points of failure such as a single-region dependency. You test the RTO in advance instead of assuming it.

Step 4: Recover the complete environment into a clean region or account

When an incident hits, rebuild the full environment from code: configuration, dependencies, networking and identity along with the data. Scope a backup from a single resource and Firefly discovers all of its dependencies, so nothing is missing at rebuild time.

You can roll back to a last-known-good state across regions and accounts. After a cyberattack, you can recover into a clean, isolated account from versioned IaC snapshots ransomware can't encrypt. Firefly restores complete environments in minutes.

Step 5: Test continuously and keep the evidence

DORA asks for regular testing and proof. With recovery codified, you can spin up a recovery environment on demand, validate it and tear it down, so the annual DR drill stops being an event.

The ECB's July letter names the scenarios worth rehearsing: ransomware or destructive attacks, broad compromise through zero-days, and supply chain or cloud service disruption. Build a recovery test for each.

Every change, test and recovery is logged by default. When regulators want evidence, your git history and recovery logs are the answer. Because you measure actual recovery time on every test, you can report real MTTR against your documented RTO.

The same codified environment covers DORA's exit-strategy requirement. Infrastructure that lives as code can be redeployed to another cloud provider if your primary one fails.

Building DORA-ready recovery into your operations

DORA makes recovery something you prove. A backup can't carry that proof on its own, because the configuration around your data is what keeps a service down.

The gap between your documented RTO and your real MTTR is fixable. Rebuild the complete environment, with every resource and dependency, from an immutable last-known-good snapshot into a clean region or account, and log every test and recovery. 

Teams that already work this way have evidence ready when supervisors and auditors ask, and every test they run adds to it.

The regulation is the wake-up call, but the still-open question is whether you answer it before your next outage or after it.

See how Firefly recovers complete cloud environments, or take the Cloud Resilience Assessment to find your recovery gaps first.

‍