Building an ICT Risk Management Framework That Survives Review

The ICT risk management pillar is the foundation of DORA, and it is the one where the gap between a compliant-looking document and a defensible framework is widest. Every firm in scope has a framework. Considerably fewer have the artefacts that make the framework real.

What the Regulation Asks For

DORA requires a sound, comprehensive and well-documented ICT risk management framework, forming part of the overall risk management system, enabling the entity to address ICT risk quickly, efficiently and comprehensively. It must be documented and reviewed at least once a year, and additionally after major ICT-related incidents and following supervisory instructions or conclusions from resilience testing.

Structurally, the framework runs across a familiar lifecycle: identification, protection and prevention, detection, response and recovery, learning and evolving, and communication. The lifecycle is not novel. What is novel is that a financial supervisor now expects to inspect it and to see it connected to business function criticality rather than to IT asset classes.

Identification Is Where Frameworks Fail

The requirement is to identify, classify and adequately document all ICT-supported business functions, roles and responsibilities, the information assets and ICT assets supporting them, and their configurations and interconnections — internal and external.

Three specific failures recur.

A CMDB is offered as an asset inventory. A configuration management database lists assets. DORA asks for assets mapped to the business functions they support, with dependencies. The mapping is the deliverable; the CMDB is an input.

Dependencies stop at the first hop. Firms map the application to its primary provider and stop. The fourth-party chain — the provider's cloud host, its identity provider, its data centre — is where concentration risk actually sits. DORA's third-party pillar assumes you know it.

Legacy is quietly excluded. The systems least likely to appear on a modern inventory are the ones most likely to fail. Anything running an unsupported operating system should be on the register with a documented risk acceptance and an end date.

Get identification right and the rest of the framework has something to attach to. Get it wrong and every downstream control is scoped against a fiction.

Protection, Detection, Response

Protection and prevention covers ICT security policies, identity and access management, network segmentation, encryption at rest and in transit, patch and vulnerability management, and change management. The DORA-specific angle is that these must be designed with the criticality of the supported function in mind, not applied uniformly.

Detection requires mechanisms to promptly detect anomalous activities, including performance issues and ICT-related incidents, with multiple layers of control and defined alert thresholds and criteria to trigger incident response. The word "promptly" is doing work here: a detection capability that surfaces an incident three days later fails the incident reporting clock discussed in the incident reporting article.

Response and recovery requires an ICT business continuity policy, response and recovery plans, and — critically — recovery time and recovery point objectives set per function. Backup policies must specify scope and frequency based on the criticality of the information, and restoration must be tested. Untested backups are the single most common resilience finding across every regime, not just DORA.

Governance: The Management Body Cannot Delegate This

DORA places ultimate responsibility for managing ICT risk on the management body. It must approve, oversee and periodically review the framework, allocate an appropriate budget, set the risk tolerance for ICT risk, and maintain sufficient knowledge and skills — including through regular, specific training on ICT risk.

That last obligation is often overlooked and is trivially easy to evidence. Board training on ICT and cyber risk, delivered annually, recorded in the minutes, with attendance. Firms that cannot produce it are answering an avoidable question.

The substantive test is whether board minutes show challenge. A minute reading "the committee noted the ICT risk report" evidences receipt, not oversight. A minute recording that the committee questioned the recovery time objective for the payments function and requested a revised plan evidences oversight. Same meeting, different record, entirely different supervisory outcome.

The Simplified Framework

Certain smaller and non-interconnected entities may apply a simplified ICT risk management framework. It still requires a sound and documented framework, protection and prevention measures, mechanisms to detect and respond to incidents, business continuity arrangements, and a review process. Simplified means fewer prescribed components, not a lighter attitude — and, as covered in the main DORA guide, the entitlement itself must be justified.

Key Takeaways

• Identification is the load-bearing stage: assets mapped to business functions with fourth-party dependencies, not a CMDB export.

• Recovery objectives must be set per function and backups must be restore-tested, not just taken.

• The management body cannot delegate ultimate responsibility, and its ICT training obligation is explicit and easily evidenced.

• Board minutes must show challenge, not receipt.

• The framework requires trigger-based reviews after major incidents and testing findings, not only the annual cycle.

Frequently Asked Questions

Can the ICT risk framework sit inside the existing operational risk framework? Yes — DORA expects it to form part of the overall risk management system. What it cannot do is disappear into it. The ICT-specific components must be identifiable, separately approved and separately reviewable.

How granular should asset-to-function mapping be? Granular enough that you can answer, for any critical or important function, which assets and providers it depends on and what happens if each fails. That is the test. Granularity beyond that point adds maintenance cost without adding defensibility.

Does DORA require a specific security standard such as ISO 27001? No. It is standard-agnostic. Mapping an existing ISO 27001 or NIST CSF control set to DORA articles is an efficient route to evidence, but the certification alone does not demonstrate compliance, because DORA's business-function orientation is not how those standards scope.

About the author

Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.

*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*