sota.io
2026-04-09·9 min read·sota.io team

EU DORA 2025: ICT Risk Management and Formal Verification for Financial Infrastructure

The EU Digital Operational Resilience Act — Regulation (EU) 2022/2554, known as DORA — entered into force on 17 January 2025. Unlike previous EU financial regulation that treated cybersecurity as a bolt-on, DORA elevates ICT risk to the same level as credit risk and market risk. It imposes binding requirements on more than 22,000 financial entities across the EU: banks, investment firms, insurance companies, payment institutions, crypto-asset service providers, and the cloud providers that serve them.

For developers at Deutsche Bank, Allianz, Commerzbank, Munich Re, DZ Bank, and the hundreds of German FinTech companies building on cloud infrastructure, DORA creates an ICT compliance framework that reaches into their infrastructure choices in ways most teams have not yet audited.

The intersection of DORA's third-party risk management requirements (Chapter V) and the CLOUD Act exposure of US-domiciled cloud providers creates a structural compliance gap that EU-native infrastructure — and formal verification of the software running on it — directly addresses.

DORA's Scope and Architecture

DORA applies to financial entities regulated under EU law: credit institutions (banks), payment institutions, electronic money institutions, investment firms, insurance undertakings, crypto-asset service providers (CASPs) under MiCA, and central counterparties (CCPs). It also designates certain ICT third-party service providers as "Critical ICT Third-Party Providers" (CTPPs) — cloud platforms whose disruption would constitute systemic risk.

The regulation is structured around five pillars:

ICT Risk Management (Arts. 5–16): Financial entities must maintain a comprehensive ICT risk management framework covering governance, asset management, protection, detection, response, recovery, and learning. The management body bears direct responsibility — board members must have demonstrable ICT security knowledge.

ICT-Related Incident Reporting (Arts. 17–23): Major ICT incidents must be reported to competent authorities (BaFin in Germany, AMF in France, FCA in the UK post-Brexit) within strict timelines: initial notification within 4 hours, intermediate report within 72 hours, final report within 1 month.

Digital Operational Resilience Testing (Arts. 24–27): Financial entities must conduct ICT testing annually; significant institutions must conduct Threat-Led Penetration Testing (TLPT) every 3 years using the TIBER-EU framework.

ICT Third-Party Risk Management (Arts. 28–44): Financial entities must maintain a register of all ICT third-party service providers, classify them by criticality, and include binding contractual provisions on data location, exit strategies, and audit rights.

Information Sharing (Arts. 45–46): Voluntary threat intelligence sharing between financial entities and competent authorities.

DORA Chapter V — ICT third-party risk — is where infrastructure choices become auditable compliance decisions.

DORA Article 28: The Third-Party Risk Obligation

Article 28 of DORA establishes the framework for managing ICT third-party dependencies. Financial entities must:

Article 28(7) requires that when a financial entity intends to use an ICT third-party provider for critical functions, it notifies its competent authority in advance. BaFin's DORA guidance (published Q4 2024) clarifies that major cloud migrations to providers newly classified as critical require prior notification.

The register required by Article 28(3) is not a formality. EBA's DORA ITS (Implementing Technical Standards) on registers, published in January 2024, specifies that the register must include:

That final requirement is the operative one for cloud infrastructure decisions.

Article 30: Mandatory Contractual Provisions on Data Location

Article 30(2)(c) of DORA mandates that contracts with ICT third-party providers supporting critical functions must specify:

"the places where data is to be processed, including where applicable, the location of the service provider and any of its sub-processors and the applicable law governing the contractual arrangement"

This provision forces financial entities to document precisely where their ICT infrastructure is located and under what legal jurisdiction it operates. For German banks using AWS eu-central-1 (Frankfurt), the answer produces a compliance problem their legal and IT departments must address directly.

The CLOUD Act Problem for EU Financial Data

AWS's Frankfurt region is operated by Amazon Web Services EMEA SARL, domiciled in Luxembourg, a subsidiary of Amazon.com, Inc., a US corporation. The Clarifying Lawful Overseas Use of Data Act (US CLOUD Act, 18 U.S.C. § 2523) allows US authorities to compel US-incorporated entities and their foreign subsidiaries to produce data stored anywhere in the world, regardless of where the data physically resides.

Article 30(2)(c) requires the contract to specify "the applicable law governing the contractual arrangement." For AWS, that law includes US jurisdiction over Amazon.com, Inc. DORA's Article 28 risk register must therefore reflect that financial data processed on AWS Frankfurt infrastructure is subject to potential disclosure under a US legal instrument that has no EU equivalent and operates outside GDPR's transfer safeguards.

