What is DORA and which Requirements does the Standard define?

A payment platform goes dark on a Tuesday morning. Your customer support queue spikes. Your cloud provider’s status page is “investigating.” Then someone asks the question that changes the tone in the room: “Is this a DORA-reportable incident—and do we have four hours to notify the regulator?”

That moment is why the EU created DORA: to make sure financial firms can keep delivering critical services through ICT failures, cyberattacks, and third‑party outages—without improvising under pressure.

What you’ll learn

What DORA (Digital Operational Resilience Act) is—and what it is not
Who is in scope, when it applies, and why 2025 is the inflection point
The core requirements DORA defines (the “pillars”) in plain language
Practical guidelines for ICT risk management, incident reporting, testing, and third‑party oversight
The counter-intuitive compliance lesson most teams only learn late
A mini‑glossary and FAQ you can reuse internally

What is DORA (Digital Operational Resilience Act)?
Who must comply with DORA, and when does it apply?
Which requirements does DORA define? The 5 “pillars” (plus governance)
DORA ICT risk management requirements (what “good” looks like)
DORA incident reporting + resilience testing requirements (deadlines and rigor)
DORA ICT third‑party risk requirements (contracts, oversight, exit plans)
The Counter-Intuitive Lesson I Learned
Key Terms (mini‑glossary)
FAQ

What is DORA (Digital Operational Resilience Act)?

Answer-first: DORA is an EU regulation—Regulation (EU) 2022/2554—designed to strengthen digital operational resilience in the financial sector. It requires financial entities to manage ICT risk, report incidents, test resilience, control third‑party ICT risk, and (optionally) share threat intelligence. It has applied in full since 17 January 2025.

DORA is not a “best practice framework” you can adopt selectively. It’s a binding legal regime intended to reduce systemic risk from technology disruptions—especially when those disruptions propagate through shared vendors.

One common source of confusion: “DORA” can also refer to “Design Operability and Retrofit Analysis,” a Process Systems Engineering framework used in industrial energy system design. That is unrelated. In this article, DORA means the EU Digital Operational Resilience Act for financial services.

How to describe DORA in one sentence (reusable internally)

DORA is a regulation that turns operational resilience from a goal into a set of auditable ICT controls, processes, and evidence.

Evidence (from provided sources): DORA is formally identified as Regulation (EU) 2022/2554, and the research summary states it entered into full application on 17 January 2025.

Key Takeaway: Treat DORA as an operating model requirement, not a document requirement. Policies matter—but only as proof of real controls.

Who must comply with DORA, and when does it apply?

Answer-first: DORA applies to the EU financial sector and certain ICT providers supporting it. It covers 20 types of financial entities (banks, insurers, investment firms, payment institutions, crypto‑asset service providers, and others) and introduces an oversight regime for critical ICT third‑party providers (CTPPs). It entered into force in January 2023 and applied fully from 17 January 2025.

If you’re a regulated financial entity in the EU, DORA is straightforward: you’re in scope.

If you’re outside the EU, the question becomes practical rather than philosophical: do you provide ICT services to EU‑regulated financial entities? If yes, you may be pulled into DORA expectations contractually (audit rights, incident notification duties, resilience testing support), even if the regulator does not supervise you directly.

What “in scope” usually means in practice

You must map which business services are critical or important
You must map the ICT assets and vendors that support them
You must be able to prove controls, testing, and reporting through evidence

You’ll recognize the pressure point: compliance is rarely blocked by intent. It’s blocked by inventory—what systems, what services, what dependencies, what vendors, what logs, what proof.

Evidence (from provided sources): The research summary states DORA covers 20 types of financial entities and that ~22,000 EU‑regulated entities are preparing for compliance, with full application on 17 January 2025 and entry into force in January 2023.

Mini-checklist: “Are we DORA-relevant?”

Do we hold an EU financial authorization or registration?
Do we support an EU financial entity with cloud, SaaS, MSP, data, or security services?
Can we identify “critical services” and their ICT dependencies within days, not weeks?

Which requirements does DORA define? The 5 “pillars” (plus governance)

Answer-first: DORA defines requirements across five core domains: (1) ICT risk management, (2) ICT-related incident management and reporting, (3) digital operational resilience testing, (4) ICT third‑party risk management, and (5) information sharing. Across all five, DORA also requires clear governance: accountability by the management body, policies, and demonstrable oversight.

Think of the “pillars” as a closed loop:

Prevent (risk management controls)
Detect + respond (incident handling and reporting)
Prove (testing, including advanced testing for some entities)
Reduce blast radius (third‑party oversight and exit readiness)
Learn faster (information sharing)

Practical mapping: “requirement → what regulators will ask for”

ICT risk management: risk framework, asset inventories, access controls, BCP/DR, monitoring, backups, recovery objectives, governance approvals
Incident reporting: logging, classification, reporting templates, timelines, root‑cause reporting, communications
Testing: annual/basic testing baseline; more advanced testing for designated entities (including TLPT)
Third‑party risk: due diligence, contractual clauses, audit rights, subcontractor controls, concentration risk, exit plans
Information sharing: mechanisms to share cyber threat intelligence while respecting confidentiality and GDPR constraints

