DORA ICT Risk Management Framework: Board Approval Guide

Before examining what Article 6 requires, the distinction between the ICT risk management framework and the ICT risk management programme must be clear, because confusing them is one of the most common governance failures in DORA preparation.

The ICT risk management framework is the board-level document. It defines the entity's approach to identifying, classifying, and managing ICT risk. It sets risk appetite and establishes governance structures, roles, and oversight mechanisms. The management body formally approves it, reviews it annually, and is accountable for it under Article 5(2)(a).

The ICT risk management programme is what the team implements. It is the operational translation of the framework: the specific controls, processes, tools, and workflows through which the framework's requirements are discharged. This is the CISO's domain.

A board that has approved a framework but has yet to demonstrate that the programme is operationally aligned to it has a governance gap. An entity with a mature security programme but without a formally approved framework document has a DORA compliance gap. Both matter for supervisors.

DORA entered into force on 16 January 2023 and became applicable on 17 January 2025. The ICT risk management framework requirements under Chapter II apply to all in-scope financial entities, with proportionality provisions for simplified frameworks under Article 16 for a defined list of entity types, including small and non-interconnected investment firms and certain exempted institutions. Eligibility turns on entity type under the applicable sectoral directive.

Article 6(1) establishes the foundational obligation: financial entities must have a sound, comprehensive, and well-documented ICT risk management framework as part of their overall risk management system.

Chapter II of DORA, covering Articles 8 through 14, details the minimum components the framework must address. They are enumerated requirements, each of which supervisors will examine.

Identification of ICT Risk Exposure

The framework must include a methodology for identifying and classifying the entity's ICT assets and associated risks. This means maintaining an up-to-date inventory of ICT assets, including hardware, software, data, and infrastructure, and mapping dependencies between those assets and the business functions they support. Article 8 separately addresses asset management requirements, but the framework document must establish the governance of that process.

Protection and Prevention

Article 9 requires the framework to address protection and prevention measures. This includes policies for access management, patch management, configuration management, and the controls through which the entity protects the confidentiality, integrity, and availability of its ICT systems. The framework sets the governance standard; specific control specifications sit in subordinate policy documents.

Detection

The framework must establish how the entity detects anomalies and unusual behaviour in its ICT environment. Article 10 addresses detection in more detail, but the framework must articulate the governance architecture: who is responsible for detection, what monitoring capabilities are required, and how detection findings are escalated.

Response and Recovery

Articles 11 and 12 address ICT-related incident response, recovery, and backup. At the framework level, the board is approving the entity's approach: governance of incident classification, escalation, response coordination, and recovery priorities. The operational incident response playbook sits below the framework layer.

Learning and Evolving

Article 13 reflects a principle that runs through DORA: the framework must address how the entity learns from incidents and evolves its approach over time. Post-incident reviews, lessons-learned integration, and threat intelligence feeds all fall under this component. The framework must establish that this learning loop exists as a governed process.

Communication

The framework must address internal and external communication in the context of ICT risk and incidents. This includes the escalation path to the management body, communication with competent authorities under Article 19 major incident reporting obligations, and communication with ICT third-party providers under contractual and regulatory requirements.

Risk appetite for ICT risk is a board-level construct. The management body sets the business context within which technical risk thresholds make sense, and the risk and ICT functions translate that context into measurable operational metrics.

A credible ICT risk appetite statement, suitable for board approval and supervisory review, should address:

1. Availability: what levels of service disruption are acceptable for which business functions? What recovery time objectives (RTOs) and recovery point objectives (RPOs) does the board consider tolerable for critical operations?
2. Confidentiality: what is the board's appetite for data exposure risk, across customer data, proprietary information, and regulated data categories?
3. Integrity: what tolerance exists for data corruption or manipulation events?
4. Third-party concentration: what is the acceptable level of dependency on any single ICT third-party provider, particularly for critical or important functions?
5. Residual risk: what level of residual ICT risk, after controls are applied, is the board willing to accept?

Appetite statements expressed only in qualitative terms have limited supervisory value. Statements that connect to measurable thresholds, such as incident frequency, RTO metrics, and third-party concentration ratios, give the board a basis for monitoring and give supervisors a basis for examination.