This is not a hypothetical risk. The CLOUD Act has been used in criminal and national security investigations. Financial data — transaction records, customer identification, anti-money-laundering (AML) audit trails — represents exactly the category of data that US law enforcement agencies seek. GDPR Article 44 prohibits transfers of personal data to third countries without adequate protection. DORA Article 28 requires documenting third-country law exposure. Together they create a compliance obligation to flag and manage CLOUD Act exposure in the ICT third-party register.

The practical implication for DACH financial institutions: the ICT risk register, when prepared in compliance with EBA's DORA ITS, must disclose the CLOUD Act applicability to any cloud provider with US corporate parentage, regardless of where their EU data centres are located. This includes AWS, Microsoft Azure, Google Cloud Platform, and Oracle Cloud — all US-incorporated entities.

BaFin, as the German competent authority under DORA, has not published guidance explicitly requiring EU-only infrastructure. But the EBA DORA ITS register template, combined with Article 30(2)(c)'s "applicable law" requirement, creates a documentation trail that financial entities' DORA compliance teams must address in their third-party risk assessments.

Formal Verification for DORA ICT Risk Management

DORA Article 9 establishes protection and prevention requirements for ICT systems. Article 9(2) requires financial entities to have ICT security tools that "prevent unauthorized access" and detect anomalous activity. Article 9(4)(a) specifies that policies and procedures must ensure "the availability, authenticity, integrity and confidentiality of data."

These are the four classical information security properties — and they are precisely the properties that formal verification tools can prove, not merely test.

ProVerif: Cryptographic Protocol Verification

ProVerif is a formal verification tool for security protocols developed at INRIA Paris by Bruno Blanchet. It operates on a process calculus (applied pi-calculus) and automatically verifies cryptographic protocol properties including secrecy, authentication, and non-repudiation.

For DORA Article 9 compliance, ProVerif is applicable to:

ProVerif produces formal proofs that a protocol achieves secrecy and authentication properties against an active Dolev-Yao attacker — an adversary who can intercept, replay, and forge messages. For DORA Article 9(4)(a)'s "authenticity" requirement, a ProVerif proof of authentication constitutes formal assurance that no attacker model can bypass the authentication mechanism.

ProVerif is EU-native: INRIA Paris (Institut national de recherche en informatique et en automatique) is a French public research institute. ProVerif has been used to verify TLS 1.3 (which underlies modern banking APIs), Signal Protocol, and the Noise Protocol Framework.

Tamarin Prover: Security Protocol Analysis at EU Scale

Tamarin Prover, developed at ETH Zurich and the University of Basel, provides automated analysis of security protocols against unbounded numbers of sessions — a capability ProVerif approximates but Tamarin makes exact for many protocol classes.

Tamarin's multiset rewriting formalism and temporal logic properties make it appropriate for verifying protocols where DORA's incident response requirements intersect with security guarantees:

For DORA Article 9(4)(a)'s "non-repudiation" requirement in financial transactions, Tamarin proofs provide machine-checked evidence that signature schemes behave correctly under adversarial conditions.

Tamarin Prover development continues at ETH Zurich and TU Darmstadt — both EU-resident academic institutions. Commercial adoption in EU financial sector security assessments is documented at ABN AMRO (NL) and KBC Group (BE).

SPARK Ada: Formal Contracts for Critical Transaction Processing

SPARK Ada is a formally verifiable subset of Ada developed by AdaCore, headquartered in Paris (AdaCore S.A.S., 75002 Paris). SPARK programs are annotated with formal contracts — preconditions, postconditions, data flow specifications — that the SPARK toolchain proves correct at compile time using Why3 as an intermediate verification platform.

For DORA-relevant financial software:

Payment transaction processing: Core payment engines at European banks and payment processors handle tens of millions of transactions daily. Arithmetic errors in transaction processing — integer overflow in amount calculations, incorrect rounding in currency conversion — constitute ICT incidents under DORA Article 17. SPARK Ada's proof of absence of runtime errors eliminates this category of ICT risk by construction.

Anti-money-laundering (AML) rule engines: EU AML Regulation (AMLA, entering into force 2027) and the current AMLD6 framework impose accuracy requirements on transaction screening. SPARK Ada's data flow contracts allow proving that transaction classification logic does not misclassify based on data dependencies.

Core banking state machines: Account state transitions (opening, closing, blocking, reactivating) are state-critical operations. SPARK Ada preconditions and postconditions formally specify valid state transitions, preventing invalid state combinations that would constitute ICT incidents.

SPARK Ada is deployed in the Multos payment card operating system (Infineon DE/Multos International UK) and in French Ministry of Finance applications. AdaCore maintains SPARK Ada as EU-originated, EU-hosted software.

Why3 and Alt-Ergo: The EU Verification Platform Layer

