Digital Operational Resilience Act (DORA): How to Recover Cloud After an Incident

A misconfiguration takes a regulated trading platform offline at 09:00, the same way a cloud provider outage can. Under the Digital Operational Resilience Act (DORA), the company must prove it can recover. But restoring the database does not restore the live environment, so the RTO clock keeps running. This guide maps what EU DORA requires for Recovery, then shows how to recover cloud and SaaS configuration, not just data.

TL;DR

• The Digital Operational Resilience Act (DORA) requires financial institutions to prove they can recover critical ICT services within defined recovery objectives.
• Data recovery alone is not enough. IAM policies, DNS records, network settings, and SaaS configurations must also be recoverable to meet DORA requirements.
• Infrastructure as Code (IaC) is not a disaster recovery strategy. Cloud drift and manual changes often leave Terraform and OpenTofu environments out of sync with production.
• Digital operational resilience depends on recovering cloud infrastructure configuration, not just databases, workloads, and applications.
• ControlMonkey helps organizations meet DORA recovery requirements by continuously backing up cloud, identity, networking, and SaaS configurations.
• With ControlMonkey, teams can restore AWS, Azure, GCP, Okta, Microsoft Entra ID, Cloudflare, and other critical platforms from a known-good state.

What is the Digital Operational Resilience Act (DORA)?

The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554. It is an EU framework that requires Financial Sector Entities and their ICT Third-Party Providers to withstand, respond to, and achieve Recovery from any ICT Incident through strong ICT Risk Management, Incident Reporting, Digital Operational Resilience Testing, and Business Continuity measures. Solutions such as ControlMonkey help organizations strengthen operational resilience by protecting Cloud Configuration, SaaS Configuration, IAM Policies, Network Settings, and other critical systems needed for Infrastructure Recovery and restoration to a Known-Good State.

DORA was adopted on 14 December 2022 and entered into force on 16 January 2023. It has applied since 17 January 2025. So the obligations are live, not future.

Scope is broad. It covers around twenty categories of EU financial entity, including banks, insurers, and investment firms. DORA also reaches their critical ICT Third-Party Providers, including cloud and data-center providers, who now face direct EU oversight. If you run regulated infrastructure or supply it, you are in scope.

The regulation rests on five areas: ICT Risk Management, Incident Reporting, Digital Operational Resilience Testing, ICT third-party risk management, and information sharing. Of these, recovery and Business Continuity live inside ICT risk management. That is exactly where the configuration gap hides.

Digital Operational Resilience Act requirements for response and recovery

The Digital Operational Resilience Act (DORA) requirements that matter most for an engineering team sit in its ICT Risk Management provisions. ICT Risk Management includes both backup and Recovery, and Business Continuity depends on recovery working. This is the section that should drive how you plan, so let’s translate it into practice.

DORA’s response-and-recovery and backup obligations live in Articles 11 and 12 of Regulation (EU) 2022/2554. Article 11 requires a documented ICT business continuity policy plus response-and-recovery plans. Article 12 requires backup policies and restoration procedures. The plans must be tested at least yearly, and for all entities other than microenterprises the tests must include cyberattack and switchover scenarios.

DORA also expects a business impact analysis that sets quantitative recovery objectives. You define a Recovery Time Objective (RTO) and a recovery point objective per function, based on how critical that function is. RTO is simply your recovery-speed target: how fast a function must be running again after an incident. Then you have to demonstrate you can actually meet it.

Here is the honest implication. Meeting RTO is not about how fast you restore a backup. It is about how fast the whole environment, data plus configuration, is running again. Recovery reduces RTO only when it restores everything the function needs. This is where ControlMonkey fits. It reduces RTO by restoring the full environment from a known-good state. That is what strengthens Business Continuity under DORA.

Mapping DORA recovery requirements to your environment

So how do you turn these DORA recovery requirements into something concrete? Start by translating each obligation into an artifact you own. The continuity policy becomes a written plan. The BIA becomes a tiered list of functions with RTO targets, and the testing clause becomes a drill on the calendar. For a regulated trading platform, the continuity policy names who declares an incident, the BIA tiers the order-matching engine as tier-1 with a 1-hour RTO, and the testing clause puts a failover drill on the Q3 calendar. For the practical end of this, see our guide to building a cloud disaster recovery strategy. The point is to make recovery a process you can prove, not a promise you hope holds.

Can You Actually Prove DORA Recovery Readiness?

Most organizations can document recovery procedures. Far fewer can prove they can restore cloud infrastructure, identity systems, DNS, and SaaS configurations within their target RTOs.

