Who This Article Is For
You work in or around a financial institution. You have read what DORA is and why it matters. Now you need to know what to actually do. This article gives you a practical, sequenced starting point — not an exhaustive compliance programme, but an honest guide to where to begin and what to prioritise.
Before Anything Else: Confirm You Are in Scope
The first step is one many teams skip. DORA applies to approximately 22,000 regulated financial entities across the EU — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more. It also applies to ICT third-party providers that serve them.
If your organisation operates within the EU financial sector or provides technology services to entities that do, you are almost certainly in scope. If you are outside the EU but serve EU financial clients in a critical capacity, DORA reaches you through the contract obligations your clients must impose on you.
Confirm your scope formally. The consequence of incorrectly concluding you are out of scope is not a minor administrative issue — it is a gap in your entire operational resilience posture.
Step 1 — Run a Gap Analysis
You cannot build a compliance programme without knowing where you currently stand. A gap analysis maps your existing capabilities against DORA's five pillars and tells you, concretely, what is missing.
For ICT risk management, ask whether you have a documented framework that identifies, classifies, and controls ICT risks across all your systems — not just the obvious ones. Do you have a complete inventory of your ICT assets, including systems hosted by third parties? Is the management body formally accountable for it?
For incident reporting, ask whether you have a documented process for classifying ICT incidents against DORA's severity thresholds. Do you know the reporting timelines required by your national competent authority?
For resilience testing, ask what testing you currently do, how often, and whether results are documented and acted upon. For organisations at significant scale, ask whether you have a threat-led penetration testing programme in place.
For third-party risk management, ask how many ICT providers you have, which support critical or important functions, and whether your contracts include audit rights, incident notification obligations, business continuity requirements, and exit arrangements. For most organisations this is where the largest gap will be found.
For information sharing, ask whether you participate in any EU threat intelligence sharing arrangement. Document the gaps. Assign a severity to each. This becomes your roadmap.
Step 2 — Start With the Register of Information
If you do one thing first, make it this. DORA requires every financial entity to maintain a comprehensive Register of Information — a structured inventory of all contractual arrangements with ICT third-party service providers. This register operates at entity level, sub-consolidated level, and consolidated level where applicable. Competent authorities submitted these registers to the ESAs by April 2025 for use in designating critical third-party providers.
The register is not optional and it is not simple. It needs to capture every ICT provider and the services they deliver, which business functions those services support, whether those functions are critical or important, the data classifications involved, the geographic locations of data processing, and the recovery objectives for each service.
Starting with the register forces you to map your third-party landscape comprehensively — the foundation for everything else in the third-party pillar. And it is what regulators look at first. An incomplete or inaccurate register signals immediately that your third-party governance is not functional.
Step 3 — Fix the Contracts
Once you have your Register of Information, you will know which providers support critical or important functions. Every contract with those providers needs to be reviewed against DORA's requirements under Article 30.
At minimum, contracts must include service level agreements with clear availability and performance standards, audit rights allowing the financial entity and its regulators to inspect the provider, incident notification obligations requiring the provider to alert you within defined timelines, business continuity and resilience requirements, subcontracting disclosure requirements so you know who your provider relies on, and exit arrangements including a transition period to move to an alternative provider.
Be prepared for pushback. Some providers will resist renegotiation. Some will refuse entirely. Where a provider of a critical function refuses to accept DORA-compliant contract terms, that is a risk that needs to be escalated to senior management and assessed against your risk appetite. In some cases the answer will be to exit the relationship.
A provider's statement that they are "working towards" DORA compliance is not a compliant contract. Until the terms are in the contract, the risk is yours.
Step 4 — Build the Incident Reporting Process
DORA requires major ICT-related incidents to be reported to your national competent authority in a structured, timely sequence. The initial notification is required quickly — often within hours of determining that an incident meets the threshold for major classification. This is followed by an intermediate report and then a final root cause report.
To make this work under pressure, you need to build the process before an incident occurs. That means a clear internal classification matrix so staff can determine quickly whether an incident meets the reporting threshold, named owners in each relevant jurisdiction responsible for regulatory notification, pre-drafted report templates aligned to the regulatory technical standards published by the ESAs, and a tested escalation path from technical teams to legal and compliance.
Simulate a significant ICT incident and walk through the classification, escalation, and notification process with the people who would actually be involved. In almost every organisation that does this for the first time, it reveals that nobody knows who is responsible for notifying the regulator. Find that out in a tabletop, not during an actual incident.
Step 5 — Establish the Testing Programme
DORA requires regular testing of digital operational resilience. A baseline programme should include annual vulnerability assessments across critical systems, scenario-based resilience testing that simulates realistic disruption events, and — for organisations at significant scale or with systemic importance — threat-led penetration testing (TLPT) carried out by independent qualified testers.
Testing results are not just for internal use. Regulators expect to see them. More importantly, they expect to see evidence that identified weaknesses were addressed. A clean test result is less credible than a test result that found issues and documented how they were remediated.
DORA requires organisations to implement an immutable backup of data that is physically and logically segregated from primary and secondary systems, and to recover that data within two hours of an incident. That recovery capability must be manually tested at least once per year. Many organisations discover during that test that the two-hour window is not achievable with their current infrastructure. Test it before a regulator asks you to prove it.
Step 6 — Get the Board Involved
This is not a step that can be delegated away. DORA places ICT risk governance directly on the management body. Board members are expected to maintain current knowledge of cyber threats. Senior managers face individual accountability for failures in this area.
In practical terms this means the board needs a standing agenda item for ICT risk, not just an annual briefing. It means the CISO or equivalent needs a direct line to the board, not a filtered report through three layers of management. And it means at least some members of the management body should be completing formal training on cyber risk and operational resilience.
If your board currently treats ICT risk as a technical matter for the IT department, that needs to change. The regulation assumes board-level ownership. Supervisors will look for evidence of it.
Step 7 — Join an Information Sharing Arrangement
This is the most underutilised pillar of DORA and also the easiest to address. The EU has established structured frameworks for financial entities to share intelligence on cyber threats and vulnerabilities with each other, securely and in compliance with confidentiality and competition law obligations. Joining one of these arrangements does not require significant resource — what it requires is a decision to participate and a process for both contributing intelligence and acting on what you receive.
Where to Focus If You Are Just Starting
Start with visibility — complete the Register of Information so you know your full ICT landscape. Then address the highest-risk contracts — the providers supporting critical functions whose agreements are not DORA-compliant. Then build the incident reporting process, because that is the capability you may need to use before everything else is fully mature. Then work through the testing programme and governance requirements.
None of this is a one-time project. DORA requires the ICT risk management framework to be reviewed at least annually. The institutions building these capabilities as ongoing operational practice — rather than compliance projects with an end date — are the ones that will be in the strongest position when enforcement intensifies.
A Final Word
DORA is demanding. It asks financial institutions to prove resilience rather than simply assert it. It asks boards to own risk they previously delegated. It asks compliance and technology teams to work together in ways that have historically been difficult.
But the underlying goal is straightforward: keep the financial system running, protect the people who depend on it, and hold institutions accountable for the technology risks they take on. The practical question is not whether to comply, but how to build compliance that is genuine rather than performative — because in the long run, only one of those will hold up under scrutiny.
This concludes the three-part DORA series.
Sources: Regulation (EU) 2022/2554 · EIOPA · EBA · ESMA Official Publications · ESA Supervisory Guidance 2025