DORA Compliance on AWS: A Practical Guide for EU Financial Entities and ICT Third-Party Providers

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) is the European Union’s most comprehensive financial-sector cybersecurity regulation, in force since 17 January 2025. DORA replaces fragmented national rules with a single ICT risk-management regime covering ~22,000 financial entities and the ICT third-party service providers — including hyperscalers like AWS — that they depend on. Penalties run up to 2% of total annual worldwide turnover for financial entities and up to 1% of average daily worldwide turnover (calculated daily) for designated critical ICT third-party providers (CTPPs).

If you are a bank, payment institution, e-money institution, investment firm, crypto-asset service provider, insurance undertaking, or any of the other 17 covered entity types — and your platform runs on AWS — DORA is on your critical path. This guide is for compliance leads, CISOs, and platform engineers operating in the EU or serving EU financial markets. It covers scope, the ICT risk-management framework, the third-party register, threat-led penetration testing (TLPT) under TIBER-EU, the major-incident reporting timeline, and the AWS-native control mapping that turns DORA from regulation text into operational reality.

Need help with DORA readiness on AWS? FactualMinds runs DORA readiness engagements alongside ISO 27001, SOC 2, and NIS2 — sharing controls and evidence across audits. See our compliance services or talk to our team.

Step 1: Confirm Scope and Map the AWS Estate

DORA is broader than most financial-services regulations because it sweeps in the technology-supplier chain. You need three answers before drafting controls.

Are you a financial entity in scope? The 20 categories in Article 2 are explicit — banks (CRR institutions), payment institutions, e-money institutions, investment firms (MiFID), central counterparties, central securities depositories, trading venues, trade repositories, crypto-asset service providers (under MiCA), insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision (IORPs), credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, account information service providers, payment service providers under PSD2, alternative investment fund managers, and management companies. A small subset (microenterprises, certain IORPs, certain insurance intermediaries) get a proportionality discount but still have core obligations.

Are you a CTPP? Critical ICT third-party providers are designated by the ESAs based on systemic relevance, substitutability, and the criticality of the financial functions supported. The first designations were announced in 2025 and include the major hyperscalers. CTPP status brings direct oversight by a Lead Overseer (ESMA, EIOPA, or the EBA), the right to issue binding requirements, and the power to fine. Most readers are not CTPPs but are sub-contractors or non-critical suppliers — DORA still binds you contractually through the financial entities you serve.

What runs on AWS? Use AWS Resource Explorer and AWS Config aggregator views to inventory every workload, then classify each by financial-function criticality. The DORA Register of Information (RoI) demands this taxonomy: critical or important functions get one set of obligations; non-critical functions get a lighter touch. Mis-classifying a customer-facing payment workload as non-critical is the single most common audit finding from the first DORA cycle.

Step 2: Build the ICT Risk-Management Framework (Article 6)

DORA Article 6 mandates a board-approved ICT risk-management framework that covers identification, protection, detection, response, recovery, learning, and communication. The framework is reviewed at least annually. Mapping to AWS-native services:

• Identify — Asset and dependency inventory via AWS Config, Resource Explorer, and Service Catalog. Threat assessment using STRIDE or PASTA. Business-impact assessment for every critical function.
• Protect — IAM Identity Center for workforce SSO with identity propagation; least-privilege IAM with permissions boundaries; AWS WAF and Shield Advanced at edge; AWS Network Firewall + Firewall Manager for stateful L3-L7; KMS with customer-managed keys (CMKs) and ML-KEM hybrid TLS for long-lived data; AWS Verified Access replacing legacy VPN for workforce app access.
• Detect — GuardDuty across CloudTrail, VPC Flow Logs, EKS, S3, RDS, Lambda, and EC2 Runtime; Inspector v2 for vulnerability and code scanning; Security Hub Essentials as the aggregator with the FSI conformance pack; Amazon Detective for forensic graph investigation.
• Respond — Documented incident classification matrix (DORA RTS criteria) with EventBridge automation that pages the right runbook based on finding severity; CloudFormation StackSets to deploy containment guardrails Organization-wide.
• Recover — Multi-AZ and multi-region designs for critical functions, AWS Elastic Disaster Recovery for tier-2 workloads, AWS Backup with cross-account vaults and immutable backups, regular failover drills.
• Learn — Quarterly post-incident reviews fed back into the framework; threat-intelligence subscriptions; lessons applied to control updates.
• Communicate — Documented escalation paths to the board, the competent authority, and customers; templates pre-approved by legal.