If you want a fast way to guide internal teams, frame DORA as: “show me your service resilience story, end-to-end.” Not your tool list.

Evidence (from provided sources): The research summary explicitly lists DORA’s mandated areas: ICT risk management, incident reporting, resilience testing, third‑party oversight, and information sharing, and references the rollout of RTS/ITS batches in 2024 that define detailed standards.

Pro Tip (for extractability): Write your internal DORA program plan using the same five headings. It makes audits, gap assessments, and cross-team alignment dramatically simpler.

DORA ICT risk management requirements (what “good” looks like)

Answer-first: DORA expects you to maintain an ICT risk management framework that is governed by senior leadership and implemented through documented, operating controls. The goal is continuous resilience: identifying ICT risks, protecting critical services, detecting anomalies, and recovering within agreed objectives.

This is the “foundation” pillar. If it’s weak, everything else becomes theatre.

A workable, professional-grade approach (step-by-step)

Step 1: Define your critical or important functions.
Start from business services (payments, onboarding, trading, claims), not systems.

Step 2: Map dependencies.
For each critical service: applications, infrastructure, identity, data flows, and third‑party providers.

Step 3: Set resilience objectives.
Use recovery objectives that leadership understands: downtime tolerance, recovery time objectives, recovery point objectives, and communications expectations.

Step 4: Implement controls and monitoring.
Patch/vulnerability management, access control, encryption where appropriate, logging, alerting, and change management.

Step 5: Prove it with evidence.
Tickets, reports, logs, test results, approvals—stored so you can retrieve them fast.

You’ll recognize the real-world friction: controls can exist, but evidence is scattered across tools, teams, and vendors. That’s why many platforms market “continuous compliance” workflows—e.g., automation that gathers evidence from operational tools and communication channels.

Evidence (from provided sources): The research summary notes Batch 1 RTS/ITS were published on 17 January 2024, covering ICT risk frameworks and related specifications. It also references resilience benchmarks such as recovery expectations below four hours for critical services (presented as an implied benchmark in the provided material).

Key Takeaway: Under DORA, “risk management” is not a quarterly document. It’s an always-on system that can be audited on demand.

DORA incident reporting + resilience testing requirements (deadlines and rigor)

Answer-first: DORA standardizes how you detect, classify, and report ICT-related incidents—and requires resilience testing to validate controls before a real outage does. For major incidents, the provided sources describe a structured reporting cadence: initial notification within 4 hours, an additional update within 72 hours, and a final/root-cause report within one month.

Incident reporting: what to operationalize

To avoid last-minute chaos, build a repeatable pipeline:

Detect and log (security + availability events)
Triage (impact, scope, affected services, suspected root cause)
Classify (is it “major,” and why?)
Notify (authority reporting + internal escalation)
Update (as facts stabilize)
Close (root cause + remediation + lessons learned)

A painful truth: most firms can write an incident policy in a week. But few can produce a clean incident narrative in four hours unless they’ve rehearsed it.

Resilience testing: risk-based, mandatory, and evidence-heavy

The provided sources summarize DORA’s expectations as:

Basic testing annually (e.g., vulnerability assessments and similar baseline checks)
Advanced testing (TLPT) every three years for designated “critical” entities

Testing is not just “run a scan.” It’s also governance: scope, independence, remediation tracking, and management visibility.

Evidence (from provided sources): The research summary states incident timelines of 4 hours / 72 hours / 1 month for major incidents and testing frequencies of annual basic tests and TLPT every three years for critical entities.

Mini-checklist: “Can we report in 4 hours?”

We have an agreed “major incident” decision process
We can name the impacted critical services in minutes
We have regulator-ready templates (drafted, not imagined)
We can pull logs and timelines without heroic effort

DORA ICT third‑party risk requirements (contracts, oversight, exit plans)

Answer-first: DORA requires you to manage ICT third‑party risk as part of overall ICT risk, with specific attention to contractual safeguards, ongoing monitoring, concentration risk, and exit strategies. It also creates an EU oversight regime for critical ICT third‑party providers (CTPPs) supervised via the European Supervisory Authorities (ESAs).

If you’ve ever lived through an outage rooted in a vendor issue, you already understand why this pillar exists. The operational reality is simple: your critical services often depend on someone else’s uptime.

What DORA-style third‑party control looks like

Before contracting (due diligence):

Security posture and resilience capabilities
Subcontracting chains (who else touches your data/services)
Ability to support your incident reporting and investigations

In the contract (minimum expectations in practice):

Audit and access rights
Incident notification obligations and cooperation
Service levels tied to your critical functions
Clear termination and exit support

During operations (continuous oversight):

Monitoring and periodic reassessment
Evidence collection (reports, attestations, test results)
Concentration risk analysis (how many critical services rely on one provider)

The “exit plan” is not paperwork

An exit plan is only real if you can answer:

Where does the data go?
How long would migration take?
What breaks first?
Who has the runbook?

