DORA Explained for Security Teams: What Changes in Practice
The EU Digital Operational Resilience Act translated into engineering terms: who is in scope, what incident reporting really requires, TLPT, and why your vendor register just became a regulated artifact.
What DORA is and why you should care
The Digital Operational Resilience Act, formally Regulation (EU) 2022/2554, has applied across the EU since 17 January 2025. As a regulation (not a directive), it applies directly in every member state with no national transposition to wait for. If you work in security at a financial entity operating in the EU, or at a company selling ICT services to one, DORA is not a future problem. It is the current baseline.
The one-sentence version: DORA assumes incidents will happen and regulates how well you withstand, respond to, and recover from them. It is less interested in whether you have a firewall and more interested in whether you can prove your critical services survive when things break.
The regulation stands on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Below is what each one means when translated out of legal language.
Who is in scope
DORA covers roughly 20 categories of financial entities: banks, payment and e-money institutions, investment firms, trading venues, insurers and reinsurers, crypto-asset service providers, fund managers, and more. Around 22,000 entities across the EU.
Two things security teams often miss:
- Proportionality is real but limited. Microenterprises and some smaller entities get lighter requirements, but "we are small" is not an exemption from the core obligations.
- ICT providers are pulled in too. If you sell software, cloud, or data services to financial entities, DORA reaches you contractually through your customers. Providers designated as critical ICT third-party providers (think major cloud platforms) additionally fall under direct oversight by the European Supervisory Authorities, with a lead overseer, inspection powers, and penalties.
Pillar 1: ICT risk management
DORA requires a documented ICT risk management framework owned explicitly by the management body. Board members are accountable for it, must approve it, and are expected to maintain sufficient knowledge to challenge it. That accountability shift is quietly one of the biggest changes: resilience stops being a delegated IT topic.
In engineering terms, the framework demands things a mature security program should recognize:
- A complete, current inventory of ICT assets and dependencies, mapped to the business functions they support.
- Identification of critical or important functions and the systems behind them. This classification drives almost everything else in DORA, from testing scope to reporting.
- Protection, detection, and monitoring capabilities appropriate to those functions.
- Backup, restoration, and recovery policies that are tested, with defined recovery objectives.
- Post-incident reviews that feed lessons back into the framework.
None of this is exotic. What changes is the evidentiary standard: regulators can ask you to show the inventory, the mapping, the test results, and the board sign-off. "We do this informally" no longer counts as doing it.
Pillar 2: Incident classification and reporting
Every ICT-related incident must be logged and classified against harmonized criteria: clients and counterparts affected, duration and service downtime, geographical spread, data losses, criticality of services affected, and economic impact. Incidents crossing the thresholds become major incidents and trigger mandatory reporting to your competent authority.
Reporting follows a three-stage structure defined in the implementing technical standards:
| Report | Deadline |
|---|---|
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it |
| Intermediate report | Within 72 hours of the initial notification, then updates on significant change |
| Final report | Within one month of the intermediate report (or its latest update) |
Read those timelines as an engineer and the implications are concrete. Classification against the criteria must happen during the incident, not in the retrospective, which means your IR process needs the classification logic built into triage. The 4-hour clock starts at classification, so ambiguity about who classifies and how costs you your entire buffer. And the final report expects root cause analysis, so evidence preservation and timeline-keeping during response are now regulatory requirements, not just good DFIR hygiene.
Practical translation: your playbooks need a DORA branch. Who assesses the classification criteria, who drafts the notification, who owns the authority relationship, and where the incident timeline lives. Teams running structured incident workflows in a platform like mlab IR have an easier time here, because the timeline and evidence trail the final report requires are produced as a side effect of response rather than reconstructed afterwards. Voluntary reporting of significant cyber threats (near misses that could have been major) also exists; a threat intelligence function gives you something worth submitting.
Pillar 3: Resilience testing, including TLPT
All in-scope entities need a digital operational resilience testing programme: vulnerability assessments and scans, open source analyses, network security assessments, scenario-based tests, and penetration testing, executed at least yearly on systems supporting critical or important functions by independent parties (internal or external).
The headline requirement is TLPT: threat-led penetration testing, mandated by Article 26 for entities designated by their authorities. TLPT is not a standard pentest:
- It runs against live production systems supporting critical functions.
- Scenarios are built from actual threat intelligence about the actors and TTPs targeting the entity, aligned with the TIBER-EU framework.
- It covers people, processes, and technology, meaning phishing and detection evasion are in scope, and the blue team is not warned.
- Cadence is at least every three years, with the scope and providers validated by the authority.
For security teams, TLPT changes the posture question from "did the pentest find bugs" to "did our SOC detect a realistic adversary emulation before it reached crown jewels." If your detection coverage mapping is aspirational, TLPT will make that public inside your organization.
Pillar 4: ICT third-party risk and the register of information
DORA treats your vendors as part of your attack surface, and regulates them through you.
Every financial entity must maintain a register of information covering all contractual arrangements with ICT third-party providers, flagged by whether they support critical or important functions. This register is reported to authorities on request and feeds the EU-wide designation of critical providers. It is a regulated artifact with a mandated structure; a spreadsheet someone updates twice a year will not survive contact with a supervisor.
Beyond the register, DORA requires:
- Pre-contract risk assessment of every ICT provider, proportionate to criticality, including concentration risk (what happens when half your critical functions sit on one cloud).
- Mandatory contract clauses (Article 30): service levels, security requirements, incident cooperation, audit and access rights, data location, and support for exit. Contracts for critical functions carry extended requirements including termination rights and exit strategies.
- Exit strategies that are actually documented and plausible, because "we could never leave this vendor" is now a finding.
This pillar is where most security teams have the least existing tooling. Vendor risk has historically lived in procurement spreadsheets and annual questionnaires, neither of which produces the continuously current register and ongoing monitoring DORA expects. Purpose-built platforms exist for exactly this gap: mlab TPRM implements DORA-aligned third-party risk management, including the register of information, vendor tiering by criticality, and continuous monitoring, and is self-hosted so the vendor data never leaves your control.
Pillar 5: Information sharing
DORA explicitly permits and encourages financial entities to exchange cyber threat intelligence (indicators, TTPs, alerts) within trusted communities, with safeguards. This is the shortest pillar but a useful one: it removes the legal ambiguity that made some EU institutions hesitant to share IOCs. If your team was waiting for permission to join a sharing community, this is it.
Where to start if you are behind
A pragmatic ordering for a security team that reads this and feels the gap:
- Map critical or important functions to systems and providers. Everything else keys off this.
- Build the register of information. It is concrete, auditable, and forces the vendor conversation.
- Wire classification into IR. Add the major-incident criteria and reporting clocks to your playbooks and run one tabletop against them.
- Baseline your testing programme and find out whether your authority intends to designate you for TLPT.
- Remediate contracts on renewal, prioritizing providers supporting critical functions.
DORA does not ask whether you can prevent incidents. It asks whether you can prove you will survive them. For once, the regulation and the engineering agree on what matters.
