Art. 5

Management Body Responsibilities

Art. 5 places ultimate responsibility for ICT risk management squarely on the management body. This is not a delegation-friendly obligation. While the management body may appoint a Chief Information Security Officer or equivalent to manage day-to-day operations, the board or executive management retains personal accountability for the framework's adequacy and effectiveness.

The management body must approve and regularly review the ICT risk management framework, the ICT strategy, the ICT business continuity policy, and the internal audit plans for ICT. It must define and approve the entity's digital operational resilience strategy and ICT risk appetite. Members must stay informed about the ICT threat landscape relevant to the entity and ensure adequate budget and resources are allocated to ICT security and resilience.

Training obligation: Art. 5(4) requires members of the management body to keep their ICT knowledge up to date, including by attending relevant training. Supervisors may assess whether board members have sufficient understanding of ICT risk during supervisory reviews. This requirement is unique to DORA and goes beyond what most existing financial regulation demands.

In practice, this means the management body should receive regular ICT risk reporting, typically quarterly or after significant events. Reports should cover the current risk posture, open vulnerabilities, incident trends, testing results, and the status of remediation activities. DORA GRC generates these board-level reports automatically from live data across all five pillars.

Art. 6

ICT Risk Management Framework Requirements

Art. 6 sets out what the ICT risk management framework must contain. It must be a documented, comprehensive set of strategies, policies, procedures, and ICT tools that the entity uses to manage ICT risk. The framework must be reviewed at least once a year, or more frequently following significant ICT incidents or material changes to the ICT landscape.

The framework must include a digital operational resilience strategy that explains how the entity will implement the framework. It must define the methods for addressing ICT risk, set key performance indicators and risk metrics, and describe how the entity's ICT architecture supports its business strategy. It must also account for changes in the ICT threat landscape and incorporate lessons learned from past incidents and testing.

RTS 2024/1774 provides detailed specifications on the content of the framework, including requirements for ICT asset management policies, encryption policies, access control policies, capacity and performance management, and vulnerability management. Entities should use the RTS as a checklist when building or reviewing their framework documentation.

An independent internal audit function must review the ICT risk management framework at least annually. The audit must assess whether the framework is adequate, effective, and compliant with DORA and the applicable technical standards. Audit findings must be reported to the management body and tracked to remediation.

Art. 8

ICT Systems and Asset Identification

Art. 8 requires entities to identify, classify, and document all ICT-supported business functions, the ICT assets that support them, and the dependencies between them. This is the foundation on which everything else in the framework rests. Without a complete and accurate inventory, risk assessments, business continuity plans, and testing programmes cannot function effectively.

The entity must maintain a register of all ICT assets, including hardware, software, data repositories, and network components. Each asset must be classified by criticality, and the register must record which business functions each asset supports, which providers supply or maintain the asset, and what dependencies exist between assets.

Art. 8(4) specifically requires entities to map the interconnections and dependencies between ICT-supported business functions, ICT assets, and ICT third-party providers. This dependency mapping is essential for understanding concentration risk, planning business continuity, and scoping resilience testing. DORA GRC's CIF register and dependency mapping tools automate this process and link directly to the asset register and provider register.

Continuous maintenance: The asset register is not a one-time exercise. Art. 8(1) requires entities to keep it up to date on a continuous basis. Any new system, decommissioned asset, or change in provider arrangement must be reflected promptly. Many supervisors treat the accuracy and completeness of the asset register as a primary indicator of ICT risk management maturity.
Art. 9

Protection and Prevention Measures

Art. 9 requires entities to implement a comprehensive set of ICT security policies and procedures to protect their ICT systems. These measures must be designed to ensure the confidentiality, integrity, and availability of data and ICT systems, and must be proportionate to the entity's risk appetite and the criticality of the systems being protected.

The required measures include access control policies that limit system access to authorised personnel on a need-to-know and least-privilege basis. Entities must implement strong authentication mechanisms, particularly for access to critical systems and for remote access. Encryption must be applied to data at rest and in transit, with key management procedures that are documented and auditable.

Network security measures must include segmentation, firewall management, and intrusion detection. Entities must have policies for patch management that define timelines for applying security updates based on severity, and must maintain hardened configurations for all ICT systems. Physical security of ICT infrastructure must also be addressed, including data centres and network equipment.

Change management procedures are required under Art. 9(4)(e), covering all changes to ICT systems, from minor patches to major platform migrations. Changes to critical systems must be risk-assessed, tested, and approved before deployment, with rollback procedures documented and available.

Art. 10

Detection and Monitoring

Art. 10 requires entities to establish mechanisms to promptly detect anomalous activities on their ICT systems. This includes network traffic monitoring, log analysis, and correlation of security events. Detection capabilities must cover both internal threats and external attack vectors.

Entities must implement multiple layers of detection controls, including automated alerting for known threat indicators, behavioural analysis for unusual patterns, and monitoring of privileged account activity. The detection mechanisms must be tested regularly as part of the resilience testing programme required under Art. 24-25.

Log retention and analysis are central to Art. 10 compliance. Entities must collect and retain logs from all critical ICT systems for a sufficient period to support incident investigation and regulatory enquiries. The logs must be protected against tampering and stored securely. RTS 2024/1774 provides further detail on minimum logging requirements and retention periods.

Art. 11

Response and Recovery

