DORA ICT Risk Management: Requirements and Implementation Guide for Financial Institutions

DORA’s ICT risk management framework (Articles 5–16) is the foundation upon which all other DORA requirements are built. Incident reporting, resilience testing, and third-party risk management all depend on a robust ICT risk management framework being in place first. For financial institutions, this is not new territory — MaRisk, BAIT, and EBA guidelines already imposed ICT risk management requirements — but DORA raises the bar with specificity, mandatory governance structures, and binding Regulatory Technical Standards (RTS).

This guide breaks down every component of the DORA ICT risk management framework: governance requirements, the framework structure, ICT systems management, detection mechanisms, business continuity, and the learning loop. For each component, we explain what DORA requires, how it differs from existing regulation, and what financial institutions must do to comply.

Governance: The Management Body’s Responsibility (Article 5)

DORA places ICT risk management squarely on the management body’s agenda. This is not delegation — it is personal accountability. The management body must: define and approve the ICT risk management strategy, allocate sufficient budget and resources for ICT resilience, approve the digital operational resilience strategy, review ICT risk reports regularly, and ensure adequate ICT knowledge and training at the board level.

The critical difference from MaRisk: DORA introduces explicit personal liability for management body members who fail to fulfill their ICT risk oversight obligations. This elevates ICT risk from an IT topic to a board-level governance responsibility with legal consequences. Financial institutions should ensure that board-level ICT risk reporting is structured, regular (at minimum quarterly), and covers the full scope of DORA requirements.

The ICT Risk Management Framework (Article 6)

Article 6 requires a comprehensive, documented ICT risk management framework that covers the entire ICT lifecycle. The framework must include:

• Identification: Complete inventory of ICT-supported business functions, information assets, and ICT assets. Classification by criticality. Mapping of dependencies between business functions and ICT systems.
• Protection and prevention: Security policies, access controls, encryption, patch management, network security, and physical security measures proportionate to the identified risks.
• Detection: Continuous monitoring mechanisms to detect anomalous activity, security events, and ICT-related incidents in a timely manner.
• Response and recovery: Incident response procedures, business continuity plans, disaster recovery capabilities, and crisis communication procedures.
• Learning and evolving: Post-incident reviews, lessons learned integration, continuous improvement of the framework based on testing results and incident experience.

The RTS published by the ESAs (EBA, ESMA, EIOPA) provide detailed specifications for each component. Financial institutions must map their existing ICT risk management documentation against the RTS requirements and close identified gaps.

ICT Systems, Protocols, and Tools (Articles 7–9)

ICT Asset Management (Article 7)

Financial entities must maintain a documented inventory of all ICT assets, including hardware, software, network components, and data assets. The inventory must be classified by criticality and linked to the business functions each asset supports. This goes beyond a simple CMDB — DORA requires understanding which business functions depend on which ICT assets and what the impact of asset failure would be.

Encryption and Cryptographic Controls (Article 8)

Data at rest and in transit must be protected with appropriate encryption. Cryptographic key management must be documented. The framework must define which data categories require encryption, the encryption standards to be used, and the key lifecycle management process. Financial institutions should review their encryption posture against the RTS specifications, paying particular attention to legacy systems that may use outdated cryptographic standards.

ICT Change Management (Article 9)

All changes to ICT systems must follow a documented change management process including: risk assessment before changes, testing in non-production environments, rollback procedures, and post-implementation review. Emergency changes must also be documented, even if retrospectively. The change management process must be auditable and cover all ICT systems supporting critical business functions.

Detection (Article 10)

DORA requires financial entities to implement mechanisms for the prompt detection of anomalous activities. Detection capabilities must include: multiple layers of controls (network, endpoint, application), continuous monitoring of ICT operations, automated alerting for security events, and regular testing of detection capabilities. The emphasis on layered detection means that no single point of detection failure should leave the organization blind to threats.

For organizations with existing SIEM or XDR deployments, the key gap is often documentation: DORA requires that detection policies, procedures, and response plans are formally documented and regularly reviewed, not just that detection technology is deployed.

ICT Business Continuity Management (Articles 11–12)

DORA elevates ICT business continuity from a best practice to a detailed regulatory requirement:

Business Impact Analysis (Article 11)

Financial entities must conduct BIAs for all ICT-supported critical and important functions. The BIA must cover: impact assessment for severe disruption scenarios, recovery time objectives (RTO) and recovery point objectives (RPO), ICT dependencies (internal and third-party), and impact tolerances defining the maximum acceptable disruption.