👉 See how ControlMonkey helps teams continuously validate and recover critical cloud configurations.

Check Cloud DR Readiness

Why data backup alone fails the recovery test 

Here is the claim this whole article rests on. Data Backup restores your data, but not the Cloud Configuration and SaaS Configuration the data needs to run. That gap is what keeps you down.

Name the layers that go missing. Cloud Configuration includes your IAM Policies and the Network Settings that route traffic: VPCs, subnets, security groups, and load balancers. SaaS Configuration includes the Third-Party Integrations that wire your tools together. None of it comes back in a database restore.

Walk the failure mode with a fintech checkout flow. You restore the payments database in minutes. Good. But there are no IAM Policies granting the service access. No network path reaches it, and no connected SaaS integrations fire the webhooks. The data is back. The function is not. The RTO clock is still running, and the regulator still expects you to meet it.

Now the common objection: “we’ll rebuild from code, we’re 100% IaC.” Most live environments have drifted from their IaC. Someone made an emergency console change. An AI agent adjusted a permission. A third-party tool was wired in by hand. So the code no longer describes the running state, and rebuilding from it reproduces yesterday’s environment, not today’s.

This is precisely the problem ControlMonkey resolves. It complements Data Backup by continuously capturing a Known-Good State of the configuration that backups miss, so recovery restores the whole environment. An entity that can only restore data cannot credibly demonstrate it meets its DORA recovery objectives.

The diagram below shows where a data-only restore stalls, and what closes the gap.

How to recover cloud and SaaS configuration, not just data

Recovering configuration is a repeatable process, not a heroics-on-the-day scramble. Treat these five steps as the Digital Operational Resilience Act implementation work that turns the requirements above into a recovery you can run. They close the gap between a restored database and a running environment, getting the whole system back within RTO. ControlMonkey threads through the capture and restore steps as the engine that makes them reliable.

The diagram below shows how those steps fit together as one recovery workflow.

Step 1: Inventory the configuration your environment depends on

Catalog the Cloud Configuration and SaaS Configuration that recovery must restore: IAM Policies, Network Settings, and Third-Party Integrations. Then map dependencies for each critical function. Take a healthcare records backend. Write down which IAM roles, which subnets, and which SaaS connectors break the function if they go missing. That dependency map mirrors what DORA expects, and it tells you what a real recovery has to put back.

Step 2: Capture a continuously updated known-good state

Snapshot the live configuration continuously, so your recovery source reflects today’s environment, not stale IaC. ControlMonkey captures a Known-Good State of cloud and SaaS configuration as it changes, detecting drift and reconciling it as it happens. When an engineer changes a security group at 2 a.m., the captured state moves with it. The result is a recovery source you can trust, because it matches the running system rather than the version in your repo.

Step 3: Define recovery objectives for the whole environment

Set a Recovery Time Objective (RTO) and an RPO that cover configuration recovery, not just the data restore. This is the business impact analysis DORA expects. Decide tiering too. For a tier-1 payments service, write the RTO against full-environment recovery. The clock only stops when IAM, network, and integrations are back alongside the data. A target that measures the database alone hides the real downtime.

Step 4: Restore the full environment from the known-good state

Recover data and configuration together, so the environment comes back running, not just populated. ControlMonkey restores Cloud Configuration and SaaS Configuration alongside the data backup, rebuilding IAM Policies, Network Settings, and Third-Party Integrations from the captured state. When the original is compromised, restore into a clean or secondary environment. This is the heart of infrastructure disaster recovery for cloud and SaaS, and it is what turns a restore into a running service. To see how the full workflow fits a cyber-incident.

Step 5: Test and demonstrate recovery on a schedule

Run recovery drills at least yearly, and include cyberattack and switchover scenarios, as DORA’s testing clause requires. Keep records that show you met your RTO end to end, because that evidence is what regulators ask for. A documented annual drill that restores a full e-commerce environment within its RTO is exactly the proof DORA wants. For a working template, see how to build a cloud disaster recovery plan.

Building DORA-ready recovery into your operations

Two ideas carry this guide. DORA makes recovery a provable obligation, and Data Backup alone cannot meet it, because the configuration around your data goes missing. Restore the data and you are still down.

What closes the gap is recovering cloud and SaaS configuration from a continuously captured Known-Good State, so the whole environment comes back within RTO. That is how DORA compliance for Business Continuity stops being a paper exercise and becomes something you can demonstrate. ControlMonkey is the resilience platform that delivers the Infrastructure Recovery backups miss, restoring the environment rather than just the data.