Learn
DORA Articles 5 through 16 mandate a comprehensive ICT risk management framework for every financial entity in the EU. The European Banking Authority’s final Regulatory Technical Standards - developed jointly with ESMA and EIOPA under the ESA umbrella - specify exactly what this framework must contain. But the gap between “you need an ICT risk management framework” and “here is how to actually write one that will survive supervisory scrutiny” remains massive.
Most organisations produce a framework that restates the regulation without operationalising it - a policy that reads like a DORA paraphrase rather than a governance instrument. Supervisors see through this immediately.
This guide walks you through building an ICT risk management framework that meets both the Level 1 text (the regulation) and the Level 2 requirements (the EBA RTS, Commission Delegated Regulation (EU) 2024/1774). We cover structure, supervisory focus areas, common deficiencies, and how to connect governance to operational reality.
📜
Section 1
What the Framework Must Cover
DORA Chapter II (Articles 5-16) establishes seven mandatory pillars for ICT risk management. Your framework document must address every one of them - not as a theoretical exercise, but with concrete policies, responsibilities, and operational procedures. Here is what each article demands:
Governance & Organisation (Art. 5-6)
The management body must define, approve, oversee, and be accountable for the ICT risk management framework. This includes setting risk tolerance, allocating adequate budget, and designating a control function responsible for ICT risk management.
ICT Risk Identification (Art. 8)
Identify, classify, and document all ICT-supported business functions, information assets, ICT assets and their interdependencies. Maintain a comprehensive inventory and map critical dependencies on third-party ICT service providers.
Protection & Prevention (Art. 9)
Implement policies, procedures, and technical controls to ensure the security, integrity, and resilience of ICT systems. Covers access control, encryption, network security, patch management, and vulnerability remediation.
Detection (Art. 10)
Establish mechanisms to promptly detect anomalous activities, including ICT-related incidents. Deploy monitoring and logging across all network layers, with defined alert thresholds and escalation procedures.
Response & Recovery (Art. 11)
Establish ICT business continuity and disaster recovery plans covering all critical functions. Define RPOs, RTOs, and switchover procedures. Test recovery plans at least annually and after significant ICT environment changes.
Learning & Evolving (Art. 13)
Gather and analyse information on vulnerabilities, cyber threats, and ICT-related incidents (including from third-party providers). Conduct post-incident reviews. Feed lessons learned back into risk assessment and the framework itself.
Communication (Art. 14)
Establish internal and external communication policies for ICT-related incidents and vulnerabilities, including defined roles for public disclosure, crisis communication plans, and procedures for notifying supervisory authorities within the mandated reporting windows.
“Financial entities shall have in place an internal governance and control framework that ensures an effective and prudent management of ICT risk, in order to achieve a high level of digital operational resilience.” - DORA Article 5(1)
Do not treat these as independent chapters. Your framework must demonstrate how they connect: risks under Article 8 drive protections under Article 9, detection under Article 10 feeds response under Article 11, and the entire cycle reports to the management body under Article 5. The ESA RTS explicitly requires this linkage.
⚖️
Section 2
The EBA RTS Requirements: What Goes Beyond DORA Itself
DORA sets the principles. The EBA RTS (finalised as Delegated Regulation (EU) 2024/1774, building on joint ESA draft JC/2023/86) specifies the operational detail. A framework that only addresses the regulation text without incorporating RTS requirements is incomplete. Here is what the RTS adds:
| RTS Domain | Key Requirements Your Framework Must Address | DORA Articles |
|---|---|---|
| Network security management | Network segmentation policy, firewall rules review cadence, intrusion detection/prevention, network architecture documentation, secure remote access procedures, DMZ configuration requirements | Art. 9(2), 9(4)(d) |
| Encryption & cryptography | Cryptographic policy specifying algorithms, key lengths, key lifecycle management, data-at-rest and data-in-transit encryption standards, certificate management, crypto-agility for post-quantum readiness | Art. 9(2), 9(4)(b) |
| ICT operations security | Procedures for capacity management, software lifecycle management, logging and monitoring policies, backup and restoration (including air-gapped/immutable backups), malware protection, data leakage prevention | Art. 9(1), 9(4)(a) |
| ICT project & change management | Formal change management process with risk-based approval workflows, segregation of development/test/production environments, ICT project governance including security-by-design requirements and testing gates | Art. 8(5), 9(4)(e) |
| Physical & environmental security | Physical access controls for data centres and critical infrastructure, environmental controls (fire, flood, power), clean desk policies, equipment disposal and media sanitisation procedures | Art. 9(4)(c) |
| Human resources security | Security awareness training programme (with DORA-specific modules), role-based access provisioning, pre-employment screening for critical ICT roles, security responsibilities in employment contracts, offboarding access revocation | Art. 13(6) |
| Identity & access management | Least-privilege access model, privileged access management (PAM), multi-factor authentication for critical systems, access certification reviews (minimum annual), service account governance, identity lifecycle management | Art. 9(4)(c) |
| ICT business continuity | Business impact analysis for ICT-supported functions, recovery plans per critical function with RPO/RTO targets, crisis management governance, communication plans during disruptions, annual testing (including scenario-based), third-party continuity requirements | Art. 11, 12 |
Why the RTS Matters for Your Framework Document
Many organisations write their ICT risk management framework referencing only the DORA regulation text. When supervisors assess your framework, they assess it against the RTS requirements. A framework that addresses DORA Articles 5-16 but ignores the RTS specifications on network segmentation, cryptographic policy, or change management will receive deficiency findings - even though the regulation text is less prescriptive on these topics. The RTS is where the operational detail lives.
📋
Section 3
Framework Document Structure Template
This ten-chapter structure maps to both the DORA regulation and the EBA RTS. It is a structural blueprint ensuring every supervisory requirement has a home in your document. Adapt sub-sections to your organisation’s size, complexity, and risk profile.
Chapter 1
Governance and Responsibilities
Maps to: DORA Art. 5(1)-5(4), Art. 6(1)-6(8) | RTS Art. 1-2
- Management body responsibilities (approval, oversight, accountability)
- ICT risk management function - mandate, reporting lines, independence
- ICT risk appetite statement and tolerance thresholds
- Budget allocation and framework review cycle (minimum annual, per Art. 6(5))
Chapter 2
ICT Asset Management and Classification
Maps to: DORA Art. 8(1)-8(4) | RTS Art. 3-4
- ICT asset inventory (hardware, software, data, network components)
- Information asset classification scheme (confidentiality, integrity, availability)
- Business function mapping, criticality assessment, and dependency mapping
- Inventory update triggers and review frequency
Chapter 3
Risk Identification and Assessment Methodology
Maps to: DORA Art. 8(5)-8(7) | RTS Art. 5-7
- Risk identification process (threat modelling, vulnerability identification)
- Risk assessment methodology (likelihood, impact, scoring matrix)
- Risk treatment options with approval authorities
- ICT risk register and annual/event-driven reassessment cycle
Chapter 4
Protection and Prevention Controls
Maps to: DORA Art. 9 | RTS Art. 8-17
- Network security - segmentation, firewalls, IDS/IPS, DMZ architecture
- Encryption and cryptographic controls - algorithms, key management
- Identity and access management - least privilege, PAM, MFA, access reviews
- ICT operations security - capacity management, logging, malware protection
- Change management - approval workflows, environment segregation, rollback
- Physical security, patch management SLAs, and data leakage prevention
Chapter 5
Detection and Monitoring
Maps to: DORA Art. 10 | RTS Art. 18-20
- Anomaly detection capabilities and alert thresholds
- SIEM requirements, log retention, and tamper-protection
- Network traffic monitoring and baseline analysis
- Escalation procedures and cross-system event correlation
Chapter 6
Response and Recovery
Maps to: DORA Art. 11-12 | RTS Art. 21-26
- Incident response plan with roles, escalation paths, communication protocols
- BCP/DR plans with RPO/RTO targets per critical function
- Business impact analysis methodology and crisis management governance
- Switchover/failback procedures and annual testing requirements
Chapter 7
Testing Programme
Maps to: DORA Art. 24-27 | RTS on TLPT
- Resilience testing programme (scope, frequency, governance)
- Vulnerability assessments, penetration testing, and TLPT (Art. 26 entities)
- Findings tracking, remediation, and verification procedures
- Integration of testing results into the risk assessment cycle
Chapter 8
Third-Party Risk Integration
Maps to: DORA Art. 28-30 | RTS on ICT third-party risk
- Third-party risk policy - due diligence, monitoring, exit strategies
- Concentration risk assessment and contractual requirements (Art. 30)
- Sub-outsourcing visibility and Register of Information maintenance (Art. 28(3))
- Linkage between third-party risks and the overall ICT risk register
Chapter 9
Reporting and Communication
Maps to: DORA Art. 14, Art. 19 | RTS Art. 27-28
- Management body reporting (frequency, content, escalation triggers)
- NCA incident reporting timelines - initial (4h), intermediate (72h), final (1 month)
- Internal and external communication protocols for ICT crises
Chapter 10
Continuous Improvement
Maps to: DORA Art. 13 | RTS Art. 29-30
- Post-incident review and lessons-learned methodology
- Threat intelligence integration and annual framework review triggers
- Training and awareness programme (role-based modules)
- KRIs, KPIs, maturity assessment, and improvement roadmap
Proportionality Principle
DORA Article 4 allows financial entities to apply the ICT risk management framework proportionately, based on their size, nature, scale, and complexity of services and activities. This does not mean smaller entities can skip chapters - it means the depth and sophistication of controls can be calibrated. Your framework must explicitly state how proportionality is applied across each chapter and document the rationale.
🔎
Section 4
Key Sections That Supervisors Scrutinise Most
Based on early supervisory assessment patterns since DORA entered into application on 17 January 2025, certain areas consistently attract the most attention. If you have limited time, prioritise getting these right:
1. Management Body Accountability
Supervisors want evidence that the board is not just approving the framework as a rubber-stamp exercise. They look for: documented board discussions on ICT risk, evidence of challenge from non-executive directors, explicit allocation of ICT security budget by the board, and whether the CISO/CIO has a direct reporting line to the management body.
2. ICT Asset Inventory Completeness
The most common first question in assessments: “Show us your ICT asset inventory.” Supervisors check whether the inventory is genuinely complete (including shadow IT, cloud services, SaaS applications), whether dependencies are mapped, and whether criticality classifications are defensible rather than arbitrary.
3. Third-Party Concentration Risk
With the CTPP oversight framework now in force, supervisors are particularly interested in how entities assess concentration risk across their ICT service provider portfolio. They want quantified concentration metrics, not just qualitative statements. They also check for viable exit strategies and whether substitutability has been genuinely assessed.
4. BCP/DR Testing Evidence
Not just whether tests were conducted, but whether test scenarios were realistic, whether critical staff participated, whether third-party providers were included, and - critically - whether deficiencies found during testing were actually remediated. Test reports that consistently show “all green” are treated with suspicion.
5. Incident Response Readiness
The 4-hour initial notification window under DORA Article 19 means supervisors probe whether organisations can realistically detect, classify, and report an ICT-related incident within that timeframe. They look for tabletop exercises, automated classification mechanisms, and pre-drafted notification templates.
6. Risk-Control Linkage
Supervisors want to trace from an identified ICT risk, through the control that mitigates it, to the testing that validates the control’s effectiveness, and back to the risk assessment update. If your framework describes risks in Chapter 3 and controls in Chapter 4 but there is no documented linkage between them, that is a deficiency.
“The management body of the financial entity shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework.” - DORA Article 5(2). Supervisors interpret “oversee” as an active, ongoing obligation - not a once-a-year board presentation.
⚠️
Section 5
Common Framework Deficiencies
These deficiencies appear most frequently across European financial institutions. Use this table as a quality checklist before board approval:
| Deficiency | What’s Missing | How to Fix It |
|---|---|---|
| Regulation parroting | Framework restates DORA articles without operationalising them. Reads like a regulatory summary, not a governance document. | For each requirement, specify: who is responsible, what the process is, how often it occurs, and what evidence it produces. |
| Missing RTS detail | Framework addresses DORA Level 1 text but ignores RTS requirements on network security, cryptography, and change management. | Cross-reference your framework against the full RTS article list. Each RTS article should map to a specific section and control in your framework. |
| No proportionality rationale | Entity claims proportionality to justify lighter controls but provides no documented rationale for why certain requirements are scaled down. | Include a proportionality assessment in Chapter 1 that maps entity characteristics (size, interconnectedness, criticality) to control calibration decisions. |
| Governance vacuum | Framework assigns responsibilities to “the organisation” or “IT” without naming specific roles, committees, or escalation paths. | Use a RACI matrix. Every activity in the framework should have a named Responsible, Accountable, Consulted, and Informed party. The management body must be explicitly named where DORA requires it. |
| Disconnected third-party risk | Third-party ICT risk is treated as a separate policy without linkage to the overall ICT risk management framework. | Chapter 8 should cross-reference the risk register in Chapter 3, the protection controls in Chapter 4, and the BCP in Chapter 6. Third-party risks must feed into the same risk assessment methodology. |
| Static document | Framework was written once and never updated. No version history, no evidence of annual review, no trigger-based update mechanism. | Include a version control table, define annual and event-driven review triggers, and document the approval workflow. Art. 6(5) requires review at least annually and after major ICT incidents. |
| No testing linkage | Framework describes a testing programme but there is no feedback loop from testing results to risk assessment updates and control improvements. | Chapter 7 should define how testing findings are logged, prioritised, remediated, and verified - and how they trigger updates to risk assessments in Chapter 3 and controls in Chapter 4. |
| Inadequate KRIs | Framework mentions monitoring but defines no Key Risk Indicators, thresholds, or escalation triggers for reporting to the management body. | Define 10-15 ICT KRIs with amber/red thresholds and automatic escalation rules. Examples: patch compliance rate, mean time to detect, privileged access anomalies, third-party SLA breaches. |
The Single Biggest Mistake
The most damaging deficiency is not a missing section - it is the absence of operational evidence. A perfectly structured framework means nothing if the organisation cannot produce evidence that it is being followed. For every policy statement in your framework, ask: “What artefact proves this is happening?” If the answer is “nothing,” either change the policy to reflect reality or implement the process before the document goes to the board.
🏛️
Section 6
Board Approval and Governance Requirements
DORA Article 5(2) is unambiguous: the management body must define, approve, oversee, and be responsible for the implementation of all arrangements related to the ICT risk management framework. This is not delegable. The board can delegate execution, but accountability stays at the top. Here is what that means in practice:
Management Body Obligations Under DORA
Approval Duties
- Approve the ICT risk management framework (Art. 5(2)(a))
- Approve the digital operational resilience strategy (Art. 6(8))
- Approve the ICT business continuity policy (Art. 11(1))
- Approve ICT third-party risk policy (Art. 28(2))
- Set and approve ICT risk tolerance levels (Art. 6(8)(b))
- Approve the internal audit plan covering ICT risk (Art. 6(6))
Oversight Duties
- Ensure adequate ICT budget allocation (Art. 5(2)(b))
- Review at least annually the ICT risk management framework (Art. 6(5))
- Receive and act upon reports on ICT-related incidents (Art. 5(2)(e))
- Ensure staff maintain adequate ICT skills through training (Art. 13(6))
- Monitor arrangements with ICT third-party providers (Art. 5(2)(d))
- Undergo specific training on ICT risks (Art. 5(4))
Article 5(4) is critical: management body members must “actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk.” Board members need documented, tracked ICT risk training. The absence of board-level ICT training is a frequently cited supervisory finding.
Practical tip: Include a “Board Governance Calendar” as an appendix to your framework. This should list every board deliverable required by DORA (framework review, risk tolerance setting, budget approval, training completion, incident report review) with target dates and responsible parties. It transforms abstract obligations into a concrete schedule your company secretary can track.
Include a front page with a formal approval block: date, version, approving members’ signatures, and next review date. Supervisors use this to verify governance compliance on the first page.
🔗
Section 7
Connecting the Framework to Operational Reality
Your ICT risk management framework should function as the apex document in a policy hierarchy, with clear downward linkages to operational procedures and upward linkages to board reporting.
Recommended Document Hierarchy
Level 1: ICT Risk Management Framework
Board-approved · Strategic · Reviewed annually · DORA Art. 5-16 + RTS
Level 2: Policies
Information Security Policy, BCP Policy, Access Control Policy, Third-Party Policy
Level 3: Standards
Encryption Standard, Patch Management Standard, Logging Standard, Network Segmentation Standard
Level 4: Procedures
Incident Response Runbook, DR Switchover Procedure, Access Certification Process, Vulnerability Scan Procedure
Each chapter should reference subordinate documents that implement its requirements. The framework sets the “what” and “why”; subordinate documents detail the “how.” Supervisors trace from framework requirement to operational procedure - and check whether it is followed.
Include a “Framework Mapping Matrix” as an appendix - a table mapping each chapter to subordinate documents, owners, and review cycles. It demonstrates completeness to supervisors and functions as a management tool:
| Framework Chapter | Subordinate Documents | Owner | Review Cycle |
|---|---|---|---|
| Ch. 4 - Protection Controls | Information Security Policy, Encryption Standard, Patch Management Standard, Access Control Policy | CISO | Annual |
| Ch. 6 - Response & Recovery | BCP Policy, DR Plans (per critical function), Incident Response Runbook, Crisis Comms Plan | Head of IT Operations | Annual + post-incident |
| Ch. 8 - Third-Party Risk | ICT Third-Party Policy, Vendor Due Diligence Checklist, Exit Strategy Template, RoI Maintenance Procedure | Head of Procurement / CRO | Annual + on contract renewal |
⚡
Section 8
How Venvera Helps Build Your Framework
Building a DORA ICT risk management framework from scratch takes months. Venvera was purpose-built for this problem - not a generic GRC tool, but a DORA compliance platform that understands ESA RTS requirements natively.
Policy Template Library
Pre-built policy templates mapped to every DORA article and RTS requirement. Not generic templates - each is structured to address the specific supervisory expectations for that domain, with built-in proportionality guidance.
Gap Assessment Engine
Systematic gap assessment against DORA Chapter II and the RTS. Identifies which requirements your current framework covers, which are partially addressed, and which are missing entirely - with prioritised remediation guidance.
Control-to-Risk Mapping
Automated linkage between identified ICT risks, the controls that mitigate them, and the testing that validates control effectiveness. The risk-control traceability that supervisors demand, built into the platform rather than maintained in spreadsheets.
Register of Information
Full Article 28 RoI module with ICT providers, contractual arrangements, business functions, and sub-outsourcing chains. ESA-format XBRL and CSV export for regulatory submissions - ready when your NCA asks.
Incident Classification & Reporting
DORA Article 18 severity classification with automated NCA reporting timeline tracking: 4-hour initial notification, 72-hour intermediate report, one-month final report. Pre-built notification templates aligned to supervisory expectations.
Board Reporting Dashboard
Executive-level dashboards showing ICT risk posture, open findings, testing programme status, third-party risk overview, and compliance gaps - designed for the management body reporting cadence that DORA Article 5 requires.
Resilience Testing Tracker
Full testing programme lifecycle: vulnerability assessments, penetration tests, scenario-based resilience tests, and TLPT. Track findings, assign remediation owners, verify fixes, and feed results back into risk assessments automatically.
Multi-Framework Coverage
DORA does not exist in isolation. Your ICT risk management framework intersects with ISO 27001, GDPR, NIS2, and potentially SOC 2 and the EU AI Act. Venvera maps controls across frameworks simultaneously, eliminating duplicate effort.
From Document to Living System
The real value is not in writing the framework - it is in making it operational. Venvera transforms your ICT risk management framework from a static PDF into a living system where risks are tracked, controls are monitored, incidents are classified, and the management body receives structured reporting. When your NCA asks to see your framework in action, you show them a platform, not a binder.
Regulatory References
- Regulation (EU) 2022/2554 (DORA) - Articles 5-16 (ICT Risk Management), Articles 17-23 (Incident Reporting), Articles 24-27 (Resilience Testing), Articles 28-44 (Third-Party Risk)
- Commission Delegated Regulation (EU) 2024/1774 - RTS on ICT risk management framework, specifying detailed requirements under DORA Articles 15 and 16(3)
- JC/2023/86 - Joint ESA Consultation Paper on draft RTS on ICT risk management framework and simplified ICT risk management framework
- EBA/RTS/2024/01 - Final Report on draft RTS on ICT risk management tools, methods, processes, and policies
- DORA Application Date: 17 January 2025 - all requirements are now in force and subject to supervisory assessment
This article is for informational purposes only and does not constitute legal or regulatory advice. Financial entities should consult with qualified legal and compliance professionals when developing their ICT risk management frameworks. Published March 2026.
