Module 4: Governance and the ICT Risk Management Framework

Step 1 – Positioning DORA Governance & ICT Risk Management

Where does this module fit?

By now you know who DORA applies to (Module 2) and how it sits among GDPR, NIS2, PSD2, etc. (Module 3). Here we focus on how firms must be governed and what an ICT Risk Management Framework (ICT RMF) must look like under DORA.

Key legal references (as of December 2025)

• Regulation (EU) 2022/2554 (DORA) – entered into force in 2023 and applies from 17 January 2025.
• Core provisions for this module:
• Articles 4–6 – Governance, management body responsibilities, ICT risk management framework.
• Articles 7–15 – ICT risk management requirements (prevention, detection, response, recovery, learning).
• Annex I – Detailed components of the ICT RMF.
• Annex II – Reporting templates (relevant for documentation & auditability).
• Level 2 measures (e.g., RTS/ITS from ESAs) refine details, but the Regulation text is the baseline.

Why this matters

DORA moves ICT and cyber risk from “IT problem” to core board-level responsibility, with:

• Explicit accountability of the management body (board + senior management).
• A mandatory, documented ICT RMF integrated into enterprise risk management (ERM).
• Supervisory scrutiny and potential sanctions when governance is weak.

In this module, you will:

1. Deconstruct DORA’s management body duties for ICT risk.
2. Map the components of a compliant ICT RMF.
3. Practice gap analysis between a legacy ICT governance setup and DORA expectations.

> Thought anchor: Treat ICT risk like credit risk or market risk: it has a risk appetite, governance, controls, metrics, and board oversight. DORA forces firms to operationalize this mindset.

Step 2 – Management Body: From High-Level Oversight to Concrete Duties

Who is the “management body” under DORA?

DORA follows the usual EU definition (similar to CRR/CRD):

• The management body is the board of directors or equivalent, including, depending on national law, the senior management entrusted with the firm's direction.

Core DORA expectations (Articles 4–5)

Under DORA, the management body must:

1. Define and approve

• ICT risk management framework (policies, procedures, methodologies).
• ICT risk tolerance/risk appetite, including cyber risk, aligned with overall risk appetite.
• Roles and responsibilities for ICT and security (e.g., CISO, CIO, risk function).

1. Oversee and monitor

• Implementation and maintenance of the ICT RMF.
• Key ICT risk and performance indicators (e.g., incident volumes, patching timelines, availability metrics).
• Major ICT projects and changes (e.g., cloud migration, core banking system replacement).

1. Ensure resources and competence

• Adequate budget, staffing, and tools for ICT and security.
• Training for management body members on ICT/cyber risk (Article 5(4)).
• Independence and authority of control functions (risk, compliance, internal audit).

1. Accountability

• The board remains ultimately responsible, even if functions are outsourced or delegated.
• Supervisors can challenge the board on ICT risk decisions and may consider governance weaknesses as part of their risk assessment.

Integration into corporate governance

DORA expects integration, not a parallel IT silo:

• ICT risk is part of the overall risk management framework (aligned with, e.g., Basel/CRR/IFR frameworks).
• ICT risk considerations should influence strategic decisions (M&A, digital transformation, outsourcing, product launches).
• Governance must align with other EU frameworks:
• NIS2: management responsibility for cybersecurity.
• GDPR: accountability for data protection.
• Sector rules (e.g., EBA Guidelines on ICT and security risk management) – DORA now provides a horizontal baseline.

> Reflection: If your board currently receives only an annual “IT presentation” with uptime statistics, you are far from DORA-compliant. Under DORA, the board must regularly engage with risk-based, decision-enabling ICT information.

Step 3 – Thought Exercise: Is This Board DORA-Ready?

Imagine the following situation in a mid-sized EU payment institution:

• The board meets quarterly.
• ICT matters appear as a sub-item under “Operations update”.
• The CIO presents:
• System uptime (99.7%).
• Number of helpdesk tickets.
• Ongoing IT projects (e.g., mobile app redesign).
• There is no documented ICT risk appetite.
• Cyber incidents are reported only if they disrupt customer service.
• The board has no formal cyber training; one member has an IT background but in manufacturing.

