Executive Summary
- DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. Because it is a regulation, not a directive, it is directly applicable across all EU member states with no national transposition, and it has applied since 17 January 2025.
- Scope is broad: roughly twenty categories of financial entities (banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and more) plus the ICT third-party service providers that serve them. Critical providers fall under a new EU-level oversight framework.
- The substance sits in five pillars: ICT risk management, incident management and reporting, resilience testing (including threat-led penetration testing for significant entities), ICT third-party risk management and information sharing. Proportionality applies, but the management body is explicitly accountable.
- Professnet delivers DORA readiness as an operational practice, not a binder of policies. We operate the controls our regulated clients are measured against: a 24/7 Managed SOC, incident classification and reporting workflows, ICT risk tooling and the evidence trail an auditor or competent authority will ask to see.
What Is DORA, and Why Does It Matter?
DORA (the Digital Operational Resilience Act) is the European Union’s harmonised rulebook for how financial entities manage technology risk. Its formal name is Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. It was published in the Official Journal (L 333) on 27 December 2022 and has applied since 17 January 2025.
The premise is simple and, for anyone who has run production systems in a bank, overdue. Financial stability now depends on the continuous availability and integrity of ICT systems. A trading platform that goes dark, a core banking ledger corrupted by ransomware, or a cloud provider outage that takes down payments processing is no longer just an IT incident. It is a prudential risk. DORA treats it as one.
Why “Regulation” Is the Word That Matters
Key fact: DORA is a regulation, not a directive. A directive (such as NIS2, Directive (EU) 2022/2555) sets goals that each member state must transpose into national law, which produces twenty-seven slightly different implementations. A regulation is directly applicable: the same text, the same obligations and the same articles apply identically in Warsaw, Frankfurt and Dublin. For a group operating across borders, that is a meaningful simplification. You comply with one instrument, supplemented by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities.
The flip side: there is no national grace period or local watering-down to hide behind. The obligations took effect on the application date for everyone in scope at once.
Who Is in Scope?
Quick answer: almost every regulated financial entity in the EU, plus the technology firms they depend on.
DORA enumerates the financial entities it covers. The list runs to around twenty categories and includes credit institutions, payment institutions and electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories and the management companies behind investment funds, among others. If you hold an EU financial licence, you should assume you are in scope until you have confirmed otherwise.
The second population is new and is what makes DORA different from earlier guidance. ICT third-party service providers, meaning the vendors that supply network, software, data-processing, cloud and other digital services to financial entities, are pulled into the framework. Most are reached indirectly through contractual obligations their financial-entity customers must impose. A subset designated as critical are reached directly through an EU-level oversight regime described below.
Proportionality
DORA is not a flat mandate. It is built to be applied proportionally, taking into account an entity’s size, risk profile and the nature, scale and complexity of its services. A large systemic bank and a small payment institution do not face identical implementation burdens. A simplified ICT risk management framework is available to certain smaller and less complex entities. Proportionality is a calibration tool, however, not an exemption. The objective is the same for everyone; the depth of the controls scales with the risk you actually carry.
What Are the Five Pillars?
The operative requirements of DORA are usually grouped into five pillars. Treating them as five separate programmes is a mistake. They share evidence, tooling and ownership, and they are most efficiently built as one integrated operating model.
1. ICT Risk Management Framework
This is the foundation. Each financial entity must maintain a sound, documented ICT risk management framework: governance and accountability, identification of ICT-supported business functions and the assets that underpin them, protection and prevention controls, mechanisms to detect anomalous activity, and tested response, recovery, backup and business continuity arrangements. In plain terms, you must know what you run, what depends on it, how you defend it, how you would notice an attack, and how you would come back from a bad day. The framework must be reviewed regularly and after major incidents.
2. ICT-related Incident Management, Classification and Reporting
DORA standardises how incidents are handled and, critically, how they are reported to authorities. Entities must detect, manage and log ICT-related incidents, then classify them against harmonised criteria covering factors such as the number of clients affected, duration, geographical spread, data losses and economic impact. Major incidents must be reported to the competent authority on a defined timeline using a structured template, typically an initial notification, an intermediate report and a final report once the root cause is understood. Significant cyber threats may be reported on a voluntary basis. The practical implication is that incident response can no longer be an informal, heroics-driven activity. It needs a repeatable classification decision and a clock you can prove you met.
3. Digital Operational Resilience Testing
Frameworks that are never tested are theatre. DORA requires a risk-based testing programme covering the full range of appropriate tests: vulnerability assessments, scans, open-source analyses, network security assessments, gap analyses, penetration testing and scenario-based testing. On top of this baseline, financial entities identified as significant must perform threat-led penetration testing (TLPT) at least every three years. TLPT means a controlled red-team exercise driven by realistic threat intelligence against live production systems, building on the European TIBER-EU framework. It is demanding, it involves your real environment, and it tends to surface the gaps that tabletop reviews miss. ICT third-party providers supporting the tested functions must be included where relevant.
4. Management of ICT Third-party Risk
This pillar is where many institutions have the most work, because it forces visibility most have never had. Two requirements stand out. First, every financial entity must maintain a register of information: a complete, structured, continuously updated inventory of all contractual arrangements for ICT services, distinguishing those that support critical or important functions. This register is submitted to the competent authority and was the dataset the European Supervisory Authorities used to designate critical providers. Second, contracts with ICT providers must include specific mandatory terms: clear service descriptions, full data access and audit rights, defined service levels, assistance during incidents, cooperation with supervisors and structured exit strategies so that a single provider can be replaced without endangering operations. Concentration risk, the danger of too many institutions depending on the same handful of cloud and software vendors, is an explicit concern.
5. Information and Intelligence Sharing
DORA encourages, but does not compel, financial entities to share cyber threat information and intelligence with one another within trusted communities. The logic is collective defence: a tactic seen at one bank is forewarning for the next. Sharing must respect competition law and data protection. This is the lightest pillar in terms of hard obligation, and the easiest to neglect, yet it is where a mature SOC earns disproportionate value.
What Is the Oversight Framework for Critical Providers?
DORA does something earlier financial regulation could not: it reaches the technology supply chain directly. Under the Oversight Framework, the European Supervisory Authorities (the EBA, EIOPA and ESMA, acting through their Joint Committee) designate certain ICT third-party providers as critical (CTPPs) based on systemic importance to the EU financial sector. Each designated provider is assigned a Lead Overseer, which can examine it, request information, issue recommendations and ultimately apply penalties for non-compliance.
Key fact: the Joint Committee of the ESAs published the first list of designated critical ICT third-party providers in November 2025, under Article 31 of DORA. This is the mechanism by which the largest hyperscale cloud and software providers come under direct EU financial-sector supervision for the first time.
For a financial entity, the oversight regime does not transfer your responsibility. Even where a provider is supervised at EU level, the obligation to manage that relationship, maintain the contractual terms and keep your exit strategy current remains with you and your management body.
Who Is Actually Accountable?
DORA places ultimate responsibility on the management body, the board and senior executives. They must define, approve and oversee the ICT risk management framework, allocate adequate budget and maintain sufficient knowledge to challenge ICT risk decisions. ICT risk cannot be quietly delegated to a vendor or buried two levels down in the IT function. This is deliberate. Regulators learned from the financial crisis that accountability has to sit where the authority sits. If you are on the board of a financial entity, DORA is now part of your personal duty of oversight.
Where Should You Start? A Practical Roadmap
We have walked regulated clients through this. A workable sequence looks like the following.
- Confirm scope and proportionality. Establish whether you are in scope, which entities in your group are caught, and whether any simplified regime applies. Document the determination.
- Map critical and important functions. You cannot protect, test or report on what you have not mapped. Identify the business functions, the ICT assets behind them and their dependencies.
- Build the register of information first. It is the single most revealing artefact and feeds the third-party, incident and testing pillars. Most institutions discover provider relationships they did not know they had.
- Run a gap analysis against the five pillars. Compare current controls to the regulation and the relevant RTS and ITS. Prioritise by risk, not by ease.
- Operationalise incident classification and reporting. Wire the classification criteria and reporting timelines into your SOC and incident-response runbooks so they fire automatically, not from memory.
- Remediate contracts and plan exits. Renegotiate ICT contracts to include the mandatory clauses and write credible exit strategies for critical-function providers.
- Stand up the testing programme. Establish the baseline testing cadence and, if you are a significant entity, plan TLPT engagements with intelligence-led scoping.
The common failure mode is treating DORA as a documentation exercise that produces policies nobody operates. The controls have to run continuously and leave evidence, because that is exactly what a competent authority will ask to inspect. Building on a strong foundation matters: the same disciplines that underpin a managed SOC and a hardened security operating model are the disciplines DORA codifies.
Professnet serves regulated financial clients and operates these controls in production, not just on paper. If you are working out where your organisation stands against DORA, or you want an honest gap assessment of your five-pillar readiness, see our case studies or contact us for a consultation. We will tell you what is genuinely in scope, what is proportionate for your risk profile and where the real exposure sits.