DORA ICT Risk Management: The Complete Guide for Financial Entities (2026)

The Digital Operational Resilience Act has been fully applicable since January 17, 2025. For financial entities that deferred DORA readiness work pending final RTS publication, that date was a hard stop. For those that began compliance programs in 2023 or 2024, 2026 is the year where supervisory scrutiny intensifies and early enforcement decisions begin shaping how the regulation is interpreted in practice.

ICT risk management is DORA's foundational pillar. Everything else — incident reporting, resilience testing, third-party risk management — is built on the assumption that financial entities have a functioning, documented ICT risk management framework in place. If that foundation is weak, nothing else can be compliant.

This guide provides a complete breakdown of what DORA Chapter II actually requires, how the January 2025 RTS translate those requirements into specific tools and processes, and how compliance teams should approach ongoing monitoring of this evolving regulatory area.

What DORA Requires for ICT Risk Management

Chapter II of DORA (Articles 5–16) establishes the ICT risk management framework requirements. The core obligation is straightforward: financial entities must have a comprehensive, documented, and regularly reviewed ICT risk management framework. What makes implementation complex is the specificity of what that framework must contain.

Article 5 of DORA establishes the governance foundation. The management body of the financial entity — not the CTO, not the CISO, but the board-level management body — bears ultimate responsibility for ICT risk management. Specifically, Article 5 requires the management body to:

• Define, approve, oversee, and be accountable for implementing the ICT risk management framework
• Set a clear risk appetite for ICT risk, including the tolerance for ICT disruptions
• Allocate adequate ICT budget and human resources
• Approve the ICT strategy, including the digital operational resilience strategy under Article 6(8)
• Keep adequate knowledge of ICT risk to properly challenge management reporting

The board-level accountability in Article 5 is not ceremonial. The RTS specify that management body members must undertake regular training on ICT risk. Supervisors will assess whether boards genuinely understand ICT risk or are merely rubber-stamping management submissions.

Article 6 of DORA describes the ICT risk management framework itself — what it must contain, how it must be documented, and how it must evolve. The framework must be documented in a dedicated ICT risk management policy that is reviewed at least annually and after every major ICT incident or major change to the ICT infrastructure.

"DORA's ICT risk management framework is not a checklist. It's an integrated system of controls where each layer feeds into the next. A gap in identification means you can't protect what you don't know you have. A gap in detection means incidents escalate unnoticed. Supervisors are looking for coherence across all five layers, not box-ticking on individual requirements."

The practical challenge for many financial entities is that DORA's requirements consolidate and formalize what was previously scattered across different frameworks (ISO 27001, NIST CSF, EBA ICT Guidelines). The resulting DORA ICT risk management framework must be a single, coherent document — not a collection of existing policies with a DORA label appended.

The 5-Layer ICT Risk Management Framework

DORA's ICT risk management framework is most practically understood as five interconnected layers, each addressing a different phase of the risk lifecycle. The RTS provide detailed requirements for each layer.

Layer 1: Governance and Organization (Article 5)

The foundation of the framework. Requirements include:

• Documented allocation of ICT risk responsibilities across the three lines of defense
• A dedicated ICT risk management function with clear reporting lines to the management body
• An ICT risk appetite statement approved by the management body, specifying tolerance levels for ICT disruption, data loss, and availability degradation
• Defined escalation paths for ICT incidents, including thresholds for escalation to the management body
• Annual training for management body members on ICT risk, with records maintained

The governance layer is where DORA departs most sharply from prior ICT guidance. Earlier EBA ICT Guidelines placed responsibility with senior management. DORA places ultimate accountability at management body level. This distinction has significant implications for how compliance teams document and report ICT risk — the audience is now the board, not just the CTO.

Layer 2: Risk Identification and Classification (Articles 8–9)

Financial entities must maintain a complete, up-to-date inventory of all ICT assets — hardware, software, data, and network infrastructure — and classify them by criticality. Article 8 of DORA requires:

• An ICT asset register covering all assets used in critical or important functions, including assets managed by third-party providers
• Asset classification by criticality, based on the ICT-related risk they pose if compromised
• Documented dependencies between ICT assets and critical business functions
• Identification of single points of failure in ICT systems supporting critical or important functions
• Regular updating of the asset register, including when third-party arrangements change

Article 9 of DORA extends the identification requirement to ICT risks themselves: entities must continuously identify and document ICT risks associated with each asset, including risks arising from third-party dependencies and from the interconnection of ICT systems across the entity and with external providers. Risk assessments must be conducted after every significant change to the ICT environment and at least annually for all assets.