Your task (write down your reasoning)

1. List at least 4 gaps versus DORA’s management body expectations.
2. For each gap, propose one concrete improvement.
3. Identify one piece of information the board should regularly receive to exercise proper ICT risk oversight.

> Aim for precision: reference concepts like risk appetite, incident reporting, training, KPIs/KRIs, and framework approval in your answer.

Use this exercise to structure how you would critically assess real boards in case studies or internships.

Step 4 – Anatomy of a DORA-Compliant ICT Risk Management Framework

DORA requires a formal, documented ICT Risk Management Framework (ICT RMF). Think of it as a meta-structure that organizes how the firm plans, executes, and monitors ICT risk management.

Core components (based on Articles 6–15 and Annex I)

At minimum, a DORA-compliant ICT RMF must cover:

1. Governance & organization

• Roles and responsibilities (board, senior management, CIO, CISO, risk, audit).
• Segregation of duties and reporting lines.
• Integration with enterprise risk management (ERM).

1. ICT strategy and architecture

• Alignment of ICT strategy with business and risk strategy.
• Target architecture (on-prem vs cloud, legacy vs modern, integration patterns).
• Lifecycle management (acquisition, development, maintenance, retirement).

1. Risk identification and assessment

• Processes to identify ICT and cyber risks (including third-party and supply-chain risks).
• Periodic risk assessments, threat modeling, vulnerability management.
• Risk classification and prioritization (e.g., critical vs non-critical services).

1. Risk appetite and controls

• Defined ICT and cyber risk appetite and tolerances.
• Control environment (preventive, detective, corrective controls).
• Mapping of controls to standards (e.g., ISO 27001, NIST CSF) is helpful but not a substitute for DORA.

1. Operational resilience capabilities

• Business continuity and disaster recovery (BCP/DRP) for ICT.
• Backup, redundancy, and failover strategies.
• Incident response and crisis management.

1. Monitoring, testing, and improvement

• Continuous monitoring of ICT systems and security.
• Periodic testing (vulnerability scans, penetration tests, scenario tests).
• Post-incident reviews and lessons learned loop.

1. Documentation, reporting, and auditability

• Policies, standards, procedures, and records.
• Internal reporting to management and board.
• External reporting (supervisory incident reports under DORA, plus GDPR, NIS2 where applicable).
• Audit trail of decisions and changes.

Key insight

DORA does not prescribe a single template or standard. Instead, it specifies functional outcomes. A firm can leverage existing frameworks (e.g., ISO 27001 ISMS) but must explicitly map them to DORA’s requirements.

> Challenge: Try to draw a diagram of an ICT RMF with these components as boxes and arrows. Where would you plug in third-party risk management and testing of digital operational resilience (covered more in later modules)?

Step 5 – Risk Identification, Classification & Appetite: A Concrete Scenario

Scenario: Online retail bank under DORA

A digital bank offers:

• Mobile and web banking.
• Instant payments.
• Card issuing.

It relies heavily on:

• A cloud-based core banking system.
• Several fintech APIs for KYC, fraud detection, and analytics.

#### 1. Risk identification

The bank conducts an ICT risk workshop and identifies:

• Service unavailability of the core banking cloud instance.
• API failure with the instant payments provider.
• Ransomware affecting customer-facing apps.
• Data exfiltration from misconfigured cloud storage.
• Third-party compromise in a KYC provider that processes sensitive PII.

Methods used:

• Asset inventory review.
• Threat intelligence feeds.
• Past incident analysis.
• Architecture diagrams.

#### 2. Classification

They classify:

• Critical services: core banking, payments, customer authentication.
• Important ICT systems: fraud detection, KYC services.
• Non-critical: internal reporting tools.

They also assign impact levels (high/medium/low) based on:

• Financial loss.
• Customer harm.
• Regulatory and reputational impact.

#### 3. Risk appetite

The board approves statements such as:

