ICT Risk Management Framework (DORA)

Example Conversation

Below is an example of how the agent guides a compliance officer through drafting the ICT risk management framework for a mid-size payment institution.

You: We need to create our DORA ICT risk management framework. We are a payment institution licensed in Germany, supervised by BaFin. We have about 120 employees and 8 ICT third-party providers, two of which support critical payment processing functions.

Agent: I will draft the full ICT risk management framework under DORA Articles 5-16. Based on your profile – a payment institution with 120 staff – you do not qualify for the simplified framework under Art. 16 (that applies only to microenterprises with fewer than 10 staff and turnover below EUR 2 million). You will need the complete framework including the digital operational resilience strategy.

Let me start with governance (Art. 5). Who currently approves your ICT policies, and do you have a dedicated CISO or ICT risk function?

You: Our CTO approves ICT policies. We have a CISO who reports to the CTO. The board has not been directly involved in ICT risk decisions so far.

Agent: Under DORA Art. 5(2), the management body (your board) must personally define, approve, and oversee the ICT risk management framework – this cannot be delegated to the CTO or CISO alone. I will draft the governance section to establish:

• Board approval of the framework and all Art. 9(4) policies
• Quarterly ICT risk reporting to the board (Art. 5(7))
• A mandatory ICT risk training program for board members (Art. 5(4))
• Clear segregation between the CISO (control), CTO (management), and internal audit

Now I will draft the ICT asset identification section. How many ICT systems support your critical payment processing functions?

You: We have about 35 systems in total, but 12 directly support payment processing, which we consider critical.

Agent: I have drafted the ICT asset inventory and classification section (Art. 8), covering all 35 systems with criticality tiers, dependency mapping for the 12 critical systems, and a configuration management register. I have also documented your two critical ICT third-party providers and flagged concentration risk given both support payment processing.

I will now move through protection (Art. 9), detection (Art. 10), response and recovery (Art. 11-12), and the remaining sections. Once the full draft is complete, I will run dora_ict_risk_completeness_checker to verify every article is covered.

Agent: The completeness check returned 0 errors and 2 warnings. The warnings are about your multi-vendor strategy (Art. 6(8)(e)) and physical security documentation (Art. 9(4)(e)). I recommend addressing both before supervisory review. The framework document is ready with all 13 sections plus a cross-reference matrix mapping each DORA article to the corresponding section.

Sample Output Excerpt

Below is a representative excerpt from the ICT risk management framework document, covering the governance section (Art. 5) and the beginning of the digital operational resilience strategy (Art. 6(8)).

1. Executive Summary and Scope

This ICT Risk Management Framework is established pursuant to Regulation (EU) 2022/2554 (DORA), Articles 5-16, and the supplementing Regulatory Technical Standards (RTS 2024/1774). It applies to [Entity Name], a payment institution authorized under Directive (EU) 2015/2366 and supervised by the Bundesanstalt fur Finanzdienstleistungsaufsicht (BaFin).

Proportionality assessment: The entity employs approximately 120 staff and has annual turnover exceeding EUR 2 million. It does not qualify as a microenterprise under Art. 16(1). The full ICT risk management framework under Articles 5-15 applies.

2. Governance and Management Body Responsibilities (Art. 5)

2.1 Ultimate accountability. The Management Board bears ultimate responsibility for the management of ICT risk (Art. 5(2)). This accountability is non-delegable.

2.2 Framework approval. The Management Board shall define and approve this ICT risk management framework, including all ICT security policies under Art. 9(4), at least annually. Approval is recorded in the Board minutes with individual signatures.

2.3 Oversight. The Management Board shall monitor the effective implementation of this framework through:

• Quarterly ICT risk reports presented by the CISO (Art. 5(7))
• Annual review of the digital operational resilience strategy (Art. 6(9))
• Approval of the ICT audit plan (Art. 5(6))

2.4 ICT budget. The Management Board shall determine the appropriate level of ICT budget, ensuring sufficient allocation for digital operational resilience, security awareness programs, and ICT skills development (Art. 5(2)(b)). The current approved annual ICT budget is EUR [amount], of which EUR [amount] is allocated to resilience and security.