Layer 3: Protection and Prevention (Articles 9–10)

Once identified, ICT risks must be addressed through protection and prevention controls. The RTS published in January 2025 provide granular requirements in this area. Key controls mandated by Article 9(4) of DORA include:

• Network segmentation: Critical systems must be segregated from non-critical systems and from third-party accessible zones
• Identity and access management: Privileged access must be controlled with multi-factor authentication; access rights reviewed at least annually and upon role changes
• Cryptographic controls: Encryption at rest and in transit for data classified as critical or confidential
• Patch and vulnerability management: Documented processes for identifying, assessing, and remediating vulnerabilities, with defined timelines based on severity classification
• Physical security: Documented controls for data center and office infrastructure hosting ICT systems supporting critical functions
• Capacity and performance management: Monitoring of ICT system performance against defined thresholds, with escalation procedures for performance degradation

The January 2025 RTS also specify requirements for ICT project management and change management — all significant changes to ICT systems must go through a documented change control process that includes ICT risk assessment before implementation.

Layer 4: Detection (Article 10)

Article 10 of DORA requires financial entities to implement mechanisms to promptly detect anomalous activities, including ICT-related incidents and potential vulnerabilities. Detection requirements include:

• Continuous monitoring of ICT systems, including network traffic, user activity, and system events
• Defined thresholds for what constitutes an anomalous event requiring investigation
• Logging of security-relevant events, with log retention for a minimum period defined in the RTS
• A Security Information and Event Management (SIEM) system or equivalent capability for entities with complex ICT environments
• Regular testing of detection mechanisms, including penetration testing and red team exercises for entities subject to the enhanced framework

The detection layer connects directly to DORA's incident reporting obligations under Chapter III (Articles 17–23). An entity that cannot demonstrate effective detection mechanisms will face questions about whether its incident reports are complete and timely.

Layer 5: Response and Recovery (Articles 11–12)

Article 11 of DORA requires financial entities to have documented ICT Business Continuity and Disaster Recovery (BC/DR) plans that have been tested. Specific requirements include:

• Documented Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for all ICT systems supporting critical or important functions
• Business Impact Analysis (BIA) identifying which functions are critical and what the maximum tolerable downtime is for each
• Tested failover procedures for critical systems, including activation of backup systems and transfer to alternate processing sites
• Crisis communication procedures, including internal escalation and external notification (regulators, market participants where applicable)
• Annual testing of BC/DR plans, with results documented and lessons incorporated into plan updates

Article 12 of DORA separately addresses backup policies: financial entities must maintain backup systems for all critical data and ICT systems, with backup copies stored in a geographically separate location from primary systems and tested regularly. The RTS specify minimum backup frequency based on data criticality classification. For detailed implementation guidance, see also our DORA compliance guide.

Key RTS Requirements (January 2025)

The Commission Delegated Regulation specifying the RTS on ICT risk management tools, methods, processes and policies was published on January 17, 2025, the same day DORA came into full application. Developed jointly by EBA, ESMA, and EIOPA, the RTS translate DORA's framework-level requirements into operational specifics.

ICT Asset Register Standards

The RTS specify that the ICT asset register must include, for each asset: asset type, asset name, business function(s) supported, owner/responsible party, location, interdependencies with other assets, third-party provider(s) if applicable, and classification (critical/important vs. non-critical). The register must be maintained in a format accessible for supervisory review and updated within defined timelines when changes occur.

ICT Risk Appetite Specification

The RTS require the ICT risk appetite statement to include quantitative and qualitative tolerances for: system availability (expressed as maximum permitted downtime per period for each critical system), data integrity failures (maximum acceptable data loss), cybersecurity incidents (response time thresholds), and third-party ICT failures (concentration risk limits). The risk appetite statement must be reviewed at least annually and cascaded into specific ICT risk limits for individual business lines and systems.

Vulnerability and Patch Management

One of the more operationally demanding RTS requirements. Financial entities must:

• Subscribe to recognized threat intelligence feeds covering the software and hardware in their ICT environment
• Classify vulnerabilities using a recognized scoring framework (e.g., CVSS) within defined timelines of discovery
• Define and enforce patching timelines based on severity: critical vulnerabilities patched within 48 hours of availability of patch, high-severity within 7 days, medium within 30 days
• Maintain a documented exception process for cases where patching cannot be applied within the defined timeline, with compensating controls
• Conduct vulnerability scans of external-facing systems at least quarterly and after significant changes

