ICT Risk Management under DORA

ICT Risk Management: The Foundation of DORA

Articles 5 through 16 of DORA (EU Regulation 2022/2554) establish the most comprehensive pillar of the regulation: the ICT risk management framework. This framework forms the backbone of digital operational resilience. Every other DORA requirement, from incident reporting to third-party risk management, builds upon the structures and processes defined here.

Unlike previous sectoral guidelines, DORA takes a prescriptive approach. It does not merely require financial entities to "have" an ICT risk framework. It specifies exactly what the framework must contain, how governance must be structured, and which lifecycle phases must be addressed.

Governance and Management Responsibility (Art. 5)

Art. 5 places ultimate responsibility for ICT risk management squarely on the management body. This is not a delegable task. The management body must:

• Define, approve, oversee, and be accountable for the implementation of the ICT risk management framework
• Set clear roles and responsibilities for all ICT-related functions
• Define the appropriate level of risk tolerance for ICT risk
• Approve and periodically review the ICT business continuity policy and ICT response and recovery plans
• Approve and review internal ICT audit plans and ICT audits, and material changes arising from them
• Allocate and periodically review adequate budget for ICT security
• Maintain adequate knowledge and skills regarding ICT risk, updated through regular training

The training requirement for the management body is explicit. Members must undergo training sufficiently frequent to keep pace with the ICT risk landscape. This is not optional. Supervisory authorities can examine whether the management body demonstrates adequate ICT competence.

The ICT Risk Management Framework (Art. 6-7)

Art. 6 requires financial entities to maintain a sound, comprehensive, and well-documented ICT risk management framework as part of their overall risk management system. The framework must include all strategies, policies, procedures, ICT protocols, and tools necessary to adequately protect all information assets and ICT assets.

Key structural requirements of the framework:

• A digital operational resilience strategy (Art. 6(8)) that explains how the framework is implemented, sets objectives for ICT security, and describes the architecture of ICT systems
• An independent ICT control function (second line of defence) separate from ICT operations
• Internal ICT audit capability (third line of defence) with adequate frequency based on the entity's ICT risk profile
• Documentation that is kept up to date and made available to competent authorities upon request
• Annual review of the framework, or after major ICT incidents or supervisory findings

Art. 7 mandates that entities establish ICT systems, protocols, and tools that are reliable, have sufficient capacity, and are technologically resilient. These must be continuously maintained and updated.

Identification (Art. 8)

Art. 8 requires entities to identify, classify, and adequately document all ICT-supported business functions, roles, and responsibilities. This includes mapping all information assets and ICT assets, identifying sources of ICT risk, and assessing cyber threats and ICT vulnerabilities relevant to the entity's business functions.

Entities must maintain an up-to-date inventory of all ICT assets and perform a risk assessment at least annually, as well as after any material change to the network or information system infrastructure. The inventory should capture dependencies between ICT assets, business functions, and ICT third-party providers.

Protection and Prevention (Art. 9)

Art. 9 specifies the preventive measures that form the entity's first line of defence. The requirements are detailed and cover:

• Policies for identity management, strong authentication, and access control including the principle of least privilege
• ICT change management policies including patching, updates, and change control
• Policies for data classification and encryption at rest and in transit
• Network security management including network segmentation
• Mechanisms to promptly disconnect or disable compromised network segments

Detection (Art. 10)

Art. 10 requires entities to deploy mechanisms and processes for the prompt detection of anomalous activities. This includes monitoring network performance, detecting ICT-related incidents, and identifying potential single points of failure. Multiple layers of detection control must be in place, with alert thresholds and trigger criteria for ICT incident response processes.

In practice, this means implementing SIEM systems, intrusion detection systems (IDS), log correlation, and establishing a SOC or equivalent capability. The detection function must be tested periodically in accordance with Art. 25 (resilience testing). See our Resilience Testing page for more.

Response and Recovery (Art. 11-14)

Art. 11 requires a comprehensive ICT business continuity policy that ensures continuity of the entity's critical or important functions. This must include:

• Business Impact Analysis (BIA) to determine the potential impact of severe disruptions
• ICT response and recovery plans with defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)
• Activation of dedicated incident response teams with clear escalation procedures
• Crisis communication plans covering staff, external stakeholders, media, and clients

Art. 12 covers backup policies and procedures, requiring entities to maintain backup systems that are physically and logically separated from the production environment. Art. 14 mandates regular testing of response and recovery plans, including scenario-based testing and switchover tests to backup facilities.

The response framework is closely linked to the incident reporting obligations under Art. 17-23. Once an incident is detected, both the response procedure and the reporting timeline begin simultaneously. See our Incident Reporting page for the complete reporting procedure.

Learning, Evolving, and Communication (Art. 13, 15)

Art. 13 requires entities to maintain capabilities and staff to gather information on vulnerabilities, cyber threats, and ICT-related incidents, and to analyse their likely impact on digital operational resilience. Post-incident reviews must be conducted after major disruptions, and lessons learned must feed back into the ICT risk management framework.

Art. 15 establishes requirements for internal communication, including policies for communicating ICT-related incidents to staff, an awareness programme for ICT security, and communication to the management body.

The Simplified Framework (Art. 16)

Art. 16 provides a simplified ICT risk management framework for certain small and non-interconnected financial entities. Qualifying entities are exempt from the full requirements of Art. 5-15 but must still maintain a framework that is proportionate to their size, risk profile, and complexity.

The simplified framework covers the same lifecycle phases (identify, protect, detect, respond, recover) but with reduced documentation, governance, and testing requirements. However, qualifying entities must still comply fully with the incident reporting requirements under Art. 17-23.

For a detailed comparison of the full and simplified framework, see our DORA Proportionality and Simplified Framework page.

Practical Implementation Tips

• Start with a gap analysis: Compare your existing ISMS (e.g. ISO 27001) against Art. 5-16. Many organisations already cover 50-70% of DORA requirements. See our ISO 27001 and DORA mapping for details.
• Secure management body buy-in early: Art. 5 makes the management body personally accountable. Present the regulatory requirements and the entity's current posture to the board to ensure budget and priority alignment.
• Automate documentation: The framework must be documented, reviewed annually, and available to supervisors on request. Manual documentation in spreadsheets will not scale. A GRC platform like Kopexa keeps your framework living and audit-ready.
• Align with RTS and ITS: DORA is supplemented by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that add granular detail. Ensure your framework addresses these standards as they are published.