Step 3: Populate the Register of Information (Article 28)

The Register of Information (RoI) is the centerpiece artifact of DORA third-party governance. Every in-scope financial entity submits the register annually to its national competent authority via XBRL — the first formal submission window opened in April 2025. The RTS specifies ~150 fields per arrangement covering: contractual reference, function supported, criticality, data and service location, sub-contractor chain, applicable law, monitoring rights, exit strategies, security incidents in the prior reporting period, and the linked cybersecurity attestation.

For AWS arrangements:

• Contractual reference — your AWS Customer Agreement plus the signed DORA Addendum (available through AWS Artifact).
• Function supported — name the financial function (e.g. “core banking transaction processing”, “credit risk modeling pipeline”, “fraud-detection inference”). Generic descriptions like “cloud hosting” fail the RTS validation.
• Criticality — apply the RTS test: is the function critical or important per Article 30? If yes, the arrangement carries the full Annex II obligations.
• Location of data and services — list every AWS Region where data is processed or stored. EU sovereignty requirements may pin you to eu-west-1, eu-central-1, eu-south-1, eu-north-1, eu-west-3, eu-south-2, or the AWS European Sovereign Cloud (announced 2024, launching 2025+).
• Sub-contractor chain — AWS publishes its sub-processor list; you transcribe the relevant entries into your register and update on AWS notification.
• Exit strategy — document the technical and operational steps to migrate the critical function off AWS within a regulator-acceptable timeline. Most financial entities accept that hyperscaler exit is multi-year; the RTS asks you to be honest about that and have a plan, not to claim feasibility you cannot deliver.

Step 4: Run Threat-Led Penetration Testing (Article 26)

TLPT is mandatory at least every three years for financial entities classified as “significant” — the threshold combines size, business criticality, and risk. The methodology aligns with TIBER-EU.

The phases:

1. Preparation — Scope agreed by white team (CISO, head of compliance, regulator liaison), including critical-function flags and rules of engagement. AWS pre-test authorization obtained for activities exceeding the standard customer testing policy (anything more than a vulnerability scan on your own infrastructure typically needs the AWS Customer Support Pre-test Form).
2. Threat intelligence — Targeted Threat Intelligence Report (TTIR) prepared by an accredited TI provider, covering the entity-specific threat landscape, plausible threat actor TTPs, and prioritized attack scenarios.
3. Red team test — Live production red-team engagement against agreed flags. The blue team (SOC) is unaware; only the white team knows. Activities span initial access (phishing, supply-chain, public-facing exploitation), persistence, privilege escalation, lateral movement, and objective achievement.
4. Replay and remediation — White-box replay of the attack chain with the blue team to validate detection coverage; remediation plan with deadlines; final report submitted to the competent authority.

A well-instrumented AWS estate makes the replay phase easier. Your evidence: GuardDuty findings during the engagement, Security Hub Essentials event timeline, Detective entity graphs, and CloudTrail Lake queries — all of which should show whether the SOC could have caught the red team in a real engagement.

Step 5: Operate the Major-Incident Reporting Workflow (Article 19)

DORA’s incident reporting is faster than NIS2 (4 hours vs 24 hours for early warning) and demands a specific classification matrix. Building the workflow:

