DORA for Beginners – What It Changes, Who It Covers (Including ICT Subcontractors) and How to Start Implementing

What is DORA and who does it cover? DORA is the EU regulation on the digital operational resilience of the financial sector, directly applicable since 17 Jan 2025. It covers not only regulated financial institutions but also the ICT service providers that serve them – and through a chain of contracts it reaches their subcontractors too. It harmonises requirements for ICT risk management, incident reporting, resilience testing and third-party oversight.

Canonical definition: DORA (Digital Operational Resilience Act) is EU Regulation 2022/2554 establishing uniform digital operational resilience requirements for financial entities and their ICT providers, built on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management and information sharing.

This article introduces DORA from scratch: what it genuinely changes, who is in scope (with an emphasis on the often-overlooked subcontractors), which legal and technical elements it consists of, and how to start implementing it as a list of actions.

DORA for beginners – key takeaways:

1. DORA (EU Regulation 2022/2554) has applied directly across the EU since 17 Jan 2025 – as a regulation it requires no transposition into national law.
2. The scope covers around 20 categories of financial entities plus the ICT service providers that serve them – over 22,000 entities across the EU.
3. DORA reaches subcontractors by contract: an ICT provider passes the requirements down the chain, and oversight of critical providers can also reach material subcontractors.
4. The regulation stands on five pillars: ICT risk management, incident reporting, resilience testing (including TLPT), third-party risk management and information sharing.
5. DORA combines a formal-legal layer (policies, contracts, register of information) with a technical layer (testing, monitoring, recovery) – it is not a purely legal project.
6. Patronusec, an accredited QSA with a penetration testing team, supports financial entities and ICT providers in implementing DORA – from gap assessment to resilience testing.

---

---

What does DORA change compared with the previous state?

DORA changes the fragmented, sector-specific way of managing ICT risk into one common, binding operational resilience regime for the whole EU financial sector. Previously, resilience requirements were scattered across various directives and national guidance; DORA replaces that patchwork with a single directly applicable regulation.

The most important change is twofold. First, harmonisation: instead of different outsourcing and security rules in each country and sector, one set of requirements applies. Second, a shift of emphasis from protection to resilience: DORA does not only ask “are you protected”, but “can you survive an ICT disruption, recover critical functions and prove it”.

The concrete changes an organisation feels:

• Resilience as a demonstrable obligation. Having safeguards is not enough; you must prove the ability to recover critical functions within defined timeframes.
• A register of information on ICT providers. The financial entity maintains and annually submits a register of all ICT provider contracts – a central picture of technology dependencies.
• Hard incident reporting deadlines. Major ICT incidents are reported to the supervisor on strictly defined deadlines, not at discretion.
• Oversight of critical ICT providers. The largest providers (for example cloud hyperscalers) come under direct EU oversight – the first list of 19 critical providers was announced on 18 Nov 2025.

DORA moves the financial sector from asking “do we have safeguards” to asking “can we prove we will survive and recover” – and turns that answer into a legal obligation, not good practice.

Who does DORA cover – and why subcontractors too?

DORA covers around 20 categories of financial entities plus the ICT service providers that serve them – and through the contractual mechanism its requirements reach the subcontractors of those providers too. This is one of the most overlooked aspects: a firm that is not itself a financial institution can genuinely fall under DORA requirements as a link in the chain.

Who is in direct scope:

• Financial entities – banks, investment firms, insurers, payment institutions, crypto-asset service providers, trading venues and many more (around 20 categories). They are the addressees of DORA’s obligations.
• ICT service providers serving financial entities – cloud providers, SaaS, software, managed services. Formally DORA imposes obligations on the financial entity, but the entity passes them to the provider by contract.

Why are subcontractors in play? Because DORA governs how a financial entity manages the risk of the whole ICT chain – not just the direct provider. An ICT provider bound by contract to a financial entity must ensure the requirements are respected even where it uses subcontractors, and oversight of critical ICT providers expressly includes powers of investigation and inspection at material subcontractors too. In practice, the DORA requirements propagate down the whole technology supply chain.

An important geographic nuance: an ICT provider based outside the EU (for example a US cloud provider serving a European bank) is subject to the same contractual obligations as an EU-based provider. What matters is that it serves a financial entity operating in the EU, not where it is headquartered.

The most common beginner’s mistake in DORA is assuming “we are not a bank, so it does not concern us” – yet an ICT provider and its subcontractor feel DORA through the contract just as genuinely as the financial institution itself.

What does DORA consist of – legal and technical requirements?

