How to build a DORA ICT risk management framework using AI

Overview

You'll learn how to build a comprehensive ICT risk management framework that satisfies DORA Articles 6-16 using AI. This guide covers the complete framework structure, from governance and risk identification through protection, detection, response, recovery, and continuous improvement, with specific ISMS Copilot prompts for generating each component.

Who this is for

This guide is for:

• CISOs and IT risk managers building or enhancing ICT risk management frameworks for DORA compliance

• Compliance officers responsible for documenting ICT risk management policies and procedures

• Consultants developing DORA-compliant frameworks for financial entity clients

• Risk committee members and management body members overseeing ICT risk governance

• Internal auditors assessing the adequacy of ICT risk management arrangements

Before you begin

You will need:

• An ISMS Copilot account (free trial available)

• Completion of the foundational steps in How to get started with DORA implementation using AI, including scope assessment and gap analysis

• Your existing ICT risk management documentation (policies, risk registers, asset inventories) for gap comparison

• Understanding of your ICT landscape (applications, infrastructure, cloud services, network topology)

• Access to key stakeholders: CISO, CRO, IT operations, business continuity manager

Understanding DORA's ICT risk management requirements

Article-by-article breakdown

DORA Chapter II (Articles 5-16) establishes the most detailed ICT risk management requirements in EU financial services regulation. Understanding each article's specific demands is essential before building your framework:

Article

Title

Key requirements

Key deliverables

Art 5

Governance and organisation

Management body defines, approves, oversees ICT risk framework

Board mandate, governance charter, training program

Art 6

ICT risk management framework

Comprehensive, documented framework with strategies, policies, procedures

Framework document, ICT risk strategy, annual review process

Art 7

ICT systems, protocols, tools

Reliable and resilient ICT systems maintained and updated

System standards, update policies, capacity management

Art 8

Identification

Identify, classify, document all ICT assets, risks, and dependencies

ICT asset register, risk register, dependency maps

Art 9

Protection and prevention

ICT security policies, access controls, encryption, patch management

Security policy suite, access control procedures, encryption standards

Art 10

Detection

Mechanisms to detect anomalous activities and ICT incidents

Monitoring strategy, SIEM configuration, alert procedures

Art 11

Response and recovery

ICT business continuity policy, disaster recovery plans, communication plans

BCP, DRP, crisis communication plan, backup strategy

Art 12

Backup policies and procedures

Backup and restoration policies, testing of backups, separate recovery sites

Backup policy, restoration procedures, test records

Art 13

Learning and evolving

Post-incident reviews, mandatory training, vulnerability disclosures

Post-incident review process, training program, lessons learned register

Art 14

Communication

Crisis communication plans, responsible disclosure policies

Communication policy, disclosure procedures, public notification templates

Art 15

Further harmonisation of ICT risk management tools

Regulatory Technical Standards specifying details of the framework

RTS compliance mapping, technical implementation

Art 16

Simplified ICT risk management framework

Proportionate requirements for qualifying small entities

Simplified framework document (if applicable)

The framework structure

DORA requires your ICT risk management framework to follow a specific lifecycle: Identify, Protect, Detect, Respond, Recover, Learn. This mirrors established cybersecurity frameworks (such as NIST CSF) but adds DORA-specific requirements around governance, proportionality, and regulatory reporting.

Use ISMS Copilot to understand how your existing framework maps to this lifecycle:

"Compare DORA's ICT risk management lifecycle (Identify, Protect, Detect, Respond, Recover, Learn) from Articles 6-16 against our existing [ISO 27001 / NIST CSF / EBA Guidelines] framework. For each lifecycle phase, identify: which existing controls already satisfy DORA, where DORA adds specific requirements beyond our current framework, and what new documentation or processes we need to create."

Step 1: Establish the ICT risk management framework document

Framework structure and governance

Article 6 requires a comprehensive, documented ICT risk management framework. This is the master document that ties together all policies, procedures, and processes across the lifecycle.

1. Open your DORA workspace in ISMS Copilot

2. Generate the framework document:

   "Create a comprehensive ICT Risk Management Framework document for a [entity type] that satisfies DORA Article 6. Include: purpose and scope, governance structure (linking to Article 5 management body responsibilities), ICT risk management strategy and objectives, risk appetite and tolerance levels, framework components (identification, protection, detection, response, recovery, learning), integration with overall enterprise risk management, roles and responsibilities (CISO, CRO, ICT risk function, first/second/third line), review and update procedures (at least annual, and after major incidents per Article 6(5)), and framework effectiveness metrics. Reference specific DORA articles for each section."

