Digital Operational Resilience Act (DORA)

DORA, the EU's Digital Operational Resilience Act, changed how financial firms are expected to treat technology risk. Officially Regulation (EU) 2022/2554, it requires banks, insurers, and the ICT providers they depend on to manage that risk as one tested, documented discipline, not a policy sitting in a drawer, but a system that actually runs.

The regulation has applied since 17 January 2025, replacing a patchwork of national ICT rules across the EU with a single, unified framework.

What does DORA stand for?

DORA stands for Digital Operational Resilience Act.

Adopted in December 2022, it's built around five pillars:

1. ICT risk management,
2. Incident reporting,
3. Resilience testing,
4. Third-party risk oversight, and
5. Information sharing.

Who does DORA apply to?

DORA covers 21 categories of financial entity, including banks, investment firms, payment institutions, insurers, and crypto-asset service providers.

It also reaches their ICT third-party providers, wherever those providers are based. A cloud vendor outside the EU is still in scope if it serves an EU financial entity.

Why DORA matters

Before DORA, financial firms mostly treated technology risk as something to insure against: set aside enough capital, and absorb the loss if something eventually broke.

DORA changes the question a firm has to answer.

It used to be, can we afford for this to fail? Now it's, can we prove we tested it, and can we recover fast? That's a harder bar, one built on continuous testing instead of an annual checklist, and on evidence instead of good intentions.

What DORA requires, in practice

Five things.

1. Identify ICT risk.
2. Protect against it.
3. Detect incidents fast.
4. Test resilience regularly.
5. Report major incidents on a strict timeline.

A sixth piece covers third-party providers directly, since a firm can be internally solid and still fail through a vendor.

Enforcement

Enforcement began in 2025 and is now active in 2026, but there's a detail worth getting right: DORA doesn't set one EU-wide fine amount. Article 50 leaves that decision to individual member states, and the result varies more than most coverage of DORA suggests.

Spain caps fines at 5% of turnover, Sweden at 10%. Czech Republic's absolute ceiling sits at €2 million, Italy's at €20 million. The "2% or €10 million" figure repeated across so much DORA content isn't something the regulation itself actually sets.

DORA vs. NIS2

DORA and NIS2 are both EU cybersecurity regulations covering critical sectors, but the relationship between them is about precedence, not competition.

For financial entities, DORA acts as lex specialis: wherever the two overlap, DORA's more specific rules take priority. That's worth checking directly rather than assuming, especially for an organization already running a NIS2 or EBA ICT risk program, since existing compliance there doesn't automatically satisfy DORA's requirements.

DORA vs. GDPR

GDPR and DORA aim at different targets, but they overlap more often than the names suggest. GDPR protects personal data, everywhere, in every sector. DORA protects ICT operational resilience, specifically for financial entities.

The two meet in practice more than you'd expect: a breach that exposes customer records during a system outage can trigger both regulations at once, each with its own reporting clock and its own authority to answer to.

Not to be confused with: DORA metrics

A separate, unrelated DORA exists in software engineering: DevOps Research and Assessment metrics, four measures of software delivery performance (deployment frequency, lead time, change failure rate, and time to restore).

It shares the acronym but nothing else; no connection at all to EU financial regulation.

Where Appknox fits

Appknox maps mobile application security findings to specific DORA articles automatically, primarily Article 8 (identification), Article 9 (protection and prevention), Article 10 (detection), and Article 25 (ICT testing), with broader support for Article 24's testing and remediation requirements.

A hardcoded API key becomes evidence under Article 9. An exposed backend endpoint becomes evidence under Article 25. The mapping turns a technical vulnerability into something a compliance team can use directly, without translating it themselves first.

For the full article-by-article mapping (Articles 8, 9, 10, 24, and 25) and how Appknox generates audit-ready evidence,

See: DORA Compliance for Mobile Apps.

Frequently asked questions

What does DORA stand for?

DORA stands for the Digital Operational Resilience Act, EU Regulation 2022/2554.

When did DORA take effect?

17 January 2025.

Who does DORA apply to?

21 categories of financial entity across the EU, plus the ICT third-party providers that support them, regardless of where those providers are based.

Is DORA the same as GDPR?

No. GDPR protects personal data across every sector. DORA governs ICT operational resilience specifically for financial entities. The same incident can trigger both.

Does a fixed fine amount apply across the EU under DORA?

No, there is no fixed fine amount under DORA. Article 50 leaves penalty amounts to individual member states, so maximum fines vary by country.

Related: DORA Compliance for Mobile Apps | What is MASVS? | Appknox Automated Vulnerability Assessment

By Aadarsh Anand, Security Researcher, Appknox Security Research Team

Appknox is an enterprise mobile application security testing platform. This page was written by Appknox's security research team based on direct experience mapping mobile application security findings to DORA and other regulatory frameworks across BFSI, insurance, and payments clients.

This page was drafted with AI assistance and reviewed and verified by the Appknox security research team.