DORA ICT Risk Management Framework Explained

DORA ICT risk management is the most extensive obligation imposed by the Digital Operational Resilience Act on financial entities in the European Union. Articles 5 through 16 of Regulation (EU) 2022/2554 establish a prescriptive framework for identifying, protecting against, detecting, responding to, and recovering from ICT-related risks. According to the European Supervisory Authorities’ joint report on digital operational resilience, over 22,000 financial entities across the EU must now implement this framework or face supervisory enforcement.

This article explains the full structure of the DORA ICT risk management framework, the governance obligations that attach at board level, each functional component, the simplified regime available to smaller firms, and how these requirements interact with ISO 27001 and GDPR.

What Does DORA Require for ICT Risk Governance?

DORA places ICT risk governance squarely on the management body of each financial entity. Article 5 establishes that the board of directors or equivalent governing body bears ultimate responsibility for defining, approving, overseeing, and being accountable for the implementation of the ICT risk management framework.

This is not a delegable obligation. While day-to-day execution may be assigned to senior management or a dedicated ICT risk function, Article 5(2) specifies that the management body must:

• Define the entity’s risk appetite with respect to ICT risk
• Approve and periodically review the ICT risk management framework
• Approve and review the ICT business continuity policy and ICT disaster recovery plans
• Allocate and periodically review the budget dedicated to fulfilling ICT risk management needs
• Ensure adequate training and awareness of ICT risks for all staff, including board members themselves

Article 5(4) requires members of the management body to maintain sufficient knowledge and skills to understand and assess ICT risks. Competent authorities may require evidence of ongoing training. A 2024 EBA survey found that only 38% of financial entities had formal ICT risk training programmes for board members at the time DORA entered into force, indicating a significant governance gap across the sector.

This board-level accountability mirrors the personal responsibility provisions found in GDPR Article 5(2) and the accountability principle, where data controllers must demonstrate compliance rather than merely assert it.

How Is the ICT Risk Management Framework Structured?

Article 6 requires financial entities to establish, maintain, and continuously update a sound, comprehensive, and well-documented ICT risk management framework. This framework must be integrated into the entity’s overall risk management system and must include strategies, policies, procedures, ICT protocols, and tools necessary to protect all information assets and ICT assets.

The framework must achieve three structural properties:

1. Completeness — covering all ICT-supported business functions, information assets, and ICT assets
2. Documentation — recorded in a manner that is auditable and available to competent authorities on request
3. Continuous improvement — reviewed at least annually and updated based on lessons learned from incidents, testing, and audit findings

Financial entities must also appoint a control function responsible for managing and overseeing ICT risk. For entities subject to the Capital Requirements Directive, this aligns with the existing three-lines-of-defence model. Smaller entities not subject to such requirements must still ensure adequate separation of duties.

Identification (Article 8)

Article 8 mandates a comprehensive identification process. Financial entities must identify, classify, and document all ICT-supported business functions, roles, and responsibilities. They must also identify and document all sources of ICT risk, including those arising from dependencies on ICT third-party service providers.

Specifically, entities must maintain an up-to-date inventory of:

• All information assets and ICT assets, including remote sites, network resources, and hardware
• The configuration of ICT assets and the interconnections between them
• All processes that depend on ICT third-party service providers

This inventory requirement has a direct parallel in GDPR compliance. Organisations subject to both frameworks will find that the Record of Processing Activities (ROPA) under GDPR Article 30 and the ICT asset inventory under DORA Article 8 overlap substantially, particularly regarding data flows and third-party dependencies.

Article 8 also requires entities to conduct risk assessments at least annually and whenever a major change occurs in network or information system infrastructure.

Protection and Prevention (Article 9)

Article 9 requires entities to deploy appropriate ICT security tools, policies, and procedures to ensure the resilience, continuity, and availability of ICT systems. The protection measures must be designed in accordance with a risk-based approach.

Key requirements include:

• Policies governing access rights management and the principle of least privilege
• Mechanisms for network security management, including segmentation and segregation
• Policies and procedures for patch and update management
• Strong authentication mechanisms, including multi-factor authentication
• Cryptographic controls for data in transit and at rest
• Physical security of ICT infrastructure

According to ENISA’s 2025 Threat Landscape report, 67% of significant ICT incidents in the financial sector involved exploitation of known vulnerabilities for which patches were available, underscoring the practical importance of DORA’s patch management requirements.

Detection (Article 10)

Article 10 requires financial entities to establish mechanisms to promptly detect anomalous activities. Detection capabilities must cover ICT-related incidents, threats, and vulnerabilities. Entities must implement:

• Multiple layers of control, including monitoring rules and alerting thresholds
• Mechanisms to detect misuse of access and anomalous network behaviour
• Processes for testing detection capabilities

