DORA Covers Five Areas of Risk. Most Compliance Reviews Only Check One or Two.

A board asks a compliance officer a simple question: are we DORA compliant. The honest answer depends entirely on which part of DORA the board means.

DORA is not one requirement. It is a regulation built from five distinct obligations, each with its own timeline, its own technical standards, and its own way of going wrong. Treating it as a single checkbox is how organizations end up confident about the parts they have addressed and blind to the parts they have not.

Understanding what DORA actually covers, and who it applies to, is the first step to answering that board question honestly.

The problem DORA was built to solve

Financial services now run on technology supplied by a small number of providers: cloud platforms, payment processors, data centers. A disruption at one of those providers does not stay contained to one bank or one country.

The European Insurance and Occupational Pensions Authority (EIOPA) frames it directly: when ICT risk is not managed properly, it can disrupt financial services across borders, with knock-on effects for other companies, other sectors, and the wider economy (EIOPA, Digital Operational Resilience Act, accessed August 2026). DORA entered into application on 17 January 2025.

Before DORA, EU member states each had their own rules, or no rules, for digital resilience in finance. A bank in one country could face stricter technology oversight than a bank in another, while both relied on the same handful of global cloud and payment providers. DORA replaces that patchwork with one regulation that applies the same way across the whole EU.

The five areas DORA actually covers

EIOPA lists what DORA covers in six parts, which group into five core obligations plus a direct oversight mechanism for the most systemically important providers.

ICT risk management sets the baseline: entities need a documented framework for identifying the technology their business depends on and continuously monitoring it,. not a static policy reviewed once a year.

ICT-related incident management covers how entities detect, classify, and report incidents to regulators, including the timelines that determine how fast a major incident has to be escalated.

Digital operational resilience testing requires entities to run a testing program that ranges from basic checks to the most demanding form, threat-led penetration testing, for entities designated as systemically significant.

ICT third-party risk management addresses the providers entities rely on, including monitoring arrangements and the contractual terms that have to be in place before a provider is trusted with critical functions.

Information sharing creates a framework, currently voluntary, for entities to exchange threat intelligence and lessons from incidents with legal protection for good-faith sharing.

Oversight of critical third-party providers is the part that reaches beyond financial entities themselves: it gives EU supervisors direct authority over the technology companies whose failure would create system-wide risk (EIOPA, Digital Operational Resilience Act, accessed August 2026).

Who actually has to comply

DORA applies to roughly 20 different types of financial entities across the EU, a scope that goes well beyond banks. It includes insurance and reinsurance undertakings, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, and the critical ICT third-party providers that support them.

Not every obligation applies with equal intensity to every entity. Threat-led penetration testing is reserved for entities a national authority formally designates as significant, typically the largest banks, major insurers, and systemically important market infrastructure. Baseline ICT risk management and incident reporting apply far more broadly, to smaller payment institutions and investment firms as well.

A mid-sized insurer and a global systemically important bank are both in scope, but the intensity of what DORA expects from each differs substantially. This is where the "are we compliant" question gets genuinely complicated: an entity can be fully compliant with four of the five areas and still have a material gap in the fifth, and the gap that matters most depends entirely on the entity's size and role.

Key insight: DORA is an operational resilience regulation, not a cybersecurity one

DORA reads like a cybersecurity regulation, but it functions as an operational resilience regulation enforced through cybersecurity mechanisms. The distinction is not semantic.

A cybersecurity regulation asks whether an organization can stop an attack. DORA asks whether an organization can keep operating, and prove to a regulator that it can keep operating, when something in its technology stack fails, regardless of whether the cause was an attacker, a vendor outage, or an internal error.

That framing changes what "readiness" should mean in practice. It is less about a single control and more about whether the organization can demonstrate, on demand, that its people and its systems behave the way its documentation says they will.

For a compliance or security leader, the useful exercise is not asking "are we DORA compliant" as one question, but mapping each of the five areas separately and being honest about where the evidence is thin.

Two areas where that evidence gap shows up most often are incident classification under time pressure and resilience testing against realistic attacker behavior. How the four-hour incident notification clock actually works in practice, and why threat-led penetration testing needs to account for AI-enabled fraud tactics like voice cloning, which the FBI's own 2025 data shows are no longer an edge case, are worth examining directly.

Neither is solved by a policy document alone. Both depend on people making the right call under real conditions, which is a capability worth testing directly rather than assuming.

Consider the gap this creates in practice. An entity can have a fully documented incident response plan, a signed-off testing calendar, and a clean audit trail, and still discover during an actual incident that the person on call cannot apply the classification criteria fast enough, or that the red team scenario never accounted for a caller who sounds exactly like a trusted colleague. Documentation proves the plan exists. It does not prove the plan works under pressure.

DORA is still being implemented in stages. Technical standards continue to be finalized, registers of information continue to be refined year over year, and supervisors are moving from dialogue to active review of what entities have actually done, not just what they have documented.

The organizations that treat DORA as five separate, ongoing obligations, rather than one project with an end date, are the ones least likely to be caught explaining a gap they did not know they had.

That distinction also determines how a compliance function should report progress internally. A single "DORA readiness: 80% complete" figure on a board slide hides which 20% is missing, and the missing piece in incident reporting carries a very different risk than the missing piece in third-party oversight. Reporting progress area by area takes longer to prepare, but it gives the board an accurate picture instead of a comforting one.