2.5 Roles and responsibilities. ICT-related roles are segregated as follows (Art. 5(2)(c)):

2.6 Management body training. All Management Board members shall complete ICT risk training within 90 days of appointment and annually thereafter (Art. 5(4)). Training covers ICT threat landscape, DORA obligations, cyber incident scenarios, and ICT third-party risk.

3. Digital Operational Resilience Strategy (Art. 6(8))

3.1 ICT risk tolerance. The entity’s risk tolerance for ICT risk is set at [Low / Medium], approved by the Management Board (Art. 6(8)(a)). Maximum tolerable downtime for critical payment processing functions is 4 hours (RTO) with a recovery point objective of 1 hour (RPO).

3.2 ICT security objectives. (Art. 6(8)(b))

• Confidentiality: Payment data and customer PII are encrypted at rest (AES-256) and in transit (TLS 1.3).
• Integrity: All transaction records are protected by cryptographic checksums with tamper-evident audit trails.
• Availability: Critical payment processing systems maintain 99.95% uptime, measured monthly.

3.3 ICT third-party strategy. (Art. 6(8)(e)) The entity maintains contractual and operational exit strategies for each critical ICT third-party provider. Concentration risk is monitored quarterly; no single provider shall support more than two critical functions without documented risk acceptance by the Management Board.

Built-in Validation Tools

The skill includes an extension tool that validates framework completeness against all DORA Articles 5-16 requirements.

dora_ict_risk_completeness_checker

Reads a JSON representation of the ICT risk management framework and checks every mandatory and recommended element across ten regulatory areas.

If the simplified framework (Art. 16) is indicated as applicable, the checker skips the digital operational resilience strategy requirements (Art. 6(8)) and instead validates simplified-regime elements: a sound documented framework, a designated person for ICT risk monitoring, and simplified security requirements.

Finding severity levels

• ERROR – A mandatory DORA requirement is missing (e.g., no management body accountability, no asset inventory, no incident management process). Must be addressed before regulatory submission.
• WARNING – A recommended element is absent or incomplete (e.g., multi-vendor strategy not documented, physical security section missing). Should be addressed for a robust framework.

Example validation output

========================================================================
DORA ICT Risk Management Framework -- Completeness Check (Arts. 5-16)
========================================================================

--- Errors (must fix) ---
  [ERROR] Art. 5(4) -- Management body ICT risk training requirement
          not documented. Members must undertake specific training to
          understand and assess ICT risk.
  [ERROR] Art. 9(4)(b) -- Encryption policy (data at rest, data in
          transit, key management) not documented.

--- Warnings (recommended) ---
  [WARNING] Art. 6(8)(f) -- Digital operational resilience testing
            approach not documented.
  [WARNING] Art. 9(4)(e) -- Physical and environmental security of
            ICT systems not documented.

========================================================================

Run the checker after completing the framework draft to verify regulatory completeness, and again after addressing any findings.

Getting Started

Activate the ICT Risk Management Framework (DORA) skill and provide the agent with your entity profile. The agent will guide you through each article step by step.

Have this information ready:

• Entity type under DORA Art. 2(1): credit institution, payment institution, investment firm, insurer, etc.
• Proportionality tier: number of employees and annual turnover (to determine if the simplified framework under Art. 16 applies)
• Competent authority: ECB/SSM, national authority (BaFin, AMF, CONSOB, etc.), or sectoral supervisor
• ICT governance structure: who currently approves ICT policies, whether you have a dedicated CISO or ICT risk function
• ICT systems inventory: approximate number of ICT systems and which ones support critical or important functions
• ICT third-party providers: number of providers, which ones support critical functions, and any designated as critical under Art. 31

Optional but helpful:

• Existing ICT risk assessments, security policies, or business continuity plans you want the framework to build on
• Recent ICT incident reports or audit findings
• Your current digital operational resilience strategy (if any)

The skill produces a complete framework document with all sections required by Articles 5-16, a cross-reference matrix mapping each DORA article to the corresponding framework section, and appendix templates for the ICT asset register, risk assessment, business impact analysis, and policy approval records.