Art. 11 deals with business continuity management and ICT disaster recovery. Every financial entity must establish a business continuity policy, business continuity plans, and ICT disaster recovery plans. These plans must define Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and Maximum Tolerable Periods of Disruption (MTPD) for each critical or important function.

The plans must be based on business impact analysis that considers the potential consequences of severe disruptions to the entity's critical functions. They must include procedures for activating the plans, communicating with stakeholders, and managing the crisis through to resolution. The plans must also address the scenario where a critical ICT third-party provider becomes unavailable.

Art. 11(5) requires that BCP and disaster recovery plans be tested at least annually. The testing must cover the full recovery process, not just individual components. Results must be documented and used to update the plans. If a test reveals that the entity cannot meet its defined recovery objectives, this must be escalated to the management body and remediated promptly.

DORA GRC's BCP module manages plans, test schedules, and results in a single workflow. Test findings link back to the risk register and are visible in the compliance dashboard, so gaps are tracked to closure automatically.

Art. 12

Backup and Restoration

Art. 12 sets specific requirements for backup policies and procedures. Entities must define backup scope, frequency, and retention periods for all critical ICT systems and data. Backup procedures must ensure that data can be restored to a known good state within the defined RPO and RTO for each critical function.

Backups must be stored in a location that is physically and logically separate from the production environment, to ensure they survive a disruption that affects the primary systems. The backup infrastructure must itself be protected against unauthorised access, corruption, and environmental threats.

Restoration procedures must be tested regularly. It is not sufficient to verify that backups are created; entities must verify that they can be restored successfully and that the restored data is complete and consistent. Restoration testing should be incorporated into the broader business continuity testing programme under Art. 11(5).

Art. 13

Learning and Evolving

Art. 13 requires entities to establish processes for learning from ICT-related incidents, both their own and those experienced by the broader financial sector. After each significant incident, the entity must conduct a post-incident review to identify root causes, assess the effectiveness of the response, and determine what improvements are needed.

The learning process must also incorporate external threat intelligence. Entities must monitor the evolving ICT threat landscape, including vulnerabilities, attack methods, and incidents reported by peers and by the ESAs. This intelligence must feed into the ICT risk management framework, driving updates to risk assessments, controls, and testing priorities.

Training and awareness programmes must ensure that all staff understand their role in ICT risk management. Staff handling critical ICT systems must receive targeted training that covers the specific threats and controls relevant to their functions. The management body's training obligation under Art. 5(4) is a separate, additional requirement.

Art. 14

Communication Obligations

Art. 14 requires entities to have policies and procedures for internal and external communication related to ICT incidents and vulnerabilities. Internally, there must be clear escalation paths for reporting incidents, and staff must know who to contact and what information to provide. Externally, the entity must be able to communicate with clients, counterparties, regulators, and the public as required.

The communication plan must cover crisis communication scenarios where an ICT incident affects service delivery or data security. It must define who is authorised to make external statements, what information can be shared, and how to comply with any regulatory notification requirements. These procedures should be tested as part of the scenario-based exercises under Art. 25.

Art. 16

Simplified Framework for Smaller Entities

Art. 16 provides a simplified ICT risk management framework for certain smaller financial entities. This applies to entities that meet the criteria defined in Art. 16(1), which includes microenterprises (fewer than 10 employees and annual turnover or balance sheet total below EUR 2 million) and certain other small entities as determined by their NCA.

The simplified framework retains the core principles of ICT risk management but reduces the procedural and documentation burden. Entities under the simplified regime must still maintain an ICT risk management framework, but with less formal documentation requirements. They must still identify and protect their critical ICT systems, respond to incidents, and maintain business continuity arrangements, but the depth and frequency of activities may be reduced.

Important: The simplified framework is not an exemption. Entities under Art. 16 are still fully subject to DORA. They must still comply with incident reporting under Art. 17-23, maintain contractual requirements with ICT providers under Art. 28-30, and operate a proportionate testing programme. The simplification applies primarily to the documentation and procedural requirements of the risk management framework itself. Check with your NCA to confirm whether you qualify for the simplified regime.
FAQ

Frequently Asked Questions

The DORA ICT risk management framework is the set of policies, procedures, protocols, and tools that a financial entity must establish under Articles 5-16 of EU Regulation 2022/2554. It covers governance responsibilities, ICT asset identification, protection and prevention measures, detection and monitoring, response and recovery, backup and restoration, learning, and communication. The framework must be documented, reviewed at least annually, and subject to internal audit.

Under Art. 5, the management body bears ultimate responsibility for the ICT risk management framework. Members must define the entity's ICT risk appetite, approve the framework and ICT strategy, allocate adequate budget and resources, stay informed about the ICT threat landscape, and keep their own ICT knowledge up to date through training. These responsibilities cannot be fully delegated to the IT department or a CISO.

Yes. Art. 16 provides a simplified ICT risk management framework for certain smaller financial entities, including microenterprises. The simplified framework retains the core principles of risk management but reduces the documentation and procedural requirements. Entities should confirm their eligibility with their national competent authority, as the criteria may vary slightly by jurisdiction.

DORA defines ICT risk as any reasonably identifiable circumstance related to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology-dependent tool or process, of the operations and processes, or of the provision of services, thereby adversely affecting the integrity or availability of data, software or any other component of ICT services and infrastructures, or causing a breach of confidentiality. This is a broad definition that covers technology failures, cyber attacks, and human errors affecting ICT systems.