3. Define the ICT risk strategy:

   "Draft an ICT risk strategy for our [entity type] as required by DORA Article 6(8). Include: strategic ICT risk objectives aligned with business strategy, risk tolerance thresholds approved by the management body, approach to ICT risk assessment methodology, resource allocation strategy for ICT security, key risk indicators (KRIs) and reporting frequency, and integration with digital transformation initiatives. Make it suitable for management body approval."

Internal ICT audit function

Article 6(6) requires that the ICT risk management framework be audited on a regular basis by ICT auditors. Use ISMS Copilot to establish this function:

"Define the internal ICT audit function requirements for DORA Article 6(6). Include: ICT audit charter, independence and objectivity requirements, audit universe covering all ICT risk management framework components, risk-based audit planning methodology, audit frequency (at least annual for key areas), reporting to management body and audit committee, and follow-up procedures for audit findings. Provide a sample annual ICT audit plan."

Step 2: ICT asset identification and classification (Article 8)

Building your ICT asset inventory

Article 8 requires you to identify, classify, and document all ICT assets, resources, and their interconnections. This inventory forms the foundation for risk assessment, incident classification, and third-party risk management.

1. Generate the asset inventory structure:

   "Create an ICT asset inventory template that satisfies DORA Article 8 requirements. Include columns for: asset ID, asset name and description, asset category (hardware, software, data, network, cloud service, third-party service), asset owner, business function supported, criticality classification (critical, important, standard), confidentiality/integrity/availability requirements, physical and logical location, interconnections and dependencies on other assets, supporting ICT third-party providers, recovery time objective (RTO) and recovery point objective (RPO), last review date. Provide classification criteria for each field and sample entries for a [entity type]."

2. Map ICT asset dependencies:

   "Create an ICT dependency mapping methodology for DORA Article 8(1). Our critical business functions include [list functions]. For each function, help us identify: the ICT systems and applications that support it, infrastructure components (servers, networks, storage), data flows and data repositories, third-party ICT services and providers, single points of failure and concentration risks. Provide a template for documenting these dependencies visually and in tabular format."

3. Classify ICT assets by criticality:

   "Define ICT asset classification criteria for DORA compliance. Create a classification scheme with levels (Critical, Important, Standard) based on: impact on financial services delivery if disrupted, regulatory reporting obligations triggered, number of clients/counterparties affected, data sensitivity, recovery time requirements, and interconnection with other critical assets. Provide decision trees and examples for a [entity type]."

ICT risk identification and assessment

With your asset inventory complete, conduct a systematic risk assessment against identified ICT assets:

"Create an ICT risk assessment methodology and template aligned with DORA Article 8. For each critical and important ICT asset, assess: threat scenarios (cyber attacks, system failures, natural disasters, human error, third-party failures), vulnerabilities (technical, procedural, organizational), existing controls and their effectiveness, likelihood of occurrence (1-5 scale with criteria), impact on business functions, clients, and regulatory compliance (1-5 scale with criteria), residual risk score and risk level, risk owner and treatment decision (mitigate, accept, transfer, avoid), treatment actions and timeline. Include integration points with our enterprise risk register."

Step 3: Protection and prevention measures (Article 9)

Developing ICT security policies

Article 9 mandates that financial entities develop and document ICT security policies covering access management, encryption, network security, and change management. These policies must be proportionate to your risk profile.

1. Generate the ICT security policy suite:

   "Create a comprehensive ICT security policy for a [entity type] satisfying DORA Article 9. Structure the policy to cover: information security governance and objectives, access control and identity management (including privileged access, multi-factor authentication, and least privilege principle), network security (segmentation, perimeter protection, intrusion prevention), encryption and cryptographic controls (data at rest, in transit, key management), ICT change management (testing, approval, rollback procedures), patch management and vulnerability remediation timelines, physical and environmental security for ICT assets, secure development lifecycle requirements, endpoint protection and mobile device management, and data leakage prevention measures. For each area, reference the specific DORA article and provide implementation guidance proportionate to a [entity size] organization."

2. Create access control procedures:

   "Develop detailed access control procedures for DORA Article 9(4). Include: user provisioning and deprovisioning workflows, role-based access control (RBAC) design, privileged access management (PAM) requirements, access review procedures (frequency, scope, documentation), authentication standards (MFA requirements, password policies), remote access security controls, service account management, and access logging and monitoring requirements. Provide procedure templates with step-by-step instructions."

