DORA Compliance: A Technical Guide for Financial Services Engineers

If you are a platform engineer, CTO, or infrastructure architect at a financial services firm operating in Europe, DORA is no longer something your compliance team handles in a spreadsheet. As of January 2025, the Digital Operational Resilience Act imposes legally binding technical requirements that reach into your cloud architecture, your incident response runbooks, and your vendor contracts. Non-compliance carries penalties of up to 2% of global annual turnover, and the 19 critical ICT third-party providers — AWS, Azure, Google Cloud, and others — are now under direct regulatory oversight for the first time.

What is striking is how few engineers at regulated firms understand the technical depth of what DORA actually demands. It reads like a regulation, but it lands like an architecture review.

Who Is This Guide For?

This guide is for platform engineers, infrastructure architects, CTOs, and security leads at banks, insurers, investment firms, payment providers, and crypto-asset service providers operating in or serving the European market. If your organisation is one of the 22,000+ entities in scope, this is for you.

By the End of This, You’ll Know…

• The five pillars of DORA and what each one means for your infrastructure
• Which technical controls you need to have in place — not just policy documents
• How DORA changes your incident response, penetration testing, and third-party vendor management
• What the 19 critical ICT providers are and what it means that they are now directly regulated
• Practical architecture patterns for compliant cloud deployments in Europe

What DORA Actually Regulates

DORA — formally EU Regulation 2022/2554 — took full effect on 17 January 2025 after a two-year implementation period. It covers 22,000+ financial entities across the EU, spanning banks, payment institutions, insurers, investment firms, crypto-asset service providers, and third-party ICT providers deemed critical.

The regulation is structured around five pillars:

ICT Risk Management (Articles 5-14): You must implement a comprehensive ICT risk management framework that includes identification, protection, detection, response, and recovery capabilities. This is not a policy document. DORA requires specific technical controls: network segmentation, access control, encryption, vulnerability management, and continuous monitoring. Every critical ICT system must be mapped to a business function, and your risk register must include actual technical risks — not just compliance risks.

ICT-Related Incident Reporting (Articles 15-23): You must classify incidents based on severity criteria — critical, significant, or minor — and report major incidents to your competent authority within strict timeframes. The initial notification deadline is 4 hours for critical incidents and 24 hours for significant ones, with a full report due within one month. This is dramatically tighter than GDPR’s 72-hour standard and requires automated incident classification pipelines.

Digital Operational Resilience Testing (Articles 24-27): If you are a significant financial entity, you must conduct threat-led penetration testing (TLPT) at least every three years. This is a red-team exercise where testers simulate a real attacker using current threat intelligence against your live production systems. It goes far beyond conventional penetration testing — the tester must attempt to breach your actual production boundary, pivot through your network, and exfiltrate data, with your SOC team unaware it is a test.

Third-Party ICT Risk Management (Articles 28-44): You must maintain a register of all ICT third-party service providers, assess their criticality, and ensure contracts include specific clauses for audit rights, incident notification, and termination assistance. The 19 critical ICT providers designated by the ESA — including AWS, Microsoft Azure, Google Cloud, and Salesforce — are now subject to direct oversight by a Lead Overseer, and financial entities must consider the overseer’s recommendations when contracting with these providers.

Information Sharing (Article 45): DORA encourages voluntary sharing of threat intelligence and cyber incident information between financial entities, subject to data protection requirements. The goal is to create a collective defence mechanism across the European financial sector.

The Technical Architecture Implications

DORA changes how you design cloud infrastructure for European financial services. Here are the specific technical controls that matter:

Network Segmentation and Micro-Segmentation: DORA requires you to isolate critical ICT systems from non-critical ones. In cloud environments, this translates to VPC-level separation for production, staging, and development environments, with service-level micro-segmentation for payment processing, trading systems, and customer data stores. On GCP, this means VPC Service Controls and Shared VPC patterns. On AWS, it means separate accounts with tightly controlled VPC peering.

Encryption at Rest and in Transit: All data classified as sensitive under DORA — customer financial data, payment information, trading records — must be encrypted at rest with customer-managed keys (CMEK) and in transit with TLS 1.3. Cloud-native KMS services must be configured with key rotation policies and access audit trails that survive regulatory inspection.

Identity and Access Management: DORA mandates just-in-time access for privileged operations, with all administrative actions logged to an immutable audit trail. This means Service Account key rotation policies, short-lived tokens, conditional access policies based on device posture and location, and privileged access management platforms integrated with your IdP. Break-glass procedures must be documented and tested quarterly.