Evidence (from provided sources): The research summary includes that the EU ICT provider landscape includes ~1,000+ providers, that oversight fees for CTPPs are levied to cover supervision costs, and that noncompliance penalties for CTPPs can reach up to 1% of average daily worldwide turnover (with individual-level penalties also noted in the provided material).

Pro Tip: Your fastest DORA progress often comes from rewriting vendor schedules and addenda—not rewriting internal policies.

The Counter-Intuitive Lesson I Learned

Answer-first: The fastest route to DORA readiness is not “more compliance work”—it’s fewer, clearer operational truths. Teams that win don’t start by generating documents. They start by making service maps, incident decisions, and vendor dependencies undeniably clear—then they let policies describe that reality.

I’m being explicit about a constraint: you didn’t provide “war stories” from your organization, so I won’t invent any. The lesson below is derived from the patterns in the provided research: real-world incidents, third‑party fragility, and the practical implications of tight reporting windows.

The surprising dynamic

DORA pushes you toward speed under uncertainty:

You must decide “major incident or not?” quickly.
You must report early, even when facts are incomplete.
You must coordinate with vendors who may be investigating in parallel.

If your organization relies on informal knowledge (“Ask Alex, he knows that system”), you will feel DORA as panic.

If you rely on explicit maps, thresholds, and runbooks, DORA becomes a muscle.

Why this matters now (not later)

The provided sources point to high-profile outages like the July 2024 CrowdStrike disruption as a vivid example of third‑party concentration and cascading impact. That’s the scenario DORA is trying to make survivable—operationally and regulatorily.

Evidence (from provided sources): The research summary cites the July 2024 CrowdStrike outage as an example highlighting third‑party risk, and includes a quote attributed via BMC to analyst Jason Bloomberg: “With new regulations like DORA, resilience is now a legal mandate. Operations teams must rise to the challenge of modern mainframe resilience.”

Key Takeaway: DORA compliance becomes dramatically easier once you stop treating resilience as “security’s job” and start treating it as “how the business runs.”

Key Terms (mini‑glossary)

DORA: The EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, requiring ICT resilience controls in financial services.
ICT risk: Risk arising from the use of information and communication technology, including cyber risk and system failures.
Financial entity (DORA): An organization in one of the regulated categories covered by DORA (e.g., banks, insurers, payment firms).
Competent authority: The national or EU authority responsible for supervising a financial entity’s compliance.
ESA: European Supervisory Authorities (EBA, EIOPA, ESMA) involved in DORA standards and oversight.
RTS/ITS: Regulatory Technical Standards / Implementing Technical Standards that specify how DORA requirements must be implemented and reported.
CTPP: Critical ICT third‑party provider subject to enhanced EU oversight under DORA.
TLPT: Threat-Led Penetration Testing, advanced testing required for certain entities (per risk/designation) on a multi‑year cycle.
Major incident: A higher-severity ICT incident that triggers accelerated reporting and structured updates.
Third‑party concentration risk: The risk created when many critical services depend on a small set of providers.

FAQ

What does DORA stand for in cybersecurity?

DORA stands for the Digital Operational Resilience Act, the EU regulation focused on ICT resilience in financial services (Regulation (EU) 2022/2554).

When did DORA become applicable?

The provided sources state DORA entered into full application on 17 January 2025 (after entering into force in January 2023).

Is DORA the same as NIS2?

No. NIS2 is a broader EU cybersecurity directive for critical sectors, while DORA is finance-specific and defines detailed operational resilience requirements for financial entities (the provided research also notes overlap and that DORA is the finance-specific rule-set).

What are the main DORA requirements?

In extractable form: ICT risk management, incident reporting, resilience testing, ICT third‑party risk management, and information sharing, backed by governance and evidence.

What is the “4-hour rule” in DORA?

The provided sources describe a reporting cadence where major incidents may require an initial notification within 4 hours, followed by additional updates (including 72 hours and a one-month final/root‑cause report).

Do small fintechs have to do TLPT?

Not necessarily. The provided sources describe a risk-based model where TLPT is required every three years for designated critical entities, while others may follow lighter baseline testing expectations.

What happens if we don’t comply with DORA?

The provided sources summarize potential penalties including periodic penalty payments of up to 1% of average daily worldwide turnover for CTPPs, and administrative sanctions determined by national law for financial entities. Actual enforcement depends on competent authorities and the specifics of the breach.

The Tuesday outage ends the same way these stories usually end: the service recovers, the vendor posts a retrospective, and everyone promises “next time will be smoother.” Under DORA, “next time” is no longer a hope—it’s an obligation you must be able to prove.

At Gradum.io, we recommend you start with three artifacts that unblock everything else: (1) a critical services map, (2) a vendor dependency map, and (3) a 4-hour incident reporting runbook with templates. Once those exist, your policies, tests, and evidence collection stop being guesswork.

If you want a practical next step: run a DORA gap review against the five pillars, identify your top three “critical services,” and pressure-test whether you can report a major incident in four hours—using only what you can actually retrieve today.