3. Establish patch management procedures:

   "Create an ICT patch management policy and procedure for DORA compliance. Include: vulnerability scanning frequency, patch classification (critical, high, medium, low) with corresponding remediation timelines, testing procedures before deployment, emergency patching process for zero-day vulnerabilities, patch tracking and compliance reporting, exception management for systems that cannot be patched, and integration with your change management process. Provide KPIs for patch compliance reporting to the management body."

ICT systems standards and resilience (Article 7)

Article 7 requires that ICT systems are resilient, reliable, and have sufficient capacity. Use ISMS Copilot to develop the supporting standards:

"Create ICT system standards and requirements for DORA Article 7. Include: system reliability and availability targets for critical functions, capacity management procedures (monitoring, planning, scaling), system update and maintenance policies, technology obsolescence management, configuration management standards, environment separation (production, testing, development), and requirements for systems supporting critical or important functions. Provide a compliance checklist format."

Step 4: Detection capabilities (Article 10)

Building your detection and monitoring strategy

Article 10 requires mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. Your detection capabilities must be proportionate to the importance of the ICT assets being monitored.

1. Design the detection strategy:

   "Create a comprehensive ICT detection and monitoring strategy for a [entity type] satisfying DORA Article 10. Include: monitoring architecture (SIEM, EDR, NDR, UEBA components), data sources to monitor (network traffic, system logs, application logs, authentication events, database activity, cloud service logs), detection use cases prioritized by risk (unauthorized access, data exfiltration, malware, DDoS, insider threats, third-party anomalies), alert classification and severity levels, correlation rules and behavioral baselines, 24/7 monitoring coverage requirements, and integration with incident classification under DORA Article 17. Provide implementation priorities for a [size] organization."

2. Define anomaly detection procedures:

   "Develop operational procedures for ICT anomaly detection under DORA Article 10. Include: how anomalies are identified (automated alerts, manual review, threat intelligence feeds), initial triage process (who reviews, response time targets, escalation criteria), false positive management, documentation requirements for detected anomalies, handoff procedures to incident response team, and continuous tuning of detection rules based on threat landscape changes. Provide a procedure template with roles and responsibilities."

Step 5: Response and recovery procedures (Articles 11-12)

ICT business continuity management

Articles 11 and 12 establish detailed requirements for business continuity, disaster recovery, and backup management. These must cover scenarios including severe ICT disruptions, cyber attacks, and third-party provider failures.

1. Create the ICT business continuity policy:

   "Develop an ICT Business Continuity Policy for a [entity type] satisfying DORA Article 11. Include: policy objectives and scope, governance (management body approval requirement), business impact analysis (BIA) methodology for ICT services, continuity strategies for each critical business function, recovery time objectives (RTO) and recovery point objectives (RPO) by function, continuity plans for scenarios: cyber attack, system failure, data center outage, critical third-party provider failure, natural disaster, pandemic, communication plans (internal, clients, competent authorities, public), roles and responsibilities during a continuity event, plan activation criteria and escalation procedures, testing requirements (frequency, scope, types of tests), plan maintenance and review cycle (at least annual). Reference DORA Article 11 requirements throughout."

2. Develop disaster recovery procedures:

   "Create ICT Disaster Recovery Plans for our [entity type] covering [list critical systems]. For each critical system, document: system description and business functions supported, recovery team and contact details, recovery procedures (step-by-step), failover mechanisms and alternate processing sites, data restoration procedures from backups, integrity verification after restoration, communication requirements during recovery, criteria for declaring recovery complete, and post-recovery review procedures. Align RTOs and RPOs with our business continuity policy."

3. Establish backup policies and procedures (Article 12):

   "Create comprehensive backup and restoration policies and procedures for DORA Article 12. Include: backup scope (all data, configurations, software required to restore operations), backup frequency by data classification and RPO, backup methods (full, incremental, differential), secure storage requirements (geographically separate secondary site per Article 12(1)), encryption of backup data, backup integrity testing procedures and frequency, restoration testing procedures (at least annual per Article 12(2)), backup monitoring and alerting, documentation and logging requirements, and procedures for backup of systems hosted by third-party providers. Specify requirements for the physically and logically separated backup site."

Crisis communication (Article 14)

Article 14 requires dedicated crisis communication plans. Generate these using ISMS Copilot:

"Develop an ICT crisis communication plan for DORA Article 14. Include: communication governance (who authorizes external communications), stakeholder communication matrix (management body, employees, clients, counterparties, competent authorities, media, public), communication templates for different incident severity levels, responsible disclosure policy for ICT vulnerabilities, procedures for coordinating with competent authorities during incidents, social media and public relations protocols, designated spokesperson and backup, and communication logging and record-keeping. Provide template messages for major ICT incident scenarios."