Once the board approves the appetite statement, the ICT risk team must translate it into operational tolerances and Key Risk Indicators (KRIs) that control owners can act against. This operationalisation is the link between the governance layer and the implementation layer.

There is no DORA-mandated template for the ICT risk management framework document. Supervisors expect a document that is coherent, internally consistent, and clearly aligned to Article 6. A workable structure:

1. Scope and Purpose. Define the entities covered, the regulatory basis (DORA Article 6), and the relationship of this framework to the entity's overall risk management framework.
2. Governance and Ownership. Define the management body's role under Article 5, the three lines of defence model as it applies to ICT risk, and the ownership and review responsibilities for this document.
3. ICT Risk Appetite Statement. The board-approved appetite statement, with quantitative thresholds where possible. This section must be clearly distinguishable as board-owned content.
4. ICT Risk Identification and Classification. Methodology for asset identification, dependency mapping, and risk classification. Reference to the asset management policy and register.
5. Protection and Prevention Standards. High-level standards for access management, vulnerability management, configuration control, and data protection. Detailed specifications are in subordinate policies.
6. Detection and Monitoring. Governance of detection capabilities: required monitoring coverage, anomaly detection standards, and escalation thresholds.
7. Response and Recovery. Framework for incident classification, escalation to the management body, business continuity governance, and recovery prioritisation. Connection to business continuity and incident response plans.
8. Learning and Continuous Improvement. Process for post-incident review, lessons-learned integration, and annual framework review.
9. Communication. Escalation to the management body; major incident reporting under Article 19; third-party communication requirements.
10. Review and Approval. Review frequency (at minimum annual, per Article 6(5)), approval authority (management body), and version control.
11. Internal Audit. Per Article 6(6), the framework is subject to regular internal audit. Include the audit schedule, the mechanism for feeding audit conclusions into the review cycle, and the ownership of any remediation actions.

Supervisory examination of the ICT risk management framework, including by the FCA in the UK and National Competent Authorities across the EU, focuses on evidence of genuine governance, assessed through what the board can demonstrate rather than what the document states.

Governance Substance

Can board members explain the framework and articulate the entity's ICT risk appetite? Minutes showing board approval without evidence of substantive discussion will attract scrutiny.

Framework-to-Programme Alignment

Is the operational ICT risk programme demonstrably aligned to the framework? Supervisors will follow the chain from framework principles to operational controls, looking for gaps.

Risk Appetite Operationalisation

Is the board's appetite statement translated into measurable KRIs? Are control owners aware of and reporting against those indicators? A gap here suggests the framework is a paper exercise.

Annual Review Evidence

Has the framework been reviewed annually as Article 6(5) requires? Is there evidence of substantive review, with documented conclusions and updated sections where warranted?

Internal Audit Coverage

Article 6(6) requires the ICT risk management framework to be audited internally on a regular basis, consistent with the entity's audit plan. Supervisors will expect to see that internal audit has reviewed the framework, that findings have been documented, and that the framework review cycle takes audit conclusions into account. Supervisors look for evidence of internal audit coverage and a clear mechanism for feeding audit conclusions into the review cycle.

Third-Party Integration

Does the framework address ICT third-party risk in a way that reflects the entity's actual dependency profile? Article 28 requires that ICT third-party risk management is integrated into the overall ICT risk management framework.

Incident-Driven Updates

Has the framework been updated following material ICT incidents? Static frameworks that predate significant incidents are a supervisory concern.

The governance layer's value is only realised when it connects to operational practice. The management body approves the ICT risk appetite statement; the ICT risk and compliance functions must translate that into something control owners can act against.

The translation chain runs: board appetite statement defines the outer bounds of acceptable risk. The ICT risk management programme interprets appetite into risk tolerance thresholds for specific risk domains. Key Risk Indicators are measurable metrics assigned to control owners, reported upward through the risk function to the management body reporting cycle. Control effectiveness reporting provides periodic reporting to the board on whether KRIs are within appetite, with escalation when thresholds are breached.

This chain is what makes the framework document more than a compliance artefact. Firms using SureCloud's Continuous Controls Monitoring (CCM) capability report significant reductions in audit preparation time, because the evidence is continuously captured rather than assembled retrospectively before each review cycle.