Audit your cloud against DORA with Prowler Cloud: the five pillars, mapped to real checks for AWS and Azure

If you work in financial services in the EU, DORA stopped being a future deadline a while ago. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has been mandatory since 17 January 2025, and it applies to a long list of entities: banks, insurers, investment firms, payment institutions, and the Information and Communication Technology (ICT) third-party providers that serve them. The regulation is broad. It covers governance, incident reporting, resilience testing, third-party risk, and information sharing. Much of it is organisational and contractual work that no scanner can do for you.

A meaningful slice of DORA is technical, though, and technical controls are exactly the kind of thing that should be measured continuously rather than attested once a year in a spreadsheet. That slice is what Prowler now maps. DORA is available as a compliance framework in Prowler, so you can take the cloud configuration you already run and ask a concrete question: where do I actually stand against DORA’s ICT requirements, today?

Why this matters now

The hard part of DORA compliance is rarely “we don’t know the rule exists.” It’s the translation gap. Article 9 says financial entities must implement policies and protocols for strong authentication mechanisms and data protection. Fine, but which of your hundreds of cloud settings prove that? Is your root account using MFA? Are your EBS volumes and RDS instances encrypted? Is public access blocked on the buckets that hold customer data? DORA tells you the intent. It doesn’t hand you the checklist for your specific cloud.

Closing that gap by hand means reading each article, deciding which configuration evidences it, and then re-checking it every quarter. That’s the work nobody has time for. Prowler’s DORA mapping does the translation once, in the open, so every scan produces evidence aligned to the articles auditors actually cite.

What’s in Prowler’s DORA framework

DORA in Prowler is a single, declarative compliance framework organised the way the regulation is, around its five pillars and the underlying articles. Today it ships with AWS coverage: 202 unique AWS checks mapped across 18 requirements, spanning 18 articles and all five pillars. Check it on the Prowler Hub.

Here is how the coverage breaks down:

• ICT Risk Management (Art. 5–14) — root account hygiene and MFA, least privilege, config recording, encryption in transit and at rest, GuardDuty and Security Hub detection, backup and point-in-time recovery.
• ICT-Related Incident Reporting (Art. 17, 18, 19) — CloudTrail and CloudWatch logging, log integrity, alerting and metric filters that make incidents detectable and classifiable.
• Digital Operational Resilience Testing (Art. 24, 25) — vulnerability scanning with Inspector, Access Analyzer, configuration assessment of ICT tools and systems.
• ICT Third-Party Risk Management (Art. 28, 30) — visibility and control over externally-exposed resources, cross-account access, and the configuration evidence behind provider relationships.
• Information Sharing (Art. 45) — threat-intelligence-relevant detection services and findings aggregation.

The heaviest-weighted articles are the ones you’d expect from a cloud-config lens. Article 9 (Protection and prevention) carries 33 checks, Article 12 (Backup, restoration and recovery) carries 27, and Article 17 (ICT-related incident management) carries 22. That distribution isn’t arbitrary. It reflects where cloud configuration carries the most regulatory weight.

How to run it

If you already use Prowler, there’s nothing new to learn. DORA is just another value passed to --compliance:

prowler aws --compliance dora

That runs the DORA-relevant checks against your AWS account and produces a compliance report keyed to the pillars and articles above.

The faster path is Prowler Cloud. Connect an account once and DORA shows up alongside your other frameworks in the compliance view, grouped by pillar, so you can see at a glance which areas are passing and which need attention. Scans run on a schedule, so the per-pillar score stays current without anyone remembering to re-run a command; findings carry full history, so you can show an auditor not just where you stand today but that you’ve held that posture over time. You get the same evidence trail described below, plus a hosted dashboard your GRC team and engineers can share. There’s a free tier to get started, so you can have a real DORA score against a live account in minutes, before you commit to anything.

Outputs built for auditors, not just engineers

A compliance scan is only useful if you can hand the result to someone. Prowler’s DORA framework outputs CSV and OCSF records that carry the Pillar, Article, and Article Title for every result, so each finding is already labelled with the regulatory clause it evidences. There’s no post-processing to map a finding back to “which article was this again?”

Because every result is tagged at the article level, the output doubles as an evidence trail. When an auditor asks to see your controls for Article 9, the answer is a filter, not a research project.

What Prowler does, and what it deliberately doesn’t

DORA is far larger than anything a cloud scanner can assess. Prowler’s mapping covers the technical controls auditable from cloud configuration: encryption, identity, logging, detection, backup, exposure. It does not cover the organisational, contractual, and supervisory obligations DORA imposes, such as your ICT risk governance documents, your third-party register and contract clauses, your threat-led penetration testing programme, or your incident-reporting timelines to competent authorities.

Think of Prowler’s DORA framework as the part of your evidence package that should be continuous and automated, sitting underneath the policy and process work your GRC team owns. It tells you whether your cloud is actually configured the way your DORA documentation claims it is.

Built to grow beyond AWS

DORA is implemented on Prowler’s universal compliance schema, a single declarative file that describes the framework once and derives its provider coverage from the checks mapped to each requirement. In practice that means the framework is AWS-populated today but architecturally multi-cloud. Azure, GCP, and other providers can be added to the same articles without restructuring anything. Financial entities rarely live in one cloud, and DORA doesn’t care which cloud a failure happened in, so neither should the framework.

Where to start

The quickest way to see where you stand is to connect one AWS account to Prowler Cloud on the free tier and open the DORA view. Prefer the CLI? Run prowler aws --compliance dora. Either way, read the per-pillar score and start with the heaviest articles: protection (Art. 9), backup and recovery (Art. 12), and incident management (Art. 17), because that’s where cloud misconfigurations carry the most regulatory exposure. Fix, re-scan, and watch the per-pillar score move.

DORA compliance isn’t a one-time certificate. It’s an operational state you have to keep proving. Prowler turns “are we still compliant?” from a quarterly fire drill into a question you can answer on any given day.

Try it free at cloud.prowler.com · Book a live demo