DORA ICT Risk Management Framework Template

DORA ICT Risk Management Framework: [Financial entity name]

The framework document that sets out how a financial entity governs, identifies, protects against, detects, responds to, recovers from and learns from ICT risk under Chapter II of the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA, Articles 5 to 16), with the policies, procedures and review report that Commission Delegated Regulation (EU) 2024/1774 (the RTS on the ICT risk management framework) specifies. It holds the digital operational resilience strategy, the ICT risk tolerance, the risk assessment method, the policy map, the yearly review and the traceability from each legal requirement to the document and evidence that meets it. DORA has applied since 17 January 2025; check the consolidated texts on EUR-Lex and your competent authority's expectations before use. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice; check the current official text and a qualified professional.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and legal basis
2. Governance and organisation
3. Digital operational resilience strategy
4. ICT risk tolerance and impact tolerances
5. ICT risk management policy and methodology
6. Identification of functions, assets and dependencies
7. Policy and procedure map
8. Detection, response and recovery
9. Learning, evolving and communication
10. ICT third-party risk link
11. Digital operational resilience testing
12. Internal audit and follow-up of findings
13. Framework review and review report
14. Traceability matrix
15. Glossary and references

1. Purpose, scope and legal basis

1.1 Purpose

This document establishes the ICT risk management framework of [Entity]. It describes how the entity keeps a high level of digital operational resilience: how ICT risk is governed, measured and kept within the tolerance the management body has set, and how the entity continues to deliver its critical or important functions when ICT systems fail or are attacked. It is part of the entity's overall risk management system and uses the same risk taxonomy, committees and reporting lines.

1.2 Legal basis

Delegated Regulation (EU) 2024/1774 was adopted on 13 March 2024 and published in the Official Journal on 25 June 2024. It applies from the DORA application date. Check the consolidated texts and any later amendments before relying on article numbers.

1.3 Full or simplified framework

Example: Corvellan Bank AG is a credit institution with about 1,400 staff. It is not in the Article 16(1) list and is not a microenterprise, so it applies the full framework.

1.4 Entities and perimeter

1.5 Other jurisdictions

Groups with operations outside the EU map this framework to local regimes rather than run parallel documents. Two common examples, named for orientation only: in the United Kingdom, the PRA's supervisory statement SS1/21 on operational resilience and impact tolerances for important business services, with the FCA's matching rules; in the United States, the interagency paper on sound practices to strengthen operational resilience (Federal Reserve SR 20-24, issued 2 November 2020 and revised 2 June 2026). Check each regulator's current text.

2. Governance and organisation

2.1 Management body responsibilities (Article 5(2))

Article 5(4) requires management body members to keep sufficient knowledge and skills to understand and assess ICT risk, including through regular, specific training. Record the training plan here: [training provider, topics, dates, attendance].

Article 5(3) requires entities other than microenterprises either to establish a role to monitor arrangements with ICT third-party service providers or to designate a senior manager for that exposure. Name the holder: [role, person].

2.2 Roles and responsibilities

R responsible, A accountable, C consulted, I informed.

2.3 Control function and lines of defence (Article 6(4))

The ICT risk control function sits in the risk management division and reports to the chief risk officer. It does not operate ICT systems and does not approve its own changes. Internal audit is separate from both the first and second lines. Describe the model in one paragraph and attach the organisation chart: [reference].

Independence test: [state how conflicts are avoided, for example the head of the function has direct access to the risk committee and cannot be dismissed without management body approval].

3. Digital operational resilience strategy

3.1 Strategy elements

3.2 Objectives and indicators

3.3 Multi-vendor strategy (optional, Article 6(9))

If the entity adopts a multi-vendor ICT strategy, state the key dependencies on ICT third-party service providers and the reasons for the mix of providers. Example: Corvellan Bank AG uses two cloud providers for customer-facing workloads so that the mobile app can run in either; the core banking platform stays with one provider and is covered by the exit plan in the register of information.

3.4 Current resilience position

4. ICT risk tolerance and impact tolerances

4.1 ICT risk tolerance statements

4.2 Impact tolerances for critical or important functions

The recovery time objective is shorter than the maximum tolerable disruption so that there is time to detect, decide and invoke before the tolerance is breached. Link each function to its business impact analysis in compliance/business-continuity.

5. ICT risk management policy and methodology

5.1 Policy content (RTS Article 3(1))

RTS Article 3(2) adds that the treatment procedure monitors the effectiveness of measures, checks whether tolerance levels have been reached, and checks whether corrective or improving actions were taken where needed. Section 5.3 covers these three checks.

5.2 Assessment method

Likelihood and impact are each rated from 1 to 5. The risk score is likelihood multiplied by impact (range 1 to 25). Bands: 1 to 9 within tolerance, 10 to 14 elevated (treat, or accept at management body level under TOL-01), 15 to 25 outside tolerance (treat as a priority).