Step 6: Learning and evolving (Article 13)

Post-incident review process

Article 13 requires financial entities to learn from ICT incidents, testing results, and vulnerabilities. This creates a continuous improvement cycle that strengthens your framework over time.

1. Establish the post-incident review process:

   "Create a post-incident review procedure for DORA Article 13. Include: trigger criteria (which incidents require formal review), review timeline (within [X] weeks of incident closure), review participants (incident responders, risk management, affected business areas, management), review template covering: incident timeline, root cause analysis (technical and organizational), control effectiveness assessment, gaps in detection or response, impact on clients and business functions, regulatory reporting accuracy, lessons learned and improvement actions, action tracking (owner, deadline, priority), management body reporting requirements, and integration of lessons into ICT risk management framework updates. Provide a post-incident review report template."

2. Build the continuous improvement program:

   "Design a continuous improvement program for the ICT risk management framework under DORA Article 13. Include: inputs to the improvement cycle (post-incident reviews, testing results, audit findings, regulatory guidance, threat intelligence, technology changes), improvement action governance (how actions are prioritized, approved, tracked), metrics for framework effectiveness (incident trends, detection times, recovery times, control maturity), annual framework review process for management body, and integration with training and awareness programs per Article 13(6). Provide a template for the annual framework review report."

ICT security awareness and training

Article 13(6) requires mandatory ICT security awareness programs and digital operational resilience training. Develop these with ISMS Copilot:

"Create an ICT security awareness and training program for DORA Article 13(6). Include: training needs analysis by role (management body, ICT staff, all employees, third-party contractors), training topics (ICT risk awareness, incident reporting obligations, security policies, social engineering, DORA-specific requirements), delivery methods and frequency, management body ICT risk training curriculum (per Article 5(4)), training effectiveness assessment, record-keeping and compliance tracking, and annual training plan. Differentiate between general awareness and role-specific technical training."

Step 7: Integrate and validate the complete framework

Cross-referencing framework components

Once you have developed all framework components, use ISMS Copilot to validate completeness and consistency:

"Review the following ICT risk management framework components for DORA compliance completeness: [list or upload your framework document, policies, procedures, templates]. For each DORA Article 5-16, confirm: whether the requirement is addressed, which document addresses it, whether the treatment is adequate for a [entity type] of our size, any gaps or inconsistencies between documents, and any requirements from Regulatory Technical Standards (RTS) under Article 15 that are not yet addressed. Provide a compliance matrix."

Preparing for regulatory examination

Competent authorities will examine your ICT risk management framework as a primary focus area. Prepare your evidence package:

"Create a DORA ICT risk management examination preparation checklist for a [entity type]. For each Article 5-16, list: the expected regulatory questions, evidence documents to have ready, key metrics and KPIs to present, common deficiency findings and how to avoid them, and management body demonstration requirements (training records, meeting minutes, approval evidence). Prioritize by likelihood of examination focus."

Next steps

You now have a comprehensive ICT risk management framework covering all DORA Article 6-16 requirements:

• Framework document with governance structure and ICT risk strategy

• ICT asset inventory with classification and dependency mapping

• Protection and prevention measures with security policy suite

• Detection capabilities with monitoring strategy and procedures

• Response and recovery procedures with BCP, DRP, and backup policies

• Learning and evolving program with post-incident review and training

Continue with the next guides in this DORA series:

• How to implement DORA incident reporting using AI -- Build on your detection and response capabilities with DORA's specific incident classification and reporting requirements

• How to plan DORA resilience testing using AI -- Design your testing program to validate the controls and procedures you have established in this framework

• How to manage DORA third-party ICT risk using AI -- Extend your risk management framework to cover ICT third-party providers identified in your asset inventory

For ready-to-use prompts covering every aspect of ICT risk management, see the DORA Compliance Prompt Library. For the complete regulatory overview, refer to the DORA Compliance Guide for Financial Entities.

Getting help

For additional support building your ICT risk management framework:

• Ask ISMS Copilot: Use your DORA workspace for iterative policy development and review

• Upload existing policies: Get targeted gap analysis by uploading current ICT risk documentation for comparison against DORA requirements

• Cross-reference frameworks: Map existing ISO 27001 or EBA Guidelines controls to DORA Articles 6-16 to leverage prior work

• Validate outputs: Review AI-generated framework documents against the DORA regulation text and relevant Regulatory Technical Standards before management body approval