Detection mechanisms must be tested periodically. The testing obligation under Article 10 feeds into the broader resilience testing programme mandated by DORA Chapter IV (Articles 24-27), creating a continuous feedback loop between detection and testing.

Response and Recovery (Articles 11-14)

Articles 11 through 14 address the entity’s ability to respond to and recover from ICT incidents. Article 11 requires a documented ICT business continuity policy that covers:

• Arrangements for the continuity of critical or important functions outsourced to ICT third-party service providers
• Response and recovery plans that are specific, well-documented, and regularly tested
• Estimated recovery times and recovery points for critical functions

Article 12 mandates backup policies and procedures, specifying that entities must determine the frequency of backups based on criticality of functions, and that restoration from backups must be periodically tested. Article 13 requires entities to maintain arrangements for learning and evolving from both ICT incidents and resilience testing, feeding insights back into the risk management framework.

Article 14 establishes communication obligations. Entities must have crisis communication policies for both internal and external stakeholders, including procedures for communicating with clients and counterparties during disruptions.

A 2024 Bank of England survey found that only 52% of financial institutions tested their ICT recovery plans at least annually, with 14% having never tested them at all. DORA eliminates this gap by making regular testing a binding obligation enforceable by supervisory authorities.

What Documentation Must Financial Entities Maintain?

DORA imposes extensive documentation requirements throughout Articles 5-16. At a minimum, entities must maintain written records of:

• The ICT risk management framework itself, including all strategies, policies, and procedures
• An inventory of ICT assets and information assets, updated continuously
• Risk assessment results, including identified vulnerabilities and remediation timelines
• ICT business continuity and disaster recovery plans
• Backup and restoration policies
• Incident response plans and post-incident review reports
• Results of resilience testing and remediation actions taken
• Evidence of board approval and oversight of the framework

This documentation must be available to competent authorities at any time. Article 6(5) requires that the framework be audited on a regular basis by ICT auditors with sufficient knowledge and independence.

For entities that also maintain GDPR compliance documentation, there is considerable overlap. Both regimes require documented policies, risk assessments, incident response plans, and evidence of governance oversight. Organisations can achieve efficiencies by aligning their DORA and GDPR documentation programmes, particularly for records relating to ICT security measures, third-party assessments, and incident management.

How Does the Simplified Framework Work for Micro-Enterprises?

Article 16 provides a simplified ICT risk management framework for entities that qualify as micro-enterprises under EU law (fewer than 10 employees and annual turnover or balance sheet total not exceeding EUR 2 million), as well as certain small and non-interconnected investment firms.

Under the simplified framework, eligible entities must still:

• Maintain an ICT risk management framework, but with reduced documentation requirements
• Identify critical functions and the ICT assets that support them
• Implement proportionate protection and detection measures
• Maintain business continuity arrangements
• Report major ICT incidents

However, the simplified regime relaxes several requirements. Eligible entities are not required to establish a dedicated ICT risk control function, do not need to conduct advanced threat-led penetration testing, and benefit from reduced reporting granularity. The proportionality principle allows these entities to calibrate their controls to their actual risk profile rather than meeting the full specification set out in Articles 5 through 15.

Importantly, Article 16 does not exempt micro-enterprises from DORA entirely. It reduces the procedural burden while preserving the substantive objectives. Supervisory authorities retain the power to request documentation and to enforce compliance, including through administrative penalties.

How Does DORA ICT Risk Management Relate to ISO 27001?

DORA does not reference ISO 27001 as a mandatory standard, but the structural alignment between the two is substantial. ISO 27001’s information security management system (ISMS) approach — plan, implement, monitor, improve — maps closely to DORA’s framework structure across Articles 5 through 16.

Key correspondences include:

DORA Requirement	ISO 27001 Control Area
ICT asset inventory (Art. 8)	Annex A.8 — Asset Management
Access control policies (Art. 9)	Annex A.9 — Access Control
Cryptographic controls (Art. 9)	Annex A.10 — Cryptography
Detection and monitoring (Art. 10)	Annex A.12 — Operations Security
Business continuity (Art. 11)	Annex A.17 — Business Continuity
Incident response (Art. 13)	Annex A.16 — Incident Management

Entities with a mature ISO 27001-certified ISMS will find that they have already addressed a significant portion of the DORA ICT risk management requirements. However, DORA goes further in several areas — particularly regarding board-level governance, specific recovery time requirements, and the mandatory testing of backup restoration procedures. An ISO 27001 certification alone does not constitute DORA compliance.

Where Do DORA and GDPR Overlap on Security Measures?

DORA Article 9 and GDPR Article 32 both require organisations to implement appropriate technical and organisational measures to ensure the security of ICT systems and personal data respectively. For financial entities processing personal data, both obligations apply simultaneously.

