DORA ICT Risk Management: What Financial Entities Must Document

Overview

The Digital Operational Resilience Act (DORA) entered full enforcement in January 2025, marking a watershed moment for EU financial services compliance. For the first time, ICT risk management requirements are codified in binding EU law — and the European Supervisory Authorities (ESAs) have made clear they intend to enforce them rigorously.

This guide breaks down exactly what financial entities need to document under DORA Articles 5-14, and what a compliant ICT Risk Management Framework looks like in practice.

Who Is In Scope?

DORA applies to a broad range of financial entities under Article 2, including:

• Credit institutions and investment firms
• Insurance and reinsurance undertakings
• Payment institutions and e-money institutions
• Crypto-asset service providers
• ICT third-party service providers designated as critical (CTPPs)

Simplified requirements apply to small and non-interconnected investment firms and certain other entities — but the core ICT risk management obligations apply across the board.

The ICT Risk Management Framework: Articles 5-14

Governance (Articles 5-6)

DORA requires a clear governance structure for ICT risk. The management body — typically the board — must:

• Approve and oversee the ICT risk management framework
• Define ICT risk appetite and tolerance thresholds
• Receive regular reporting on ICT risk exposures
• Ensure adequate ICT staffing and budget

What to document: A board-approved ICT Risk Governance Policy that defines roles, responsibilities, reporting lines, and escalation procedures. This must name the individuals responsible for ICT risk at the management body level.

ICT Risk Management Framework (Articles 7-8)

Article 7 requires a comprehensive, documented framework covering all ICT assets and risks. Article 8 mandates an up-to-date register of all ICT assets — hardware, software, data, and services — including criticality assessments.

What to document:

• ICT Asset Register with criticality classification
• Risk identification methodology
• ICT risk appetite statement with quantitative tolerance thresholds where possible

Protection and Prevention (Articles 9-10)

Protection measures must cover:

• Access control and privileged access management
• ICT security policies and awareness programmes
• Patch and vulnerability management processes
• Encryption standards and key management

What to document: A comprehensive ICT Security Policy covering each of the Article 9 requirements, including specific controls for critical systems.

Detection (Article 10)

Financial entities must have mechanisms to promptly detect anomalous activities, including ICT-related incidents and vulnerabilities.

What to document: Detection procedures covering log management, anomaly detection thresholds, and responsibilities for monitoring.

ICT-Related Incident Response (Article 11)

Article 11 requires documented ICT business continuity procedures as part of the broader operational resilience framework.

What to document: ICT Business Continuity Plan (BCP) with Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for critical systems.

ICT Disaster Recovery (Article 12)

The ICT DR Plan must include:

• Documented recovery procedures for critical systems
• Alternative processing facilities or cloud failover configurations
• Backup procedures with testing schedules
• Annual DR testing requirements

What to document: ICT Disaster Recovery Plan with specific RTO/RPO commitments, backup verification procedures, and a testing schedule compliant with Article 12(5).

ICT Learning and Evolving (Article 13)

Post-incident reviews and lessons learned must be documented and fed back into the ICT risk framework.

What to document: Post-incident review template and process for updating the framework based on findings.

Board Reporting (Article 14)

Management bodies must receive regular, comprehensive reporting on ICT risk. Article 14 specifies minimum reporting content including current risk posture, significant incidents, third-party dependencies, and testing results.

What to document: Board ICT Risk Dashboard template with standardised metrics and reporting cadence.

Common Documentation Gaps

Based on regulatory guidance and inspection findings, the most common gaps are:

1. No quantitative risk appetite — stating “low risk appetite for ICT disruption” is insufficient; ESAs expect threshold-based metrics
2. Asset register without criticality classification — listing assets without assessing which are critical to business functions
3. DR plan without tested RPOs/RTOs — plans that specify recovery objectives but have no evidence of testing
4. Generic security policies — policies copied from standards frameworks without mapping to DORA’s specific requirements

How the GRCBlueprints DORA ICT Risk Framework Template Helps

The DORA ICT Risk Management Framework blueprint covers all Articles 5-14 requirements in a single 28-page DOCX template. It includes:

• Pre-populated governance structure with editable roles
• Quantitative risk appetite statement framework
• ICT asset register with criticality scoring matrix
• BCP and DR plan templates with RTO/RPO tables
• Board reporting dashboard with KPIs mapped to Article 14

The template is built against the actual DORA legislative text and the EBA/ESMA Joint Guidelines on ICT and Security Risk Management, not summarised guidance.

Next Steps

Review your current ICT risk documentation against the Article 5-14 checklist above. If gaps exist — particularly around governance, asset inventory, or DR testing documentation — the enforcement clock is already running.

For financial entities that haven’t yet completed their DORA ICT risk documentation, the GRCBlueprints ICT Risk Management Framework provides a complete starting point that can be adapted to your specific architecture and risk profile in a matter of days rather than weeks.