DORA Compliance for Cloud Infrastructure: AWS & Azure Guide 2025

The Digital Operational Resilience Act (DORA — EU 2022/2554) has been fully applicable since 17 January 2025. If your institution runs on AWS or Azure and operates in banking, insurance, investment management, or payment services, DORA's ICT requirements are now legally binding. This guide maps the regulation's infrastructure obligations to concrete cloud configuration checks.

Who is affected by DORA?

DORA applies to a broad range of financial entities operating in the EU:

• Credit institutions (banks) and payment institutions
• Investment firms and asset management companies
• Insurance and reinsurance undertakings
• Crypto-asset service providers (CASPs)
• ICT third-party service providers designated as "critical" by the ESAs

Unlike NIS2, which uses employee and revenue thresholds, DORA applies by sector — not by size. A two-person fintech accepting payments falls in scope just as a large bank does.

DORA ICT risk requirements (Articles 5–16)

Chapter II of DORA defines a comprehensive ICT risk management framework. For cloud infrastructure, this breaks down into five technical domains:

1. Identification and classification (Art. 8)

• All ICT assets inventoried — including cloud accounts, regions, and services
• Business functions supported by each asset documented
• Data classification applied to all storage resources (S3, RDS, Azure Blob, SQL)
• Dependencies on ICT third-party providers (AWS, Azure) formally documented

2. Protection (Art. 9)

• MFA enforced on all IAM users and privileged accounts
• Encryption at rest on all storage: S3 (SSE-KMS), RDS, EBS, DynamoDB, Azure SQL (TDE), Azure Storage
• Encryption in transit: TLS 1.2+ enforced, no deprecated cipher suites
• Network segmentation: no security groups open to 0.0.0.0/0 on sensitive ports
• KMS key rotation enabled (annual minimum)
• Secrets stored in AWS Secrets Manager or Azure Key Vault — never in environment variables

3. Detection (Art. 10)

• CloudTrail enabled in all regions with log file validation and KMS encryption
• Azure Monitor / Activity Log retention ≥ 12 months
• GuardDuty enabled for anomaly and threat detection
• VPC Flow Logs and Azure NSG Flow Logs active
• CloudWatch alarms on root account usage, IAM policy changes, and failed auth events
• Centralised SIEM ingestion with tamper-evident log storage

4. Response and recovery (Art. 11–12)

• RDS automated backups with ≥7 day retention; tested restores documented
• Multi-AZ enabled for production databases
• S3 versioning and cross-region replication for critical data
• Azure SQL geo-redundant backup enabled
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO) formally defined
• Business continuity plan updated at least annually and after major incidents

5. Learning and evolving (Art. 13)

• Post-incident reviews documented with root cause analysis
• Threat intelligence feeds integrated into detection tooling
• Vulnerability scanning on all EC2 and container workloads (Amazon Inspector, Defender for Cloud)
• Patch management within defined SLAs (DORA does not specify windows — you must define and prove them)

Incident reporting (Article 19) — the 72-hour clock

DORA sets a strict three-stage reporting timeline for major ICT incidents:

• Initial notification: within 4 hours of classification as major (or 24h of first awareness)
• Intermediate report: within 72 hours — updated impact assessment and containment status
• Final report: within 1 month — full root cause analysis and corrective actions

This requires that your detection and alerting stack can identify, classify, and escalate an ICT incident within hours. CloudWatch alarms, GuardDuty findings routed to PagerDuty or Slack, and a documented classification process are minimum requirements.

ICT third-party risk (Articles 28–44)

DORA imposes significant obligations on how you manage cloud providers like AWS and Azure. Key requirements:

• Written contractual arrangements with all ICT third-party providers (Art. 30) — your cloud MSA and DPA satisfy the baseline
• Register of all ICT third-party dependencies maintained and updated
• Exit strategy documented for critical third-party dependencies
• Annual risk assessment of third-party concentration — if 90% of your workload runs on a single cloud provider, this must be assessed and mitigated
• For critical ICT third-party providers (designated by ESAs): enhanced oversight framework applies directly — currently under assessment for major cloud hyperscalers

DORA vs NIS2 — what overlaps?

DORA and NIS2 share approximately 40% of technical controls at the infrastructure level. Both require encryption, access control, logging, incident response, and business continuity. The key differences:

• Scope: NIS2 covers critical infrastructure broadly; DORA is financial-sector specific
• Incident timelines: NIS2 requires 24h early warning + 72h notification; DORA requires 4h initial + 72h intermediate + 1 month final
• Third-party risk: DORA goes much further — Art. 28-44 are largely absent from NIS2
• Testing: DORA mandates annual TLPT (Threat-Led Penetration Testing) for significant entities — NIS2 recommends but does not mandate

If your organisation is subject to both, fixing the NIS2 gaps first covers most of the DORA baseline — then focus on DORA-specific additions (third-party registers, TLPT, 4h classification process).

DORA penalties

Supervisory authorities (national competent authorities — NCAs) can impose:

• Administrative fines up to 1% of average daily worldwide turnover per violation, per day of non-compliance
• Periodic penalty payments of up to 1% of daily turnover for up to 6 months
• Public statements naming the institution and the nature of the breach
• For critical ICT third-party providers: fines up to €5 million or 1% of global turnover

How to automate DORA compliance checks

DORA's ICT risk requirements map directly to infrastructure configuration. Every encryption, access control, and logging requirement in Articles 9–10 can be verified automatically against your live cloud environment.

ConformScan runs DORA-mapped checks across your AWS and Azure accounts in under 2 minutes — covering encryption at rest and in transit, IAM controls, logging completeness, backup configuration, and network exposure. You get:

• DORA-mapped findings with SLA countdowns (3 → 14 → 30 days, aligned with Art. 19 timelines)
• Cross-framework view: see which findings affect DORA, NIS2, and ISO 27001 simultaneously
• Terraform and CLI remediation code for every finding
• PDF reports ready for your compliance officer, auditor, or NCA submission
• Scheduled daily scans to catch configuration drift before it becomes a reportable incident

Where to start

If you are starting your DORA compliance programme today, prioritise in this order:

1. Run a baseline scan — know your current exposure across all ICT risk domains
2. Fix critical findings first — encryption gaps, public databases, missing MFA
3. Build your ICT asset register — document cloud accounts, services, and third-party dependencies
4. Establish your incident classification process — the 4h clock starts when you become aware, not when you decide it is major
5. Document third-party contracts — review your AWS and Azure MSAs against DORA Art. 30 requirements

DORA is not a project with an end date — it requires continuous monitoring of your ICT risk posture. Automated scanning via conformscan.com ensures your controls remain effective between audits.