ICT Continuity Plans (Article 11)

Based on BIA findings, financial entities must maintain ICT continuity plans that: define response and recovery procedures for ICT disruptions, specify roles, responsibilities, and escalation paths, include communication procedures for internal and external stakeholders, and are regularly tested (at minimum annually). Plans must cover a range of scenarios, not just the most likely disruptions. DORA explicitly requires consideration of switchover to alternative ICT systems and the transition from normal to crisis operations.

Testing (Article 12)

ICT continuity plans must be tested at least annually. Testing must cover: the adequacy of recovery procedures, the ability to meet defined RTOs and RPOs, the effectiveness of communication procedures, and staff readiness and competence. Test results must be documented, and identified weaknesses must be addressed through corrective action plans with defined timelines.

Learning and Evolving (Articles 13–16)

DORA creates a continuous improvement loop. Post-incident reviews must identify root causes and improvement opportunities. ICT risk management framework effectiveness must be assessed annually. Lessons from testing, incidents, and threat intelligence must feed back into framework improvements. ICT staff must receive regular training on emerging threats and updated procedures.

How DORA ICT Risk Management Relates to MaRisk/BAIT

DORA supersedes the ICT-related aspects of national regulation (BAIT, VAIT, KAIT, ZAIT) for entities within its scope. However, MaRisk remains relevant for broader governance requirements not covered by DORA. In practice, organizations with mature BAIT implementations have a strong foundation — DORA adds specificity around: mandatory management body involvement (not just IT oversight), detailed RTS requirements for each framework component, explicit resilience testing requirements (including TLPT for significant institutions), and structured ICT third-party risk management (Articles 28–44, covered separately).

Implementation Roadmap

1. Month 1–2: Map existing ICT risk management documentation against DORA Articles 5–16 and the published RTS. Identify gaps.
2. Month 2–4: Update governance structures. Ensure management body ICT risk oversight is documented, regular, and comprehensive. Establish or update board-level ICT risk reporting.
3. Month 4–6: Complete ICT asset inventory with business function mapping and criticality classification. Update encryption and change management documentation.
4. Month 6–9: Conduct or update BIA for all ICT-supported critical functions. Develop or update ICT continuity plans with defined RTOs and RPOs.
5. Month 9–12: Implement or enhance detection capabilities with documented policies. Conduct ICT continuity testing. Document the learning loop and continuous improvement process.

Frequently Asked Questions

How does DORA differ from BAIT for German financial institutions?

DORA is an EU regulation (directly applicable) while BAIT was a German national supervisory circular. DORA supersedes BAIT’s ICT provisions for in-scope entities. Key differences: DORA mandates management body personal liability for ICT risk oversight, provides more detailed RTS requirements, introduces mandatory resilience testing (TLPT), and creates a pan-European ICT third-party oversight framework. Institutions with mature BAIT implementations have a ~70% head start on DORA compliance.

What are the DORA Regulatory Technical Standards (RTS)?

RTS are detailed technical specifications published by the European Supervisory Authorities (EBA, ESMA, EIOPA) that define how DORA requirements must be implemented. Key RTS cover: ICT risk management framework content and structure, ICT incident classification and reporting, TLPT methodology, critical ICT third-party provider oversight, and information sharing arrangements. RTS are legally binding and provide the level of detail that DORA Articles themselves do not.

Is there a DORA certification?

No. Unlike ISO 27001, DORA does not have a certification scheme. Compliance is assessed by competent authorities (BaFin, ECB, national regulators) through supervisory activities including on-site inspections, questionnaires, and thematic reviews. Having ISO 27001 certification supports DORA compliance evidence but is not a substitute for DORA-specific documentation and processes.

Does DORA apply to all financial institutions?

DORA applies to virtually all EU-regulated financial entities: credit institutions, investment firms, insurance companies, payment institutions, fund managers, crypto-asset service providers, and their critical ICT service providers. The only exception is a simplified framework for microenterprises (fewer than 10 employees and under EUR 2 million turnover). The simplified framework retains core requirements but with proportionate documentation and governance obligations.

What is the penalty for DORA non-compliance?

DORA empowers competent authorities to impose administrative penalties and remedial measures, including fines, public statements, and operational restrictions. Specific penalty levels are defined by national law (in Germany, through the Finanzmarktdigitalisierungsgesetz). DORA also introduces management body liability — individual executives can be held personally responsible for ICT risk management failures.