Cryptographic Key Management

The RTS specify that financial entities must have a documented cryptographic key management policy covering: key generation, storage, distribution, rotation, revocation, and destruction. Keys used for critical systems must be rotated at least annually. Hardware Security Modules (HSMs) must be used for cryptographic operations on critical systems where operationally feasible.

Third-Party ICT Risk: The CTPP Register

DORA Chapter V (Articles 28–44) addresses ICT third-party risk management, but the foundation is laid in Chapter II: Article 8's requirement to include third-party assets in the ICT asset register, and Article 9's requirement to assess risks arising from third-party dependencies.

The Critical Third-Party Provider (CTPP) framework is DORA's most structurally novel contribution to financial regulation. Under Article 31 of DORA, the ESAs jointly designate ICT third-party service providers as "critical" based on systemic importance. As of early 2026, the Lead Overseer framework is operational and the first cohort of CTPPs has been designated.

For financial entities, CTPP designation of a provider has direct compliance implications:

• Contracts with CTPPs must include the enhanced contractual requirements specified in Article 30 of DORA and the January 2025 RTS on contractual arrangements
• Financial entities must assess their concentration risk: if a significant portion of critical functions relies on a single CTPP or a small number of CTPPs, this must be addressed in the ICT risk management framework
• Financial entities must cooperate with Lead Overseer inspections of CTPPs that affect their systems, including providing documentation about their use of the CTPP's services
• Exit strategies must be documented for each CTPP, demonstrating how the financial entity could migrate to an alternative provider within an acceptable timeframe

The CTPP register maintained by the ESAs is a key document for compliance teams to monitor. CTPP designations are published by the Joint ESA Committee and affect the contractual obligations of every financial entity using those services. For a broader view of how regulatory monitoring tools support this kind of ongoing obligation, see our analysis of regulatory monitoring software for compliance teams.

The Third-Party Register

Under Article 28(3) of DORA, financial entities must maintain a register of all contractual arrangements with ICT third-party service providers. This register must include: provider name and location, services provided, classification (critical/important function vs. non-critical), contract start and end dates, and concentration risk indicators. The register must be submitted to the competent authority upon request and is subject to supervisory review.

For complex financial groups with dozens or hundreds of ICT vendor relationships, maintaining this register is a significant data management exercise. The register must also capture changes — new contracts, renewals, terminations — in real time.

Penalties for Non-Compliance

DORA Article 50 requires member states to establish administrative penalties and remedial measures for violations of DORA that are "effective, proportionate, and dissuasive." The specific penalty levels are set at the national level, but the regulation provides minimum standards.

Financial Entity Penalties

For most financial entities, the competent authority can impose:

• Periodic penalty payments of up to 1% of average daily worldwide turnover for each day of ongoing violation (applicable for a maximum of six months)
• A one-time administrative penalty of up to 2% of total annual net worldwide turnover for significant breaches
• Reputational sanctions: public statements identifying the responsible party and the nature of the infringement
• Temporary prohibition of the management body members responsible for the infringement from exercising management functions

In practice, the 1% daily penalty is the mechanism most likely to be used in cases of persistent non-compliance with ICT risk management requirements. A large institution with €10 billion in annual revenue has average daily turnover of approximately €27 million — meaning daily penalties of up to €270,000 for an ongoing violation.

CTPP Penalties

For Critical Third-Party Providers, Article 55 of DORA gives the Lead Overseer authority to impose periodic penalty payments of up to 1% of average daily global turnover for each day of non-compliance, applicable for up to six months. Given that major cloud providers designated as CTPPs generate tens of billions in annual revenue, these penalties represent a significant deterrent even in percentage terms.

Individual Liability

DORA also introduces individual liability exposure for management body members. Where an infringement results from intentional misconduct or gross negligence by management body members, national authorities may impose personal fines. The maximum levels vary by member state, but the principle — that ICT risk management failures can result in personal consequences for board members — is a significant departure from prior practice in financial regulation.

These penalty structures underscore why Article 5's board-level accountability is so significant. Board members who cannot demonstrate active oversight of ICT risk are now personally exposed if a major failure occurs. The practical response is more frequent, more substantive board-level ICT risk reporting — and consequently, greater demand from boards for clear, accessible regulatory intelligence.

Simplified vs. Enhanced ICT Risk Framework

DORA recognizes that a single framework applied uniformly to a global systemically important bank and a small payment institution would be disproportionate. The regulation therefore distinguishes between the enhanced ICT risk management framework (the full Chapter II requirements) and a simplified framework under Article 16.

