How to Build a DORA-Compliant ICT Risk Framework

The Digital Operational Resilience Act (DORA) places ICT risk management at the heart of financial services compliance. Under Articles 6–16, regulated entities must establish, implement, and maintain a comprehensive ICT risk management framework — not as a point-in-time exercise, but as a living, continuously monitored programme.

This guide breaks down what the framework must include, how to approach implementation, and where organisations typically fall short.

What DORA requires from your ICT risk framework

DORA Article 6 requires that financial entities have in place an internal governance and control framework that ensures effective and prudent management of all ICT risks. The framework must cover:

• An ICT risk strategy aligned to the entity's overall business strategy
• Documentation of all ICT assets, their functions, and interdependencies
• A risk assessment process for identifying threats and vulnerabilities
• Protection and prevention controls
• Detection capabilities for anomalous activities
• Response and recovery procedures
• Backup policies and tested recovery procedures
• A communication plan for ICT-related incidents

Crucially, the management body is responsible for approving the ICT risk framework and remains accountable for its implementation. This is not purely a technical or operational matter — it requires board-level sign-off and ongoing oversight.

The five core components

1. ICT asset inventory (Article 8)

You cannot manage risk on assets you don't know exist. DORA requires entities to maintain an up-to-date inventory of all ICT assets — hardware and software — with documented interdependencies between those assets and ICT processes, people, and other resources.

Practically, this means maintaining a register of all servers, endpoints, network devices, and cloud services; software inventory including versions and patch status; mapping of which ICT assets support which critical or important functions; and documentation of connections to third-party systems.

2. Risk identification and classification (Articles 6 and 9)

Once assets are mapped, you must assess the risks associated with each. DORA requires a structured approach to identifying ICT risks — including cyber threats, operational failures, and third-party dependencies — and classifying them by likelihood and potential impact.

3. Protection and prevention controls (Article 9)

Article 9 requires entities to implement measures to protect ICT assets. This includes access control and identity management; multi-factor authentication for systems supporting critical or important functions; network segmentation; encryption of data at rest and in transit; patch and vulnerability management; and physical security of ICT infrastructure.

4. Detection capabilities (Article 10)

DORA requires mechanisms to promptly detect anomalous activities, potential vulnerabilities, and ICT-related incidents. In practice, this typically involves a SIEM (Security Information and Event Management) system, endpoint detection and response (EDR) tooling, network traffic analysis, and log management aligned to Article 20 requirements. Detection mechanisms must have defined thresholds and be regularly tested.

5. Response and recovery (Articles 11–12)

Your framework must include documented procedures for responding to detected incidents (linked to your incident management policy), business continuity plans for ICT disruptions, disaster recovery with defined recovery time objectives (RTOs) and recovery point objectives (RPOs), and backup policies with tested restoration procedures.

Article 12 requires that backups are kept separately from the primary system and that restoration procedures are tested at least annually. Backup integrity must be verified regularly.

Common gaps we see in DORA ICT risk frameworks

Based on regulatory guidance and supervisory expectations, the most common gaps include:

1. Incomplete asset inventories — Shadow IT, unregistered cloud services, and end-of-life systems frequently fall outside formal registers.
2. Annual-only risk assessments — Treating the risk assessment as a yearly exercise rather than a continuous process does not meet DORA's standard.
3. Weak interdependency mapping — Not documenting the links between ICT assets and critical business functions is a common audit finding.
4. Inadequate third-party risk capture — Failing to include ICT third-party dependencies in the risk assessment leaves a significant gap.
5. Untested recovery procedures — Having documented RTO/RPO targets but not conducting regular tests to validate them exposes the entity to regulatory challenge.

How to demonstrate compliance

Regulators will expect to see a documented ICT risk framework with version control and approval by the management body; evidence of regular risk assessments including dates, scope, and findings; control testing records showing that protection measures are working; and audit trails for any changes to the framework.

This is where many organisations struggle — the framework exists in documentation, but the evidence that it is being actively maintained and tested does not. Under DORA, the framework must be reviewed and updated at a minimum annually and following any major ICT-related incident.

The role of technology in ICT risk management

Given the volume of controls, assets, and ongoing monitoring requirements, manual spreadsheet-based approaches to ICT risk management quickly become unsustainable. RegTech platforms designed for DORA automate evidence collection from existing tooling — SIEM, ITSM, cloud security posture management — and maintain the control mapping and audit trail required for regulatory examination.

The key is choosing a solution that maps directly to DORA's article structure rather than requiring a translation layer between the regulation and your internal control framework.