How cloud adoption can accelerate your DORA roadmap

The Digital Operational Resilience Act (DORA) is a new EU regulation aiming to increase the resilience of the EU Financial Sector.

DORA is being enforced since 17 January 2025 and from the time of writing this article the entire EU financial sector is holding their breath to wait for the first audit of a financial institution to find out how this regulation is actually enforced.

DORA covers a long list of security and resilience requirements. Some of them being tablestakes for financial institutions for a long time, some of them being quite new and not that easy to implement.

Addressing concentration risks of critical suppliers as a systemic risk to the European financial sector is very new. Especially at the level of depth the regulator is expecting under DORA.

DORA and the Public Cloud — it’s not all downside

While there have been many articles written about DORA with plenty of recommendations on how to implement it, there isn’t all that much useful information out there about how DORA affects cloud(-native) environments.

At the same time, especially FinTech and InsurTech firms who are essentially “born” in the cloud and tend to make use of very advanced cloud-native technology stacks have very different demands on their cloud usage than 100-year old banking institutions that are currently in the middle of their 10-year cloud transformation.

In this paper (written in German), the German financial regulator BaFin is detailing how German financial institutions should manage risks in the cloud. As expected they’re focusing quite heavily on the third-party risk management aspect and the right to audit the Cloud Service Provider (CSP). The BaFin actually has a pretty good understanding of cloud-native processes and technology like DevOps and Infrastructure as Code. However, as you would expect from a regulator, they don’t focus all that much on the upside but primarily on the downside that come with cloud usage.

In this article, I want to highlight the incredible benefits your cloud adoption strategy can create in achieving DORA compliance. At the same time, I don’t want to ignore the downsides and break down a few of the issues I experienced when implementing DORA.

• The good — how cloud-native processes help achieve DORA compliance faster, more efficient and with better coverage

• The bad — where heavy reliance on CSPs makes implementation of DORA more difficult

The good — how cloud-native processes help implement DORA faster, more efficient and with better coverage

The public cloud and cloud-native technology offer incredible benefits when it comes to software delivery, financial planning and even operational security but what about compliance? Specifically how do these technologies help towards DORA compliance?

In my experience, there are many different capabilities that cloud-native technologies bring that help you meet your DORA obligations. I want to dive deeper into five specifically

1. Platformization of security for built-in resilience

2. Chaos Engineering and automated incident response

3. Redundancy and reliability

4. Change control and disaster recovery

5. Asset management and Information Domain automation

Based on my own analysis, these capabilities are ordered based on the leverage they provide towards achieving compliance. This does not consider costs of implementation though. For example, Redundancy and reliability are generally built-in for any cloud service you use and come essentially at almost no costs. Building a unified security platform that covers all your assets, is significantly more complex and costly.

Platformization of Security for built-in security

With this concept I’m aggregating various different security capabilities that are possible in the cloud. These include for example

• CI/CD pipelines with built-in vulnerability management and governance

• unified logging and observability

• compliance as code

All of these and other capabilities are ensuring certain security guardrails are applied to every single resource that is deployed in your environment. This doesn’t just allow for the automated integration of specific compliance requirements, it can also significantly reduce your risk management burden, by simply applying a uniformly high level of security across all your assets.

The largest number of DORA-related tasks you’re achieving with this approach are in the domain of Digital Operational Resilience Testing (excluding threat led penetration testing). Here you can ensure that almost all the necessary security tests are applied to all your assets across your entire cloud estate. This is primarily achieved by integrating security testing and governance capabilities into your CI/CD pipeline — so the process by which applications are built, tested and deployed.

Observability includes logging and monitoring but goes a step beyond. Well executed observability allows you to understand the state of a system through logs, metrics and traces — giving you greater insight and more ability to detect security issues.

In the cloud you have greater control over the observability framework you apply. This includes built-in logging functionality of every CSP, as well as your ability to standardize logging configurations through a CI/CD pipeline or very promising new(-ish) technology like eBPF-enabled service meshes.

Compliance as code is the ability to define secure configuration settings centrally for your entire cloud estate. This would allow you to centrally conduct certain hardening activities once and then actively manage any deviation.

Of course you can find equivalent capabilities outside the three major CSPs; however, the cloud offers you an economic advantage primarily through the level of control and coverage you can achieve.

This is where the huge compliance benefit comes from: Unified control over every single asset — no accidental deviations if you set it up correctly. A unified security platform achieves exactly that and you will find quite a few DORA requirements that are partially or entirely met through this approach.

Chaos Engineering and automated incident management

DORA is heavily focused on Operational Resilience — it’s in the name. So any capability around resilience testing, incident response, disaster recovery etc. are 1) something your regulator will closely look at, and 2) something where you can get incredible benefits from the cloud.

This and the following two sections will focus on these and related capabilities.

Chaos Engineering is a somewhat new security engineering discipline that can be described as regularly breaking running applications to test your capabilities to respond and recover.

Often, discussions about Chaos Engineering (CE) focus on the part where you break things, while the real benefits are in validating your automated recovery capabilities. It’s an approach to clarify the assumptions you have about the resilience of your systems and validate that they’re true.

Also the main focus for many experts and tools is on testing Kubernetes and CSP configurations or recovery capabilities. While this is beneficial, you can take this approach much further. Reading Kelly Shortridge’s Security Chaos Engineering, you can see many examples where CE can be used to test basic security assumptions. Such as how a firewall will behave under certain circumstances.

The cloud brings many capabilities to automatically respond to malicious or unwanted behavior — chaos engineering let’s you test that out, automatically and even in your production environment (if you’re so bold).

The related topic here is automated incident response — through the amount of control you can apply over your cloud estate, especially programmatically, you can automate many response activities that would normally require a forensics expert to execute them live.

As attackers have the advantage of knowing your cloud environment already largely in advance, they can automate attacks that they couldn’t have in on-premise environments. So waiting for your incident response team to detect and respond to an incident will no longer be sufficient. Therefore, you also need to leverage automation to detect and stop ongoing attacks. This is obviously a fairly advanced stage in your threat detection and incident response maturity curve; however, there are many ways to start small and automate certain activities like forensic imaging and isolating affected resources.

Also here — the cloud brings the ability to apply control over 100% of your assets, which achieves DORA compliance on a different level than in traditional environments.

Redundancy and Reliability

Redundancy and reliability are one of the major built-in benefits of the major cloud service providers. By default most services operate in parallel in multiple data centers, with easy to use backup functionality, very low latency and very high availability.

Considering real operational resilience very specifically requires all of these things, there are quite a few DORA requirements you can mark as complete without any actions on your part.

Change control and Disaster Recovery

Managing changes and applying controls to these changes, like 4-eye approval, have been requirements from regulators for a long time. This is nothing new and something that can generally also be achieved in traditional / on-premise environments.

Where the cloud shines is the concept of “everything as code”. This means that every change to infrastructure, software, IAM, security policy etc. is done through a change in a source code file. This process is called “GitOps” and it gives you two major benefits:

1. you can apply standardized and automated controls to every change

2. you can very easily revert to any previous state of the code

Especially Disaster Recovery is a critical requirement for DORA compliance but also avoiding from system failures caused by bad changes is something that overall supports the reliability and resilience of your system and with something that ticks of quite a few DORA paragraphs.

Asset management and Information Domain automation

Asset visibility is one of the major pains of every security executive (also because security teams often don’t have full control over asset governance). The old saying “you can’t secure what you don’t know” is not always correct but there is some truth to it.

On top comes the interesting concept of the “Information Domain” that European (and especially German) regulators are quite obsessed with.

The information domain is the complete picture of the digital landscape of an organization — this includes all business processes that are supported by digital systems, as well as all the applications, infrastructure, physical assets that underpin this.

The idea behind this is, that all digital systems/assets that support a specific business process, should meet all the security requirements based on the Confidentiality, Integrity and Availability requirements of said process.

See below for a diagram explaining the structure of an information domain.

The regulator is essentially worried that security measures for all systems need to be appropriate based on the criticality of the supported business process.

In theory this makes sense, in reality this is exactly where it gets interesting in cloud-native environments. If you have a fully standardized security platform for all your cloud assets, you would implement almost no criticality-based security controls. All security controls are uniformly very high. It would be more expensive to create and manage exceptions for the risk profile of individual applications than to just apply this uniform level of maximum security.

So if you have a fully built, standardized security platform for all your cloud assets, you would still have to draw the connection between cloud resources and business processes but any further risk-based prioritization of security controls can be skipped.

Additionally, as you can see in the diagram above, there are simply parts of the Information Domain that are outside of your responsibility. You don’t have to worry about building-specific recovery measures meeting your availability requirements because the CSP is doing that for you on a significantly higher level than you could in your own data center.

Building this information domain and performing these criticality assessments, as well as the assessment of available and applicable controls for each individual application is so cumbersome that the implementation of this standardized security platform can generate significant returns, as well as streamline your GRC processes.

Furthermore, asset discovery and ownership assignment is just a few API-calls away in your cloud environment. This makes the connection to your Information Domain that much easier.

Now let’s move on to the bad stuff — where dependency on cloud assets can generate some headache for your DORA compliance efforts.

The bad — where heavy cloud-usage makes implementation of DORA more difficult

While I believe cloud-native technology brings significant advantages for operational security and sometimes also compliance, it’s not all kittens and rainbows.