Who Qualifies for the Simplified Framework?

Article 16 of DORA allows competent authorities to designate certain financial entities as "small and non-interconnected" for DORA purposes, qualifying them for a simplified ICT risk management framework. The criteria for this designation include:

• Total assets below the thresholds specified in the relevant sectoral regulations (varying by entity type — e.g., below €5 billion total assets for credit institutions under CRR)
• No cross-border activity or limited cross-border activity
• No designation as systemically important under relevant sectoral frameworks
• No use of ICT third-party providers qualifying as CTPPs for critical functions

Entities qualifying for the simplified framework still must implement an ICT risk management framework, but with reduced documentation and governance requirements. A separate set of RTS — published alongside the main DORA RTS in January 2025 — specifies the simplified framework requirements.

Key Differences: Enhanced vs. Simplified

The main differences between the enhanced and simplified frameworks:

• Board training: Enhanced requires annual ICT risk training for management body members with records; simplified requires "adequate" ICT knowledge without specifying training frequency
• Asset register: Enhanced requires comprehensive asset register with full dependency mapping; simplified allows a more proportionate approach focused on critical assets only
• Testing: Enhanced requires digital operational resilience testing under Chapter IV (including TLPT for significant entities); simplified entities are generally exempt from advanced testing requirements
• Third-party risk: Enhanced requires full Article 28–30 third-party risk management; simplified requires a proportionate approach aligned with the scale and complexity of third-party arrangements
• Audit: Enhanced requires regular independent review of the ICT risk management framework; simplified allows internal review

The simplified framework is not a "light touch" exemption from DORA. It is a proportionate application of the same principles. Entities that initially qualify for simplified treatment should monitor their growth and cross-border expansion, as these factors can cause them to transition to the enhanced framework — requiring significant additional compliance work. For a broader overview of how AI is transforming compliance approaches, see our analysis on AI in compliance monitoring.

Automating DORA Compliance Monitoring

DORA is unusual among EU financial regulations in that its compliance obligation does not end at implementation. The regulation's emphasis on ongoing review, continuous monitoring, and regular updating of frameworks means that DORA compliance is inherently a live, ongoing activity — not a project with a completion date.

What Needs to Be Monitored

For a DORA-compliant entity, the regulatory monitoring workload includes:

• ESA publications: EBA, ESMA, and EIOPA continue to publish guidelines, Q&As, and supervisory guidance on DORA implementation. Any update to the RTS — even a clarification on a technical point — may require updates to internal policies and procedures
• CTPP register updates: New CTPP designations or changes to existing designations affect contractual obligations. Entities must monitor the Joint ESA Committee's CTPP register for changes
• National competent authority guidance: Each NCA in each member state may publish jurisdiction-specific DORA implementation guidance that goes beyond the ESA baseline. For a financial entity with branches in multiple EU member states, this means monitoring multiple NCA publication streams
• Enforcement decisions: As NCAs issue their first DORA enforcement decisions, these will clarify how the regulation is being interpreted in practice — often revealing compliance gaps that weren't apparent from the regulation text alone
• ICT incident taxonomy updates: DORA's incident classification thresholds may be revised as the ESAs gather data from the new reporting regime. Changes to classification thresholds affect which incidents require regulatory notification

The Case for Automated Monitoring

Manual monitoring of DORA regulatory developments is not scalable. EBA alone published over 200 documents in 2024 related to DORA implementation. ESMA and EIOPA added further volumes. At the NCA level, 27 member state regulators may each publish DORA-related guidance at any time.

Compliance teams that relied on manual monitoring during the DORA run-up report that tracking publications across all relevant sources required multiple full-time team members. For most financial entities, that resource allocation is unsustainable once DORA is in full application and operational teams are also consuming compliance capacity.

The practical solution is automated regulatory intelligence. RegPulse monitors EBA, ESMA, EIOPA, the European Commission, and all 27 EU NCAs for DORA-related publications in real time. When the Joint ESA Committee designates a new CTPP, when EBA publishes updated Q&As on ICT risk management, or when a national supervisor issues enforcement guidance, compliance teams receive the alert the same day — not after a weekly manual scan of 20+ regulatory websites.

For financial entities implementing DORA's ICT risk management framework, this kind of monitoring infrastructure is not a luxury. It is the mechanism by which the ongoing review obligations in Article 6(5) — "the ICT risk management framework shall be reviewed at least once a year" — can actually be met with current information, rather than a 12-month-old snapshot of the regulatory landscape.