Regulation (EU) 2022/2554 of the European Parliament and of the Council on digital operational resilience for the financial sector (DORA) has applied since 17 January 2025. Smaller financial entities without their own security team usually ask two questions. Which documents does the regulation expect, and what exactly does the annual review of the ICT risk management framework mean? Below is an overview with references to the relevant articles, and a description of how to recognise a review that has really been done.
One note first. Whether an entity falls under DORA, and under which regime, is a legal question and this article does not answer it. The same applies to the wording of contracts with providers.
Documents that DORA expects
The regulation does not list documents for approval anywhere. The obligations are spread across individual articles, and from them it follows what an entity has to have described and evidenced. For a smaller entity, this is usually the list below.
| What the entity should have | Where DORA says so |
|---|---|
| ICT risk management framework including strategies, policies, procedures and tools | Art. 6(1) and (2) |
| Digital operational resilience strategy as part of the framework | Art. 6(8) |
| Inventory of information and ICT assets and their dependencies | Art. 8 |
| ICT business continuity policy and response and recovery plans | Art. 11(1) and (3) |
| Business impact analysis (BIA) | Art. 11(5) |
| ICT incident management process and records of incidents | Art. 17 |
| Register of information on contractual arrangements with ICT providers | Art. 28(3) |
| Digital operational resilience testing programme | Art. 24 and 25 |
The ICT risk management framework
Under Art. 6(1), the framework has to be sound, comprehensive and well documented, and it has to be part of the overall risk management system, not sit next to it. Under Art. 6(2) it consists of strategies, policies, procedures, ICT protocols and tools with which the entity protects its information and ICT assets, including physical components and premises.
The framework includes a digital operational resilience strategy (Art. 6(8)). The strategy has to explain how the framework supports the business strategy, set the risk tolerance level for ICT risk, describe information security objectives including indicators, the ICT reference architecture, the mechanisms for detecting incidents, resilience testing and the communication strategy in the event of an incident. For a smaller entity this does not mean dozens of pages, but a document that actually answers these points.
An entity other than a microenterprise has to assign responsibility for managing and overseeing ICT risk to a control function with an appropriate level of independence, separated from operational functions and from internal audit, in line with the three lines of defence model or another risk management and control model (Art. 6(4)). The regulation does not prescribe a specific organisational set-up, so in a small entity this may be a named role rather than a whole department.
Business continuity and recovery
DORA requires an ICT business continuity policy and the related response and recovery plans (Art. 11(1) and (3)). The policy may be a dedicated one, or it may form part of the overall business continuity policy. In entities other than microenterprises, the response and recovery plans are subject to independent internal audit reviews.
Paper alone is not enough. Under Art. 11(6)(a), continuity plans and response and recovery plans for ICT systems supporting all functions are tested at least yearly, and also upon any substantive change to systems supporting critical or important functions. An entity other than a microenterprise has to include in its testing plans scenarios of cyber-attacks and switchovers to redundant capacity, backups and redundant facilities. Records of activities before and during disruption events have to be kept readily accessible (Art. 11(8)).
Incidents
The ICT incident management process has to detect, manage and notify incidents (Art. 17(1)). The entity records all ICT-related incidents and significant cyber threats and has to ensure that root causes are identified, documented and addressed (Art. 17(2)). The process has to include early warning indicators, rules for categorising and classifying incidents according to the criteria in Art. 18(1), assigned roles, communication and escalation. At least major incidents are reported to senior management and to the management body, including the impact, the response and further controls (Art. 17(3)).
Major ICT-related incidents are reported to the relevant competent authority, which in the Czech Republic is the Czech National Bank (Art. 19(1)). Reporting has three stages: an initial notification, an intermediate report once the status of the incident changes significantly, and a final report once the root cause analysis is complete (Art. 19(4)). Under Art. 19(5), reporting may be outsourced to a third-party service provider, but the entity remains fully responsible for fulfilling the obligation.
The annual review of the ICT risk management framework
The key sentence is in Art. 6(5). The ICT risk management framework has to be documented and reviewed at least once a year, periodically in the case of microenterprises, and also upon the occurrence of major ICT-related incidents and following supervisory instructions or conclusions from resilience testing and audit processes. It has to be continuously improved on the basis of lessons derived from implementation and monitoring. A report on the review is submitted to the competent authority upon its request. An equivalent rule for entities under the simplified regime is in Art. 16(2).
It follows that the review is not a one-off check of document formatting. It is an evidenced cycle with inputs and outputs.
Inputs to the review
- Incidents and significant cyber threats over the period, taken from the entity's own records (Art. 17(2)), including the root causes identified.
- Results of continuity and response and recovery plan tests (Art. 11(6)) and results of resilience testing under Art. 24 and 25.
- Internal ICT audit findings and the state of their remediation. In entities other than microenterprises, critical findings have to be linked to a formal follow-up process with deadlines (Art. 6(6) and (7)).
- Changes in the asset inventory and in the register of ICT providers, especially for critical or important functions.
- Supervisory instructions and conclusions, where any have been received.
Outputs of the review
- A report on the review of the framework, with a date, a scope and the name of the person who prepared it. This is the document the supervisor may ask for.
- A list of changes to documents and controls, each with an owner and a deadline.
- A decision of the management body, which approves the framework and the resilience strategy (Art. 5(2)).
- A new version of the affected documents and a traceable history of earlier versions.
How to spot a review done only on paper
A few signs are usually visible straight away. The framework and policies have not changed in a year, even though the entity handled an incident or a recovery test failed. The register of ICT providers contains contracts that are no longer valid and omits services that have moved to another provider. Audit findings are written down without deadlines and without owners. A review report exists but refers to no specific input, neither incidents nor tests. And finally, the documents have never been approved by the management body.
Responsibility that cannot be handed over
Under Art. 5(2), the management body defines, approves and oversees the ICT risk management framework and is responsible for its implementation. It bears the ultimate responsibility for managing the entity's ICT risk, approves the digital operational resilience strategy including the risk tolerance level, approves and periodically reviews the ICT business continuity policy and the response and recovery plans, the ICT internal audit plans, the budget for digital operational resilience and the policy on the use of ICT services provided by third parties. Members of the management body have to keep their knowledge of ICT risk up to date, including regular training (Art. 5(4)).
Under Art. 6(10), verification of compliance with the ICT risk management requirements may be outsourced to an intra-group or external undertaking. The entity nevertheless remains fully responsible for that verification. The same rule applies to incident reporting (Art. 19(5)). An external team can therefore maintain the documentation, assess risks and prepare the review. The decisions and the responsibility stay with the entity.
The simplified framework under Article 16
For certain entities, among them small and non-interconnected investment firms, payment institutions exempted under the payment services directive, exempted electronic money institutions and small institutions for occupational retirement provision, Articles 5 to 15 do not apply. Instead, the simplified ICT risk management framework under Art. 16 applies. It also has to be documented and has to cover the mechanisms for managing ICT risk, continuous monitoring of systems, identification of key dependencies on ICT providers, continuity of critical or important functions including backup and restoration, regular testing of those plans and the incorporation of conclusions from tests and from post-incident analyses. The review is carried out periodically and upon major incidents (Art. 16(2)).
Belonging to this group is a legal assessment that depends on the type of licence. Do not assume it from headcount and have it confirmed by a legal adviser or by the supervisor.
Where to start without an in-house security team
The order that works in practice follows what everything else builds on.
- List the ICT assets and their dependencies, including what runs at providers (Art. 8).
- Complete the register of information on contractual arrangements with ICT providers and mark the services that support critical or important functions (Art. 28(3)).
- Describe the incident management process and rehearse escalation, that is, who decides on the classification and who submits the report to the supervisor and when (Art. 17 and 19).
- Test recovery at least for the systems the business depends on and write the result down (Art. 11(6)).
- Only then write the framework and the resilience strategy to match what really happens in the entity, and set the date of the annual review straight away.
We keep assets, risks, controls, providers and regulatory obligations in one place in our own application Observa. Support for DORA, NIS2 and the Czech cybersecurity act is part of all plans. If you want to compare the list above with your current state first, contact us through our contact page. The initial consultation is free of charge.
Sources: Regulation (EU) 2022/2554 (DORA), text of Articles 5, 6, 8, 11, 16, 17, 19, 24, 25 and 28