• “For critical customer-facing services, we accept a maximum unplanned downtime of 30 minutes per quarter.”
• “We have zero appetite for unencrypted storage of customer credentials and PII in any environment (prod, test, dev).”
• “We tolerate up to 2 minor security incidents per quarter that do not involve personal data or service disruption, provided they are remediated within 24 hours.”

These statements drive:

• Control selection (e.g., multi-region redundancy to meet uptime tolerance).
• Monitoring thresholds (alerts when approaching downtime limit).
• Prioritization of remediation efforts.

> Analytical angle: Notice how risk appetite is quantified and operationalized (downtime minutes, number of incidents, remediation times). Vague statements like “we minimize cyber risk” are insufficient under DORA.

Step 6 – Quick Check: Risk Appetite and Governance

Answer the following to test your understanding of DORA’s expectations around governance and risk appetite.

Step 7 – ICT Assets, Architecture & Lifecycle: What DORA Expects in Practice

DORA implicitly assumes you have control over your ICT estate. That requires robust asset management, architecture governance, and lifecycle processes.

1. ICT asset management

A DORA-aligned setup typically includes:

• Complete, up-to-date inventory of:
• Hardware, software, networks, data repositories.
• Cloud services, SaaS tools, APIs.
• Third-party dependencies (including 4th parties where relevant).
• Attributes for each asset:
• Business criticality (linked to important/critical functions).
• Data sensitivity (e.g., personal data, payment data, trade secrets).
• Owner (accountable person or function).
• Lifecycle state (in development, in production, decommissioned).

2. Architecture and design

DORA expects firms to:

• Use secure-by-design and secure-by-default principles.
• Consider resilience explicitly in architecture:
• Redundancy (N+1, active-active setups).
• Segmentation and isolation (e.g., separating critical payment systems from non-critical networks).
• Vendor and region diversification where justified.
• Document data flows and interdependencies, especially for critical services.

3. Lifecycle management

For each ICT asset, there should be documented processes for:

• Onboarding/acquisition: risk assessment, security requirements, vendor due diligence.
• Change management: impact analysis, testing, approvals, rollback plans.
• Patch and vulnerability management: timelines based on criticality (e.g., critical patches within X days).
• Decommissioning: data wiping, revocation of access, updating inventories.

Edge cases to consider

• Shadow IT: business units procuring SaaS without central oversight – this undermines DORA compliance.
• Legacy systems: unsupported OS or hardware that cannot be patched – DORA forces explicit risk acceptance, mitigation, or replacement plans.
• Multi-cloud architectures: complex interdependencies can obscure critical paths; DORA requires clear visibility into where critical data and services reside.

> Advanced thought: How would you reconcile a DevOps/Agile environment (frequent changes, CI/CD pipelines) with DORA’s need for control, documentation, and traceability? Think about automation, policy-as-code, and integrated change records.

Step 8 – Mini Gap Analysis: Legacy Governance vs DORA

You are assessing a traditional investment firm that is now in scope of DORA. Its current ICT governance looks like this:

• ICT asset inventory exists but is spread across multiple spreadsheets.
• Change management is email-based with no central system.
• The board receives a semi-annual IT risk report focusing on:
• Number of open vulnerabilities.
• Antivirus coverage.
• General comments on projects.
• There is a BCP/DRP, but it was last tested 4 years ago.
• No formal statement of ICT/cyber risk appetite.

Your task

1. Identify at least three major DORA gaps in:

• Asset management.
• Governance and reporting.
• Testing and resilience.

1. For each gap, propose a target-state control or process that would move the firm closer to DORA alignment.
2. Prioritize your recommendations: which gap would you address first and why, considering supervisory expectations and risk impact?

Write your answers in bullet points. Try to use DORA language: management body, ICT RMF, critical/important functions, testing of digital operational resilience, documentation and auditability.

> This is exactly the type of reasoning expected in advanced internships, consulting projects, or regulatory impact assessments.

Step 9 – Key Terms and Concepts Review

Flip the cards to reinforce core vocabulary from this module.

Step 10 – Final Knowledge Check: Governance & Framework Integration

One last question to consolidate your understanding of how governance and the ICT RMF interact under DORA.