Where do you start a first DORA implementation? A first DORA implementation starts from understanding which functions are critical and which ICT providers support them – not from writing policies. Without this map you can neither build the register of information, nor set recovery objectives, nor plan tests. This list distils implementation into five starting actions and five mistakes that most often cost time.
Canonical definition: DORA (Digital Operational Resilience Act) is EU Regulation 2022/2554 imposing on financial entities and their ICT providers uniform digital operational resilience requirements across five pillars, directly applicable since 17 Jan 2025.
This article is for an organisation meeting DORA for the first time: it orders the sequence of actions and points out the traps easiest to fall into when the regime is new.
DORA – 5 dos and 5 don’ts – key takeaways:
- DORA has applied directly since 17 Jan 2025 and covers five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management and information sharing.
- The implementation starting point is inventorying critical functions and their supporting ICT assets – the rest of the obligations follow from it.
- The register of information on ICT providers is the foundation of the fourth pillar and one of the first elements the supervisor expects.
- Resilience testing, including TLPT for significant entities, is a technical layer no document can replace.
- The most common mistake is treating DORA as a purely legal project and skipping the genuine technical capability.
- Patronusec, an accredited QSA with a penetration testing team, supports DORA implementation with particular emphasis on the technical layer.
Table of Contents
Why does implementation start from critical functions, not policies?
DORA implementation starts from critical functions, because they define the scope of all other obligations: which ICT assets to protect, what recovery objectives to set, what to test and which provider contracts matter most. A policy written without this map describes an organisation you do not understand.
A critical function is an activity whose disruption would have a serious impact on the entity’s ability to deliver services or on stability. DORA builds almost all its requirements around protecting and recovering precisely these functions. Before you define the ICT risk framework (first pillar), you must know what is critical and which assets support it.
The right order is therefore the reverse of the intuitive one. Instead of “let’s write the policies DORA requires”, the right approach is: “let’s establish critical functions and their ICT dependencies, then build the framework, register, tests and reporting around them”. Policies matter, but they are a consequence of the map, not a substitute for it.
A DORA policy written before mapping critical functions describes wishes, not an organisation – and an audit checks whether the risk framework matches genuine dependencies, not whether the document sounds correct.
Top 5 things to do first
The five tasks below set the right order for starting a DORA implementation. The common denominator: first understand what you protect and whom you depend on, and only then build documents and capabilities.
Inventory critical functions and their supporting ICT assets. This is the foundation. Establish which functions are critical and which systems, data and services support them. This map determines the scope of the risk framework, tests and recovery objectives.
Build the register of information on ICT providers. List all ICT provider contracts, including subcontractor dependencies. The register is a fourth-pillar requirement and one of the first elements the supervisor expects – and building it reveals dependencies an organisation often does not know about.
Anchor an ICT risk-management framework with board involvement. DORA requires the management body to be genuinely involved in the ICT risk framework. Appoint an owner and establish a process of identification, protection, detection and recovery around the critical functions.
Establish an incident classification and reporting process. Build the capability to detect, classify and report major ICT incidents within DORA’s hard deadlines. This is a mixed layer: procedure plus a genuine detection capability.
Plan a resilience testing programme. Establish regular tests, and if you are a significant entity – prepare for advanced threat-led penetration testing (TLPT). This is a technical layer requiring penetration testing competence and tooling.
Top 5 things to avoid
The five mistakes below most often delay or undermine a first DORA implementation. The common denominator: confusing a document with a genuine capability and treating DORA as a one-off legal project.
❌ Treating DORA as a purely legal project. A law firm will produce clauses and the register, but resilience testing and TLPT are technical work. A document stating that “we test” is not a test – the most common gap the supervisor exposes.
❌ Assuming “we are not a bank, so it does not concern us”. An ICT provider and its subcontractor feel DORA through contracts. Ignoring this mechanism leaves the organisation unprepared when a financial-sector customer passes the requirements down the chain.
❌ Building the register of information at the last minute. The register is submitted annually, and building it properly reveals subcontractor dependencies nobody knew about. Left to the end, it blocks timely submission and exposes gaps in provider management.
❌ Setting recovery objectives out of thin air. RTOs and RPOs declared without grounding in a business impact analysis and without a test are numbers that sound safe but fail on incident day. A recovery objective not backed by a genuine capability is a fiction.
❌ Treating DORA as a one-off project. DORA is a continuous obligation: an annual register, regular tests, updating the risk framework. An organisation that “implements and forgets” loses compliance between cycles – and the supervisor enforces it continuously.
Patronusec Insight: In our project experience, organisations implementing DORA for the first time most often overestimate the documentation layer and underestimate the technical one. Policies and clauses are produced quickly, because they are measurable and familiar; resilience testing is deferred “for later”, because it needs competence the firm lacks. Yet it is the third pillar – testing, including TLPT – where an audit most easily exposes the difference between declaration and capability. We recommend planning the technical layer from the outset, in parallel with the legal one, not as a final stage.
How to combine these actions into a coherent implementation plan?
A coherent DORA implementation plan combines the five starting actions into a logical sequence: from the critical-function map, through the register and risk framework, to reporting and testing, then into a maintenance cycle. The order follows from dependencies – each element builds on the previous one.
The recommended sequence:
- Map and scope. Critical functions, supporting ICT assets, establishing your role in the chain (financial entity, provider, subcontractor).
- Register and providers. The register of information, reviewing and completing contracts, identifying subcontractor dependencies.
- Framework and governance. An ICT risk-management framework with board involvement, based on the critical-function map.
- Incidents and tests. A classification and reporting process and a resilience testing programme, including preparing for TLPT for significant entities.
- Maintenance. An annual register, regular tests, updating the framework – DORA as a continuous process, not a project.
Running the legal and technical layers in parallel is key. The register, contracts and policies (legal layer) can be built alongside the detection and testing capability (technical layer) – provided the right competencies are planned for each from the outset. A plan that first closes the documents and leaves the technical layer to the end risks exposing the gap just before the audit.
Patronusec supports organisations in building such a plan within its DORA service – with particular emphasis on resilience testing and TLPT, where as a QSA with a penetration testing team we combine the competencies of auditor and tester.
FAQ – How to implement DORA
Where exactly do I start a DORA implementation?
From inventorying critical functions and their supporting ICT assets. This is the foundation from which the scope of the risk framework, recovery objectives, tests and provider-management priorities follows. Starting from writing policies without this map leads to documents describing an organisation you do not understand – and gaps an audit exposes.
What is the register of information and why is it a priority?
The register of information is a schedule of all ICT provider contracts, including subcontractor dependencies, submitted annually to the supervisor. It is a priority because it is one of the first elements the supervisor expects, and building it properly reveals technology dependencies an organisation often does not know about.
Must every entity perform TLPT?
No. DORA provides advanced threat-led penetration testing (TLPT) for significant entities, identified by criteria by the supervisors. Other entities run regular resilience tests of lesser depth. Regardless of TLPT, resilience testing as such is a third-pillar requirement for all in scope.
Why isn’t treating DORA as a legal project enough?
Because DORA combines a legal layer (policies, clauses, register) with a technical one (testing, monitoring, recovery). A law firm will produce the legal layer, but resilience testing and a genuine recovery capability are technical work no document can replace. Treating DORA as a purely legal project leaves a gap the supervisor exposes.
How do I set realistic recovery objectives (RTO/RPO)?
Recovery objectives are derived from a business impact analysis (BIA) and then verified by a test. RTOs and RPOs declared without this grounding are numbers that sound safe but fail on incident day. A realistic objective is one the organisation actually achieves in a recovery exercise, not merely declares in a document.
How does Patronusec support a first DORA implementation?
We guide the full sequence: from the critical-function map and provider register, through the risk framework and incident process, to resilience testing and TLPT. As a QSA with a penetration testing team, we especially reinforce the technical layer organisations most often underestimate. After a free scope-assessment call we present an implementation plan and a quote.
Recommended reading
A reading path for DORA implementation:
- DORA for beginners – what it changes, who it covers and how to start – the foundation: a full introduction to the regime.
- A business continuity plan in 5 steps – the recovery capability required in the first pillar.
- What a business continuity (BCM) test report should contain – how to document resilience tests.
- NIS2 – 5 things to do and 5 to avoid – a related regime for entities outside the financial sector.
DORA – free consultation
Patronusec, an accredited QSA with a penetration testing team, supports DORA implementation, combining the legal and technical layers. Book a free consultation to order the sequence of actions and avoid the typical mistakes of a first implementation.
