DORA
10 AWS controls for DORA
DORA lists no AWS setting: it sets principles for protection, detection and recovery. Here are the ten AWS configuration controls that answer them most directly, the DORA article each one serves, and the CIS v5.0 and FSBP references to check them.
In short
- DORA has applied since 17 January 2025 to financial entities in the Union. Its Articles 8 to 12 cover identification, protection, detection, response and backup.
- AWS is a critical third-party provider since November 2025, but the configuration of your accounts remains your responsibility.
- The ten controls cover inventory, identities, encryption, exposure, logging, detection, backups and recovery.
- Each one can be checked in the configuration, with the CIS AWS Foundations v5.0 and AWS Foundational Security Best Practices (FSBP) controls quoted.
Why these ten controls
Regulation (EU) 2022/2554 and its Delegated Regulation (EU) 2024/1774 describe what the ICT risk management framework must cover, without prescribing any technology. On AWS, part of these requirements translate into settings you can check.
The ten controls below were chosen because each answers a specific DORA article, can be observed in an account's configuration, and is something a supervisor can reasonably ask to see. They cover neither governance, nor incident management, nor contracts with your providers.
1. An up-to-date, tagged resource inventory
DORA, Article 8: identify and classify ICT assets, and the dependencies that support critical or important functions.
- Enable AWS Config in every region in use, to keep the history of each resource.
- Tag resources by application, environment and criticality, and enforce those tags with an AWS Organizations tag policy.
- References: CIS 3.3, FSBP Config.1.
2. A locked-down root account
DORA, Article 9: limit physical and logical access to what is legitimately needed. The AWS root account can do anything, including closing the account.
- No access key on the root account, and a hardware MFA device.
- Use restricted to the rare tasks that require it, watched by an alarm.
- References: CIS 1.3 to 1.6 and 4.3, FSBP IAM.4, IAM.6 and IAM.9.
3. Strong authentication and federated identities
DORA, Article 9: implement strong authentication mechanisms. Delegated Regulation 2024/1774 details access control and identity management.
- MFA for every user with console access, and preferably no IAM users at all: identities federated through IAM Identity Center.
- Unused access keys disabled after 45 days, active keys rotated every 90 days.
- References: CIS 1.9, 1.11, 1.13 and 1.20, FSBP IAM.5.
4. Least privilege, and no unintended external access
DORA, Article 9: grant only the rights a function needs. An over-broad role, or one shared with a third-party account, is often the first link of an attack.
- No policy granting
*:*; permissions attached through roles or groups. - IAM Access Analyzer enabled in every region, and its external-access findings handled.
- References: CIS 1.14, 1.15 and 1.19, FSBP IAM.1.
5. Controlled encryption at rest
DORA, Article 9: protect the confidentiality and integrity of data. Delegated Regulation 2024/1774 requires an encryption and key management policy.
- EBS encryption enabled by default in every region, encrypted RDS databases and EFS file systems.
- Customer-managed KMS keys for sensitive data, with rotation enabled.
- References: CIS 2.2.1, 2.3.1, 3.6 and 5.1.1, FSBP EC2.7, KMS.4 and RDS.3.
6. No unintended public exposure
DORA, Article 9: protect networks and prevent unauthorised access. A public bucket or an SSH port open to the internet cancels out the other protections.
- Block Public Access enabled at account level and on every S3 bucket.
- No security group or NACL opens administration ports (22, 3389) to
0.0.0.0/0or::/0; the default group blocks everything. - References: CIS 2.1.4 and 5.2 to 5.5, FSBP S3.1 and S3.8.
7. Complete, tamper-evident logging
DORA, Articles 10 and 12: detect anomalous activities and keep the records needed to analyse an incident.
- CloudTrail enabled in every region, with log file integrity validation and encryption with a KMS key.
- VPC flow logs enabled, at least for rejected traffic, with a defined retention period.
- References: CIS 3.1, 3.2, 3.5 and 3.7, FSBP CloudTrail.1, CloudTrail.2, CloudTrail.4 and EC2.6.
8. Active threat detection
DORA, Article 10: have mechanisms to detect anomalies promptly, with defined alert thresholds.
- GuardDuty enabled in every region, and its findings routed to a team that handles them.
- Security Hub enabled with the FSBP and CIS v5.0 standards, and CloudWatch alarms on sensitive events: root sign-in, IAM policy change, CloudTrail stopped, security group change.
- References: CIS 4.1 to 4.16, FSBP GuardDuty.1.
9. Isolated, restorable backups
DORA, Article 12: define backup policies, restore from systems segregated from the source, and test restoration regularly.
- AWS Backup plans covering critical resources, with copies to another account or region.
- A locked backup vault (AWS Backup Vault Lock) against deletion, and scheduled restore tests.
- References: FSBP RDS.11 and DynamoDB.2; AWS Backup restore testing for the drills.
10. An architecture that meets recovery objectives
DORA, Articles 11 and 12: a continuity policy, response and recovery plans, and recovery time and recovery point objectives.
- Multi-AZ databases, workloads spread across several Availability Zones, Route 53 health checks.
- RTO and RPO documented for each critical function, and multi-region recovery or AWS Elastic Disaster Recovery where the objective calls for it.
- References: CIS 2.2.4, FSBP RDS.5.
The ten controls in one table
| Control | DORA | References |
|---|---|---|
| Inventory and tagging | Art. 8 | CIS 3.3 · Config.1 |
| Locked-down root account | Art. 9 | CIS 1.3-1.6 · IAM.4, IAM.6, IAM.9 |
| Strong authentication, federated identities | Art. 9 | CIS 1.9, 1.11, 1.13, 1.20 · IAM.5 |
| Least privilege, external access | Art. 9 | CIS 1.14, 1.15, 1.19 · IAM.1 |
| Encryption at rest | Art. 9 | CIS 2.2.1, 2.3.1, 3.6, 5.1.1 · EC2.7, KMS.4, RDS.3 |
| No public exposure | Art. 9 | CIS 2.1.4, 5.2-5.5 · S3.1, S3.8 |
| Tamper-evident logging | Art. 10, 12 | CIS 3.1, 3.2, 3.5, 3.7 · CloudTrail.1, .2, .4, EC2.6 |
| Threat detection | Art. 10 | CIS 4.1-4.16 · GuardDuty.1 |
| Isolated, tested backups | Art. 12 | RDS.11, DynamoDB.2 |
| Recovery objectives | Art. 11, 12 | CIS 2.2.4 · RDS.5 |
Turning these controls into evidence
- Date every check: a configuration state is only meaningful at a given date.
- Name the resources that fail, not just the number of failures, and track their remediation in a register.
- Repeat: Article 24 requires testing, at least yearly, the systems that support critical or important functions. Between reviews, AWS Config and Security Hub monitor continuously.
- Report to management: Article 5 places ultimate responsibility for ICT risk on the management body.
The Silamir audit covers these ten themes on one AWS account, names every failing resource and produces a prioritised action plan and a summary for management, for USD 299 per audit. It does not run the restore tests themselves and does not issue a DORA certification.
AWS controls and DORA: frequently asked questions
Does DORA require specific AWS settings?
No. DORA and Delegated Regulation 2024/1774 set principle-based requirements: access control, encryption, logging, backup, continuity. The CIS AWS Foundations v5.0 and FSBP frameworks translate them into controls you can check on AWS.
With AWS a critical provider, are these controls still needed?
Yes. The designation places AWS under direct oversight by the European authorities, but Article 28 of DORA states that the financial entity remains fully responsible for its obligations. The configuration of your accounts is yours.
Are these ten controls enough to comply with DORA?
No. They provide evidence for Articles 8 to 12, on your AWS accounts. DORA also covers governance, incident management and reporting, testing, the register of information and contracts with providers.
How often should these controls be checked?
Continuously with AWS Config and Security Hub, and at least once a year as part of a dated review, as Article 24 requires for systems that support critical or important functions.
Where does your AWS account stand?
Ten questions, three minutes, no access to your account: a security score, a FinOps score and the article to read for each of your three weakest points. Your answers stay in your browser.
Ready to audit your AWS account?
Subscribe on AWS Marketplace, deploy the read-only role and get your reports within the hour.