• Detect — Automated detection through GuardDuty, Inspector, Security Hub Essentials, AWS Health, and your application monitoring (Datadog, New Relic, Dynatrace). Every detection enters a triage queue with a severity score.
• Classify — A documented decision tree maps detection signals to DORA major-incident criteria: clients affected, services affected, data losses, geographical spread, economic impact, reputational impact, duration, criticality. The classification triggers the regulator notification clock — get this wrong and you miss the 4-hour window.
• Notify — A pre-approved notification template populated from the incident-management tool (Jira, ServiceNow, PagerDuty Incident) and sent through the national competent authority’s structured form. Most national authorities provide an XML or web-form submission channel.
• Update — 72-hour intermediate report. Include impact updates, root-cause hypothesis, mitigation status.
• Close — Final report within one month of the intermediate report. Full root cause, attack chain reconstruction, remediation evidence, lessons learned.

EventBridge rules that fire on critical Security Hub findings or GuardDuty severity-9+ events are the technical backbone of the 4-hour clock. The legal and communications steps are the variable — pre-rehearse with the board and legal twice a year so the workflow is not theoretical.

Step 6: Engage with the Lead Overseer (CTPPs only)

If you are a designated critical ICT third-party provider, you have an additional obligation: cooperation with the Lead Overseer. The Lead Overseer can request information, conduct on-site inspections, issue recommendations, and ultimately fine you for non-compliance. Most readers are not CTPPs and skip this step. If you are, expect an annual review cycle, a documented oversight plan with milestones, and a formal liaison contact within your organization.

How DORA Maps to ISO 27001, SOC 2, and NIS2

DORA shares ~70% of controls with ISO 27001:2022 Annex A and ~60% with SOC 2 CC-series criteria. If you already have those certifications:

• ICT risk management — ISO 27001 ISMS framework + ISO 27005 risk-assessment methodology covers most of DORA Articles 5-16.
• Third-party risk — your existing supplier management process (ISO 27001 A.5.19-A.5.22, SOC 2 CC9.2) extends to fill the DORA RoI fields.
• Incident management — SOC 2 CC7.4-CC7.5 + ISO 27035 covers the operational mechanics; DORA only changes the timing and the regulator destination.
• Resilience testing — ISO 22301 BCMS + your existing DR drills cover DORA Articles 24-25; TLPT (Article 26) is the new piece.

If you also operate critical infrastructure under NIS2, the overlap with DORA is high but not 1:1. NIS2 has a 24-hour early-warning + 72-hour notification + 1-month final-report cadence; DORA tightens the early warning to 4 hours but uses a similar three-stage structure. Most regulated EU groups run a unified incident-response playbook with a decision tree that classifies each event under NIS2, DORA, GDPR, and any sectoral regimes — and notifies the right authorities in parallel.

Common Pitfalls

1. Mis-classifying AWS workloads in the RoI. Auditors expect critical-function workloads (core banking, claims processing, payment authorization) to carry the full Annex II obligations. Under-classifying is the most common finding.
2. Exit strategies that are theoretical. Saying “we would migrate to a different cloud in 12 months” without testing the migration of even a single critical workload makes the exit strategy a paper artifact. Run a tabletop or limited live drill.
3. Treating TLPT as an annual penetration test. TLPT is adversary simulation against live production with white-team-only awareness. A standard pen test does not satisfy Article 26.
4. Missing the 4-hour clock. This is almost always a workflow problem, not a technical problem. Pre-rehearse the legal-approval step that turns “we have an incident” into “we have notified the authority.”
5. Ignoring sub-contractor changes. When AWS adds or changes a sub-processor, your RoI needs an update. Subscribe to AWS notifications and route them through compliance.

Where to Go Next

• Read the full DORA Regulation (EU) 2022/2554 and the supporting RTS suite.
• Review the AWS DORA Addendum in AWS Artifact and route it through legal.
• Map your AWS workloads to the FSI Conformance Pack in AWS Config for continuous evidence.
• Browse the AWS Security & Compliance hub and the Compliance Frameworks subtopic for related guides on NIS2, GDPR, ISO 27001, and the EU AI Act.

DORA is enforceable today. Most regulated entities discover halfway through their first compliance cycle that the controls are achievable but the documentation, register population, and exit-strategy work are deeper than they planned for. Start the multi-year workstreams (RoI, TLPT, exit) early — the 4-hour incident clock is the easy part once the foundations are in place.