Incident Detection and Response Pipeline: The 4-hour notification window for critical incidents demands automated incident classification. Your SIEM or security data lake must ingest events from cloud audit logs, workload logs, network flows, and identity systems, then auto-classify severity based on pre-defined rules. Manual triage cannot meet the deadline. Platforms like Google Security Operations (formerly Chronicle SIEM), Splunk, or Elastic Security with pre-built DORA-aligned detection rules are the baseline.

Immutable Backups and Recovery Testing: DORA requires offline, immutable backups for all critical systems with recovery tested quarterly. In cloud environments, this means object storage with object lock enabled, separate backup accounts with no shared credentials, and automated recovery drills that restore a complete environment in under 4 hours. This is more demanding than typical DR planning — DORA’s testing requirements specify that you must demonstrate actual recovery, not just document a plan.

What Changes for Your Cloud Contracts

The third-party risk provisions are where DORA most directly impacts engineering decisions. Your cloud contracts with AWS, Azure, and GCP must now include specific clauses that were previously optional or vaguely worded for enterprise agreements.

You need contractual rights to audit your cloud provider’s ICT security controls — not just read audit reports, but conduct your own assessments. You need defined incident notification SLAs with clear timelines matched to DORA’s reporting requirements. You need termination assistance provisions that guarantee data extraction and migration support if the contract ends. And your contract must specify the exact locations where your data will be stored and processed, with no ambiguity about cross-border data transfers.

This last point is particularly relevant for firms using multi-region cloud deployments. If your financial data is processed in non-EU regions even as part of a global load-balancing architecture, you must assess and document the regulatory implications under DORA’s data localisation considerations.

Practical Implementation: Where to Start

If your organisation has not yet started DORA compliance work as of July 2026 — 18 months after the regulation took effect — the priorities are clear:

First, map your critical ICT assets to business functions. Use your existing asset inventory, cloud resource tagging, and configuration management database. Every critical business function — payment processing, trading, settlement, customer authentication — must be linked to the specific systems that support it. This mapping is the foundation for every other DORA requirement.

Second, implement an automated incident classification pipeline. Start with your SIEM or security data lake. Define severity levels aligned with DORA’s critical/significant/minor taxonomy. Build automated alert triage that can classify an incident within minutes of detection, then route critical incidents for immediate human review. Test the 4-hour notification workflow end-to-end at least monthly.

Third, review your cloud contracts. If you are an existing AWS, Azure, or GCP customer running production financial services workloads, your enterprise agreement may already include DORA-compliant terms. The hyperscalers updated their standard contracts in 2024 in response to the regulation. Verify that your specific agreement has the required audit, notification, and termination clauses. If you are using smaller cloud providers or SaaS vendors for critical systems, those contracts require immediate assessment.

Fourth, schedule your threat-led penetration testing. If your entity qualifies as significant — and most large banks, insurers, and payment providers do — you must complete a TLPT exercise. Engage a qualified provider, ideally one with experience in financial services and cloud-native environments. The test must simulate a real-world adversary using current threat intelligence against your production boundary.

How DORA Connects to Your Existing Infrastructure

DORA does not exist in isolation. It intersects with several other regulations and standards that financial services engineers already work with. PCI DSS 4.0 mandates specific API security controls that align with DORA’s ICT risk management requirements. ISO 27001 certification provides a framework for the governance elements. The EU Cyber Resilience Act, expected in 2027, extends similar resilience requirements to all digital products sold in the EU.

On the cloud side, the shared responsibility model takes on new meaning under DORA. Your cloud provider is now a regulated critical third party with direct oversight. But your responsibility for what runs inside your cloud environment — architecture, configurations, IAM, monitoring — has not changed. DORA makes this division more explicit and more consequential.

For teams already running on GCP or AWS with strong security foundations — VPC segmentation, CMEK, IAM with short-lived tokens, centralised logging, immutable backups — the gap to DORA compliance is manageable. The work is in formalising what may already be good practice into demonstrable, auditable, contractually backed compliance.

Further Reading

• What is DORA? — Comprehensive reference site for EU Regulation 2022/2554
• EIOPA — Digital Operational Resilience Act official page
• DORA Compliance: Key Requirements for Financial Entities — CybelAngel

For more on security and compliance in financial services, see our guide to cloud security posture management for fintech and our analysis of the cloud security market and why spending doesn’t equal safety. For cloud migration in regulated environments, see our capital markets cloud migration playbook.

Related reading: Cloud for Regulated Finance Guide · Infrastructure as Code: Terraform vs Pulumi vs Crossplane · cloud modernization practice