The following considerations of using the public cloud, specifically with any one of the 3 hyperscalers, make achieving DORA compliance a little bit harder in my experience:

1. Custom contractual terms

2. Right to audit

3. Vendor lock-in and exit strategies

4. Clarity around Recovery Time & Point Objectives

Custom contractual terms

The major cloud service providers are notoriously difficult to negotiate with when it comes to custom contractual terms. Depending on the size of your organization they tend to adopt a “take it or leave it” attitude.

This is especially complex for small FinTechs and InsurTechs who don’t have the negotiation power of multi-billion revenue financial institutions.

At the same time, the regulator will likely not accept any excuses when it comes to making sure your third-party risks are appropriately managed through contractual terms — especially for critical vendors such as your CSP.

Right to audit

In a similar fashion, the CSPs are not the biggest fans of custom audit requests. They are doing very good work when it comes to providing standardized security assurance documentation and they pretty much have every security or compliance certification under the sun.

However, the regulator also expects from financial institutions that their ability to conduct audits is not hindered — even if the standard contractual terms of a CSP is saying otherwise.

While the CSPs are clearly sympathetic towards these requirements from regulators and will do what is necessary during a regulatory audit, they will always try to provide evidence from their standard catalogue first. CSPs will do their best to avoid any custom documentation requests or on-site visits to their data centers.

Vendor lock-in and exit strategies

One of the major gripes many customers of major cloud platforms had for a while is the vendor lock-in. Meaning it can be exceptionally difficult to switch from one cloud vendor to the other.

Some of the main reasons include:

• Costs of transferring data

• Differences in provided services

• Specialization of talent on only one or two CSPs

The first point is something the CSPs could actively work on but it’s clearly part of the business model. The other two are not necessarily the fault of the CSP but just the way the cloud ecosystem evolved.

DORA explicitely requires exit strategies for your most critical vendors. So this makes compliance a bit more difficult.

Drawing up an exit plan from a CSP on paper is probably not even the most complicated part. However, I’m questioning that it can be executed in any meaningful timeframe. Companies could also invest in building their system CSP-agnostic to make moving between CSPs easier but that’s always requires a trade-off, as just using a managed service from one specific CSP can often times be the faster and cheaper option.

In my view this is also one of the DORA requirements that most regulates away from the reality of most financial institutions. I would like to see the exit strategy for Microsoft for any company with more than 50,000 employees that can be executed in less than 2 years.

Clarity around Recovery Time and Recovery Point Objectives

This last issue is more a translation and understanding problem than an operational problem with CSPs to achieve DORA compliance.

Obviously the hyperscalers offer incredibly resilient services that have near instant Recovery Time and Recovery Point Objectives (RTO and RPO).

However, instead of defining RTOs and RPOs, they offer Service Level Agreements that translate to almost no downtime. For example, AWS’ Elastic Compute Capacity (EC2) — a service providing virtual machines — offers 99.99% uptime per year. This means the service could be offline for no more than ~5 minutes over the entire year.

However, auditors and regulators expect a definition of an RTO and RPO from these services providers, so this can be checked against the criticality requirements from the underlying business process.

The CSP will simply say that the effective RTO and RPO depend primarily on how you architect their services in your environment. Even though that is largely true, understanding the recoverability of the underlying service is still a requirement to meet the IT Service Continuity expectations from DORA.

In this case, the problem can be solved fairly easily by translating these SLAs into RTOs and RPOs and then focusing on the real recovery capabilities of your organization in how they implemented the cloud services.

---

DORA is clearly an incredibly comprehensive piece of regulation that requires significant effort to be fully compliant with.

Your organization’s cloud strategy doesn’t have to be a hindrance in this endeavor. If you approach things the right way, broad adoption of cloud and cloud-native technology will actually get you there significantly faster.

What should you do next if you’re currently working on untangling the compliance status of your cloud assets and your DevOps processes?

1. Make sure your relevant 2nd and 3rd Line of Defense functions have a conceptual understanding of how the cloud works differently and considers this during their compliance efforts (check out my previous articles on this topic)

2. Analyze the DORA requirements that are fully covered by your cloud platform(s) and evaluate how your cloud migration can accelerate your DORA compliance roadmap

3. Consider getting involved in industry organizations like the European Cloud User Coalition, which is specifically set up to bridge the gap between financial institutions, CSPs and regulators

If you want to dive deeper into DORA and Cloud, I would recommend two resources:

• the European Cloud User Coalition’s position paper on DORA

• the BaFin’s supervisory notice on “outsourcing to Cloud Service Providers” (in German)

• the book “DevOpsSec” by Jim Bird — it’s 9 years old but it’s very short at ~80 pages and explains the connection between DevOps and compliance quite well