Why3 (INRIA Saclay — Île-de-France, developed by Jean-Christophe Filliâtre and the team at LRI, Paris-Saclay) provides an intermediate verification platform that connects high-level program logic with automated theorem provers. Alt-Ergo (OCamlPro, Paris FR) is the specialized SMT solver for Why3, optimized for the program verification problems that Why3 generates.

SPARK Ada uses Why3 as its backend. The combination — SPARK Ada → Why3 → Alt-Ergo (FR) + CVC5 (Stanford, open source) — forms a verification chain where the critical reasoning components are EU-originated.

For DORA Article 9(4)(c), which requires "adequate access control mechanisms," Why3-based verification of access control logic provides a machine-checked proof that an access control implementation satisfies its specification. This is stronger than penetration testing: a Why3 proof is exhaustive over all inputs, not limited to the test cases a penetration tester generates.

Isabelle/HOL: Highest Assurance for Systemic Risk Components

Isabelle/HOL, developed jointly at TU Munich (Technical University of Munich) and the University of Cambridge, provides the highest assurance level available: interactive theorem proving where every proof step is machine-checked.

For DORA's designation of systemically important financial entities — where a failure constitutes systemic risk to the EU financial system — Isabelle/HOL verification of critical components provides the strongest available evidence of correctness.

Applications in financial systems:

The seL4 formally verified microkernel (CSIRO/Proofcraft, with EU institutional use via Hensoldt Cyber DE in TRENTOS) provides an OS layer for HSMs and financial appliances where Isabelle/HOL verification of the OS kernel eliminates entire attack surface categories.

DORA and ICT Infrastructure: The EU-Native Stack

DORA's Article 28 third-party risk register, Article 30 contractual requirements on data location, and Article 9 protection requirements collectively create a compliance argument for EU-native ICT infrastructure that is stronger than any previous EU regulation's implicit preference.

The argument is not merely about GDPR data residency. It is about the legal chain of jurisdiction that DORA's EBA ITS register template requires financial entities to document.

An EU financial entity deploying on sota.io's EU-native infrastructure:

Satisfies Article 30(2)(c) without qualification. sota.io is incorporated and operated in the EU. No US corporate parent. No CLOUD Act applicability. The "applicable law" entry in the DORA third-party register is EU law only.

Simplifies the Article 28 risk register. Entries for cloud infrastructure providers with US corporate parents require CLOUD Act risk analysis, GDPR Chapter V transfer mechanism documentation, and ongoing monitoring of US legislative developments. EU-native providers require none of this additional documentation layer.

Supports Article 9 resilience requirements. EU-native infrastructure eliminates the cross-border latency and jurisdictional handoff points that create additional attack surface in CLOUD Act scenarios. EU regulators (BaFin, AMF) have direct supervisory jurisdiction over EU-incorporated providers.

Enables Article 30 audit rights without legal conflict. DORA Article 30(2)(f) requires contractual audit rights for financial entities and their competent authorities. EU-native providers operate under a legal framework where BaFin-commissioned audits face no competing US jurisdiction claims.

The formal verification stack described above — ProVerif (INRIA FR), Tamarin (ETH Zurich/Basel), SPARK Ada (AdaCore FR), Why3/Alt-Ergo (INRIA Saclay/OCamlPro FR), Isabelle/HOL (TU Munich) — runs on standard compute infrastructure. Deploying these verification pipelines on EU-native infrastructure preserves the integrity of the full compliance chain: EU law governs the code, the tools, and the infrastructure that produces and stores the compliance evidence.

The DORA Compliance Timeline

DORA has been in force since 17 January 2025. There is no grace period for the core requirements. Financial entities that have not completed their ICT third-party risk registers, Article 28 critical function assessments, and Article 30 contractual gap analyses are currently non-compliant.

BaFin's supervisory examination programme for 2025/2026 includes DORA readiness as an examination topic. The EBA's Joint Committee — coordinating BaFin, AMF, ACPR, FCA, and other national competent authorities — is conducting thematic reviews of DORA implementation at significant financial institutions in H1 2026.

For DACH financial sector developers building on cloud infrastructure: the compliance question is not whether to address DORA's ICT third-party requirements, but whether the current infrastructure register accurately reflects the CLOUD Act exposure that exists in deployments on US-parented cloud providers.

The formal verification tools and EU-native infrastructure described here do not reduce DORA to a checkbox exercise. They address the substantive ICT risk management requirements — verifiable correctness of critical protocols, absence of runtime errors in transaction processing, formally specified access controls — that DORA's Article 9 protection requirements demand.

DORA's underlying goal is operational resilience: EU financial infrastructure that functions under stress, attack, and disruption. Formal verification provides the strongest available technical foundation for that goal. EU-native infrastructure provides the legal foundation. Together they address DORA's requirements without the jurisdictional exposure that US-parented cloud infrastructure introduces into every financial entity's compliance register.

See also: