Patroklos PatroklouLast updated: 18 October 2026
Quick answer: The DORA ICT risk management framework is the documented set of strategies, policies, procedures, protocols and tools that EU financial entities must maintain under Articles 5 to 16 of Regulation (EU) 2022/2554. It must be owned by the management body, reviewed at least once a year, independently audited, and cover identification, protection, detection, response, recovery, learning and communication.
The Digital Operational Resilience Act (DORA) has applied since 17 January 2025, and supervisors have now moved from asking whether a DORA ICT risk management framework exists to testing whether it works. For a CISO, that means the framework has to hold up as evidence: who approved it, when it was last reviewed, which audit findings are still open, and how it connects to incidents and third-party risk.
This guide covers what Chapter II of DORA requires, how the technical standards add detail, and a checklist to test your framework.
What is the DORA ICT risk management framework?
It is the core structure every in-scope financial entity must build and maintain to manage ICT risk. Article 6(1) requires a “sound, comprehensive and well-documented” framework, as part of the overall risk management system, that lets the entity address ICT risk quickly, efficiently and comprehensively.
The framework is not a single policy. According to the official text of DORA on EUR-Lex, it includes at least the strategies, policies, procedures, ICT protocols and tools needed to protect all information and ICT assets, including software, hardware and servers, as well as physical components and infrastructure such as premises and data centres.
DORA applies to around 20 types of financial entity, from credit institutions and investment firms to insurers, crypto-asset service providers and ICT-dependent payment institutions, as summarised on EIOPA’s DORA page. Proportionality applies throughout, so size and risk profile shape the level of detail.
If you want a broader overview of the regulation first, see our guide to mastering DORA compliance in 2026.
Which DORA articles make up the framework?
Chapter II of DORA, Articles 5 to 16, sets out the framework. Article 5 covers governance, Article 6 the framework itself, Articles 7 to 14 the functional requirements, Article 15 the technical standards mandate and Article 16 the simplified regime.
| Article | Topic | What supervisors will look for |
|---|---|---|
| 5 | Governance and organisation | Management body approval, defined roles, budget, training records |
| 6 | ICT risk management framework | Documented framework, annual review, independent control function, internal audit, resilience strategy |
| 7 | ICT systems, protocols and tools | Systems that are reliable, have sufficient capacity and are technologically resilient |
| 8 | Identification | Inventories of functions, assets and dependencies, reviewed at least yearly |
| 9 | Protection and prevention | Security policies, access control, encryption, change and patch management |
| 10 | Detection | Mechanisms to detect anomalous activity promptly, with alert thresholds |
| 11 | Response and recovery | Business continuity policy, BIA, plans tested at least yearly, crisis management |
| 12 | Backup, restoration and recovery | Backup policies, restoration procedures, tested recovery methods |
| 13 | Learning and evolving | Post-incident reviews, staff training, yearly reporting to the management body |
| 14 | Communication | Crisis communication plans for staff, clients, counterparties and the public |
| 16 | Simplified framework | Proportionate framework for eligible smaller entities |
Who is accountable for ICT risk under DORA?
The management body is. Article 5(2) states that the management body must define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework, and it bears ultimate responsibility for managing ICT risk.
In practice, Article 5 expects the board to:
- set and approve the digital operational resilience strategy, including the appropriate risk tolerance level for ICT risk;
- approve, oversee and periodically review the ICT business continuity policy and response and recovery plans;
- approve and periodically review ICT internal audit plans and material changes to them;
- allocate budget for digital operational resilience, including security awareness programmes and training;
- approve and review the policy on the use of ICT services provided by third parties.
Article 5(4) also requires management body members to keep their ICT risk knowledge up to date through regular, specific training.
Common mistake: Treating board approval as a one-off signature on the framework document. Supervisors look for a trail of ongoing oversight, such as minutes showing the board discussed ICT risk tolerance, audit findings and major incidents during the year.
What does Article 6 require in practice?
Article 6 sets five structural requirements: an independent control function, an annual review, internal audit, a formal follow-up process for findings, and a digital operational resilience strategy.
An independent control function
Entities other than microenterprises must assign responsibility for managing and overseeing ICT risk to a control function with an appropriate level of independence, and ensure segregation between ICT management, control and internal audit functions, in line with the three lines of defence model or an equivalent internal risk management and control model (Article 6(4)).
Review at least once a year
The framework must be documented and reviewed at least once a year (periodically for microenterprises), and also after major ICT-related incidents, following supervisory instructions or conclusions drawn from resilience testing or audits (Article 6(5)). Keep a written review report for your competent authority.
Internal audit and follow-up
Non-microenterprises must have the framework audited on a regular basis by ICT auditors with sufficient knowledge, skills and expertise in ICT risk (Article 6(6)). Article 6(7) adds a formal follow-up process, with rules for the timely verification and remediation of critical ICT audit findings.
A digital operational resilience strategy
Article 6(8) requires a strategy setting out how the framework supports the business strategy and objectives. It should cover the ICT risk tolerance level, information security objectives with key performance indicators, the reference ICT architecture, detection and protection mechanisms, the resilience testing approach and the communication strategy for ICT incidents.
In practice: Many banks already have an information security strategy. The quickest route is to extend it with an explicit risk tolerance statement, measurable KPIs and a section linking it to DORA testing and incident communication, rather than writing a new document from scratch.
How do the RTS on ICT risk management add detail?
Commission Delegated Regulation (EU) 2024/1774 turns DORA’s high-level principles into specific policy and control requirements. It was adopted on 13 March 2024 and specifies the tools, methods, processes and policies for ICT risk management, plus the content of the simplified framework.
According to the RTS on the ICT risk management framework, the areas covered include:
- ICT security policies, procedures, protocols and tools;
- ICT asset management, including an inventory and lifecycle management;
- encryption and cryptographic key management;
- ICT operations security, network security and access control;
- ICT-related incident detection and response, and ICT business continuity management;
- the format and content of the report on the review of the ICT risk management framework;
- a separate, lighter title for entities under the simplified regime.
How often must you test, review and report?
DORA builds in several recurring cycles. Putting them in one calendar is the simplest way to avoid gaps.
| Activity | Minimum frequency | DORA reference |
|---|---|---|
| Review the ICT risk management framework | At least yearly, and after major incidents | Art. 6(5) |
| Review inventories of ICT-supported functions and assets | At least yearly | Art. 8(1) |
| Review risk scenarios | Regularly, at least yearly | Art. 8(2) |
| Assess legacy ICT systems | Regularly, at least yearly | Art. 8(7) |
| Risk assessment after major changes | Upon each major change | Art. 8(3) |
| Test ICT business continuity and response and recovery plans | At least yearly | Art. 11(6) |
| Senior ICT staff report to the management body on lessons learned | At least yearly | Art. 13(5) |
Keeping these cycles, owners and evidence in one place is where tooling earns its keep. Enactia’s AI-powered GRC platform maps DORA requirements against ISO 27001, NIS2 and other frameworks you already hold, so one control can evidence several obligations. If you want to see how that looks for your own framework, start your 14-day free trial.
How does the framework connect to incidents and third parties?
The framework is the foundation for the rest of DORA. Incident management (Chapter III), resilience testing (Chapter IV) and ICT third-party risk (Chapter V) all rely on the asset inventories, risk assessments and governance you set up under Chapter II.
The link is visible in real data. In June 2026 the ESAs published their first report on DORA major ICT-related incidents, covering 3,383 major incidents reported during 2025. About a third had a cross-border impact, only around 10% were cybersecurity-related, and system failures and external events were the main causes. The ESAs stressed the need for robust third-party risk management and effective oversight of outsourced services.
That has two lessons for your framework. First, availability and change management failures matter as much as attacks. Second, your Article 8 dependency mapping must reach into your ICT third-party providers, which is also the basis for your DORA register of information.
Useful building blocks include a structured enterprise risk management module for ICT risk scenarios, a vendor and third-party risk management process, and incident and data breach management workflows that feed post-incident reviews back into the framework.
DORA ICT risk management framework checklist
Use this checklist to test your framework against the regulation. Each item should have a named owner and evidence you can produce on request.
- Governance: Management body approval of the framework, strategy and risk tolerance, with minutes from the past 12 months.
- Training: Records of ICT risk training for management body members and all staff.
- Control function: Documented independent ICT risk control function and segregation from ICT operations and internal audit.
- Documented framework: Policies covering the RTS areas, version-controlled in a policy management system.
- Annual review: Written review report from the last cycle, including changes made after major incidents or audits.
- Internal audit: ICT audit plan, recent audit report and a tracker of critical findings with remediation dates.
- Identification: Current inventories of ICT-supported business functions, information assets, ICT assets and third-party dependencies.
- Protection: Access control, encryption, patch and change management policies with evidence of operation.
- Detection: Monitoring and alerting thresholds defined for anomalous activity.
- Continuity: Business impact analysis, continuity and recovery plans, and evidence of yearly tests including a cyber-attack scenario.
- Backup and recovery: Backup policy and results of restoration tests.
- Learning: Post-incident reviews and the yearly lessons-learned report to the management body.
- Communication: Crisis communication plan covering staff, clients, counterparties and the media.
Key takeaways
- The DORA ICT risk management framework spans Articles 5 to 16 and has applied since 17 January 2025.
- The management body owns ICT risk and must approve, oversee and be trained on the framework.
- Review the framework at least yearly and after major incidents, and have it independently audited.
- Delegated Regulation (EU) 2024/1774 sets the detailed policy and control requirements, including a simplified regime.
- Evidence matters most: keep minutes, review reports, test results and audit trackers ready for supervisors.
Frequently asked questions
What is the DORA ICT risk management framework?
It is the set of strategies, policies, procedures, protocols and tools that a financial entity uses to protect its information and ICT assets and manage ICT risk under Articles 5 to 16 of DORA. It must be well documented, approved by the management body, reviewed at least yearly and audited regularly by qualified ICT auditors.
How often must the DORA ICT risk management framework be reviewed?
Article 6(5) requires a review at least once a year, or periodically for microenterprises. A review is also required after major ICT-related incidents, following supervisory instructions, and when resilience testing or audit processes produce relevant conclusions. Keep a written report of each review, as your competent authority can ask for it.
Does ISO 27001 certification satisfy DORA?
Not on its own. An ISO/IEC 27001 information security management system covers many of the same controls, so it is a strong starting point. However, DORA adds specific requirements such as management body accountability for ICT risk tolerance, yearly continuity testing with cyber-attack scenarios, legacy system assessments and a formal framework review report.
Who can use the simplified ICT risk management framework?
Article 16 lists the eligible entities, including small and non-interconnected investment firms, exempted payment and electronic money institutions, certain institutions exempted under the Capital Requirements Directive and small occupational retirement institutions. They still need a documented framework, incident handling, continuity arrangements, testing and periodic review, just in a lighter form.
Can we outsource ICT risk management under DORA?
You can use external providers for tasks such as auditing or compliance verification, but Article 6(10) keeps full responsibility for verifying compliance with the entity. The management body remains accountable for the framework, and any ICT services supporting it fall under DORA’s third-party risk rules.
Turning the framework into evidence
A DORA ICT risk management framework succeeds or fails on evidence. Map articles to owners, run the recurring cycles on a calendar and keep the management body visibly involved. Start with the checklist above, close the gaps you find, and your next supervisory review becomes a walkthrough rather than a scramble.
Enactia’s DORA compliance tools help you do this alongside the other frameworks you already manage. To discuss your programme, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