Example thresholds above are illustrative; calibrate them to the entity's risk appetite and the group risk taxonomy in compliance/risk-methodology.

5.3 Risk assessment and treatment extract

For each treatment, record the three RTS Article 3(2) checks: is the measure effective (test result), is the risk now within tolerance (residual score), and were further actions taken where needed.

5.4 Accepted residual risk inventory (RTS Article 3(1)(d))

At each yearly review, confirm for each accepted risk: what has changed, which new mitigations are available, and whether the reasons for acceptance still hold.

5.5 Threat and vulnerability monitoring

6. Identification of functions, assets and dependencies

6.1 What is identified

Under DORA Article 8, the entity identifies, classifies and documents its ICT-supported business functions, roles and responsibilities, the information assets and ICT assets that support them, and their roles and dependencies with respect to ICT risk. It reviews this at least yearly. It identifies all sources of ICT risk, including exposure to and from other financial entities, and assesses the cyber threats and vulnerabilities relevant to its functions and assets. It performs a risk assessment on each major change in network and information system infrastructure and in processes or procedures (Article 8(3)). It runs a specific ICT risk assessment on all legacy ICT systems at least yearly and before and after connecting new technologies, applications or systems (Article 8(7)). Both duties apply to entities other than microenterprises.

6.2 Asset management policy and procedure (RTS Articles 4 and 5)

6.3 Function to asset mapping extract

Keep this mapping consistent with function identifiers in the register of information (compliance/dora-ict-third-party-register, template B_06.01).

7. Policy and procedure map

7.1 General elements of ICT security policies (RTS Article 2)

Each ICT security policy, procedure, protocol and tool listed below must show: approval by the management body or delegated authority, alignment with the entity's information security objectives, roles and responsibilities, the measures that apply to staff and providers, the exception process, and the review cycle. Check that every row in 7.2 meets these elements before the yearly review.

7.2 Map

7.3 Exceptions

8. Detection, response and recovery

8.1 Detection (DORA Article 10, RTS Article 23)

The entity has mechanisms to detect anomalous activities promptly, including network performance issues and ICT-related incidents, with several layers of control, alert thresholds and criteria that trigger incident response. Describe: monitoring coverage (which systems, which logs), the alert thresholds, the criteria used to escalate an anomaly to an incident, and the link to incident classification under Delegated Regulation (EU) 2024/1772.

8.2 Response and recovery (DORA Articles 11 and 12, RTS Articles 24 to 26)

9. Learning, evolving and communication

9.1 Learning and evolving (DORA Article 13)

Senior ICT staff report the lessons learned, with recommendations, to the management body at least yearly (DORA Article 13(5)). ICT security awareness and digital operational resilience training are compulsory modules for all staff and senior management (Article 13(6)).

9.2 Communication (DORA Article 14)

10. ICT third-party risk link

Third-party risks appear in the ICT risk register with the provider identifier from the register of information so that both views stay reconciled.

11. Digital operational resilience testing

11.1 Testing programme

The DORA Article 25 list of test types includes vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Choose a risk-based mix and explain omissions.

11.2 Independence of testers

Record whether each test is internal or external and how independence is assured (DORA Article 24(4) and, for TLPT, Article 27). [Describe.]

12. Internal audit and follow-up of findings

12.1 Audit coverage

12.2 Findings follow-up

Critical ICT audit findings are verified and remediated on a timeline set in the audit follow-up procedure: [state rule, for example remediation plan within 30 days and closure verified by internal audit].

12.3 Outsourced verification (Article 6(10))

If compliance verification is outsourced to an intra-group or external undertaking, name it, the scope and the contract reference. The entity remains fully responsible.

13. Framework review and review report

13.1 Review triggers and cycle

13.2 Review report outline (RTS Article 27(2))

13.3 Worked summary (Example)

Review period 2025-10-01 to 2026-09-30, yearly cycle plus one unscheduled review after INC-2026-007 (card authorisation outage of 2 hours 40 minutes, against a 2-hour tolerance). Findings: 7 (2 high, 3 medium, 2 low). Measures: 5 completed, 2 in progress, none overdue. Residual risks above tolerance: 1 accepted (ICT-R-003, score 12). Control effectiveness: 46 of 50 controls tested effective (92%).

14. Traceability matrix

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Based on Regulation (EU) 2022/2554 (DORA) and Commission Delegated Regulations (EU) 2024/1774 and (EU) 2024/1772, as published in the Official Journal of the European Union, with UK and US operational resilience texts named for orientation only. EU legislative texts are free to reuse. Article and point numbers are cited and requirements are summarised in original wording; no legal text is reproduced. Official text: EUR-Lex, https://eur-lex.europa.eu/eli/reg/2022/2554/oj and https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj. Check the consolidated texts and your competent authority's guidance before use. All organisations, figures and identifiers in the examples are fictional. This is a documentation format, not legal advice. Template licence: MIT.