The overlap is significant. Measures such as encryption, access controls, pseudonymisation, regular security testing, and incident response capabilities satisfy requirements under both instruments. A detailed examination of these intersections is provided in our DORA vs GDPR overlap analysis.

However, there are important differences. GDPR Article 32 applies a risk-based standard calibrated to the nature of the personal data being processed. DORA imposes sector-specific requirements calibrated to the criticality of business functions and the systemic importance of the entity. An entity may meet GDPR’s standard for a particular processing operation while still falling short of DORA’s requirements for the underlying ICT system.

Similarly, entities subject to NIS2 — the EU’s Network and Information Security Directive — face a third layer of cybersecurity obligations. Many financial entities will be subject to all three regimes simultaneously, making a coordinated compliance approach essential.

Legiscope helps financial entities map these overlapping obligations and manage their compliance documentation across DORA, GDPR, and NIS2 from a single platform.

What Role Does Resilience Testing Play in the Framework?

While detailed resilience testing is addressed in DORA Chapter IV (Articles 24-27), the ICT risk management framework under Chapter II establishes the foundation. Article 10 requires detection capabilities to be tested. Article 12 requires backup restoration to be tested. Article 11 requires business continuity and disaster recovery plans to be tested.

The testing obligation within the ICT risk management framework is distinct from the advanced threat-led penetration testing required of significant entities. It applies to all financial entities regardless of size and must be conducted on a regular basis. Test results must be documented, reported to the management body, and used to update the framework.

According to the ECB’s 2024 supervisory data, institutions that conducted regular ICT testing experienced 41% fewer disruptive incidents than those that did not, providing empirical validation for DORA’s emphasis on continuous testing.

How Should Financial Entities Approach DORA ICT Risk Management Implementation?

Implementing the DORA ICT risk management framework is not a one-time project. It requires sustained organisational commitment, starting with governance and extending through every operational layer. Practical steps include:

1. Establish board-level governance — ensure the management body formally approves the framework and receives regular reports on ICT risk posture
2. Conduct a comprehensive asset inventory — identify all ICT assets, information assets, and third-party dependencies
3. Perform a gap analysis — compare current ICT security controls against the specific requirements of Articles 5-16
4. Implement protection, detection, and response measures — deploy controls proportionate to the entity’s risk profile and the criticality of its functions
5. Document everything — maintain auditable records of policies, risk assessments, test results, and governance decisions
6. Test and iterate — test continuity plans, backup restoration, and detection mechanisms regularly, and update the framework based on findings

Entities already holding ISO 27001 certification or maintaining mature compliance programmes under GDPR or NIS2 will have a significant head start. The key is to identify and address the DORA-specific gaps — particularly board accountability, mandatory testing frequencies, and the prescriptive documentation requirements that go beyond what existing frameworks demand.

For a broader view of the full regulation, including the other four pillars, see our complete DORA compliance guide.

FAQ

Does DORA ICT risk management apply to all financial entities equally?

No. While all 21 categories of in-scope financial entities must implement the ICT risk management framework, Article 4 applies a proportionality principle. Requirements are calibrated to the entity’s size, nature, scale, and complexity of services. Additionally, Article 16 provides a simplified framework for micro-enterprises and certain small investment firms.

Can ISO 27001 certification satisfy DORA ICT risk management requirements?

ISO 27001 covers substantial ground, but it is not sufficient on its own. DORA imposes specific obligations that go beyond ISO 27001, including mandatory board-level governance, prescribed testing frequencies for backup restoration, and detailed requirements for ICT asset inventory and third-party dependency mapping. Certification is a strong foundation, not a complete answer.

How does DORA ICT risk management interact with GDPR security obligations?

DORA Article 9 and GDPR Article 32 both require technical and organisational security measures. For financial entities processing personal data, both apply. Many controls — encryption, access management, incident response — satisfy both. However, the risk calibration differs: GDPR focuses on the sensitivity of personal data, while DORA focuses on the criticality of business functions and systemic risk. See our DORA vs GDPR overlap analysis for a full breakdown.

What happens if a financial entity fails to implement the DORA ICT risk management framework?

Competent authorities can impose administrative penalties, require remediation actions, and in severe cases restrict or suspend activities. Article 50 empowers supervisory authorities to impose periodic penalty payments to compel compliance. The specific penalty amounts are determined by national law, but DORA sets the floor for supervisory powers across all Member States.

Does the simplified framework under Article 16 exempt micro-enterprises from DORA?

No. Article 16 reduces procedural and documentation requirements but does not eliminate the substantive obligations. Micro-enterprises must still maintain an ICT risk management framework, implement proportionate security measures, and report major ICT incidents. Supervisory authorities retain full enforcement powers over these entities.