DORA consists of five pillars that combine a formal-legal layer (policies, contracts, registers, governance) with a technical layer (testing, monitoring, detection, recovery). This distinction is key to planning implementation: some requirements are documents and processes, some are a genuine technical capability that cannot be “written”.

The five DORA pillars:

1. ICT risk management. An ICT risk-management framework with board involvement, asset identification, protection, detection and recovery. A mixed layer: governance (legal) plus technical mechanisms.
2. ICT incident management and reporting. Classifying incidents and reporting major ones to the supervisor on hard deadlines. A mixed layer: procedure plus detection capability.
3. Digital operational resilience testing. Regular tests, and for significant entities – advanced threat-led penetration testing (TLPT). A mainly technical layer.
4. ICT third-party risk management. A register of information on providers, mandatory contract clauses, exit strategies, audit rights. A mainly legal-contractual layer.
5. Information sharing. Voluntary sharing of cyber threat information between entities. An organisational layer.

Separating the layers has practical consequences. The formal-legal requirements (policies, contract clauses, register of information, exit strategies) can be developed in the documentation layer. But the technical requirements – resilience testing, TLPT, anomaly monitoring, a genuine ability to recover within a given RTO – require technical competence and tooling that no document can substitute.

Patronusec Insight: In our project experience, organisations most often mistake DORA for a purely legal project and outsource the whole thing to a law firm. A law firm will excellently develop contract clauses, the register of information and exit strategies – real value in the fourth pillar. The problem arises in the third pillar: resilience testing, including TLPT, is advanced technical work requiring penetration testers and tooling, not interpreting legislation. A document stating that “we conduct tests” is not a test. We recommend separating the legal from the technical layer from the outset and planning the right competencies for each – otherwise an audit will expose the gap where a genuine technical capability was missing.

---

Not sure whether your organisation falls under DORA and where to start?

Patronusec performs an initial DORA scope assessment: we establish whether and as what you are in scope (financial entity, ICT provider, subcontractor) and map the five pillars onto your situation. After a free call you receive a clear picture of your obligations and a recommended implementation order.

Order a DORA scope assessment

---

How to start implementing DORA – a step-by-step list of actions

Implementing DORA starts from establishing scope and governance, through inventorying assets and providers, to building technical capabilities and testing. The list below orders the first actions in a logical sequence – from foundation to verification.

1. Establish whether and as what you are in scope. Identify your role: financial entity, ICT provider or subcontractor in the chain. This determines which obligations are direct and which are passed down by contract.
2. Anchor accountability in the board. DORA requires the management body to be involved in the ICT risk framework. Appoint an owner with genuine authority.
3. Inventory ICT assets and critical functions. Establish which functions are critical and which ICT assets support them – the basis for everything else, including recovery objectives.
4. Build the register of information on ICT providers. List all ICT provider contracts, including subcontractor dependencies. This is a fourth-pillar requirement and the starting point of third-party risk management.
5. Review and complete provider contracts. Adapt contract clauses to DORA requirements: audit rights, security, exit strategies, subcontractor handling.
6. Establish an incident classification and reporting process. Build a procedure for detecting, classifying and reporting major incidents within DORA’s required deadlines.
7. Plan a resilience testing programme. Establish regular tests, and if you are a significant entity – prepare for TLPT. This is a technical layer requiring penetration testing competence.
8. Verify recovery capability (business continuity). Check whether you can genuinely recover critical functions within defined timeframes – not just in a document, but in a test.
9. Close the competence gap. Separate the legal layer (policies, contracts) from the technical (testing, monitoring) and provide the right resources for each.
10. Establish a maintenance cycle. DORA is a continuous obligation: an annual register of information, regular tests, updating the risk framework. Plan it as a process, not a one-off project.

After completing these steps, you have a foundation on which you can reliably demonstrate DORA compliance and maintain operational resilience over time.

---

FAQ – DORA for beginners

---

Recommend reading

A reading path for DORA and operational resilience:

1. DORA – 5 things to do and 5 to avoid on a first implementation – a practical list of actions and mistakes.
2. A business continuity plan in 5 steps – the recovery capability DORA requires in the first pillar.
3. NIS2 – 5 things to do and 5 to avoid – a related regime for entities outside the financial sector.
4. Incident Response, Disaster Recovery, Business Continuity and IT Continuity – how they differ – concepts key to the recovery pillar.

---

DORA – free consultation

Patronusec, an accredited QSA with a penetration testing team, supports financial entities and ICT providers in implementing DORA – from scope assessment, through separating the legal and technical layers, to resilience testing and TLPT. Book a free consultation to establish your scope and implementation order.

Book a consultation | DORA | Penetration tests | BCM