Most financial entities that come to DORA already have an information security program, and many hold ISO 27001 certification. The natural assumption is that the ICT risk management chapter is covered. Much of it is. The parts that are not tend to be the parts supervisors read first: who owns the framework, what the management body has approved, and whether the required reviews happened.
The ICT risk management framework is Chapter II of DORA, Articles 5 to 16. It is the foundation the rest of the regulation builds on. Incident reporting, testing and third-party risk all refer back to it.
This article walks through what those articles require, where an existing security program usually falls short, and what evidence to keep so you can show the framework works rather than assert it.
Who owns the framework
Article 5 starts with governance, and it is direct. The management body defines, approves, oversees and is responsible for the implementation of all arrangements related to the ICT risk management framework. It bears ultimate responsibility for managing ICT risk.
In practice, Article 5 expects the management body to:
Set clear roles and responsibilities for all ICT-related functions.
Determine the appropriate risk tolerance level for ICT risk, as part of the digital operational resilience strategy.
Approve, oversee and periodically review the ICT business continuity policy and the ICT response and recovery plans.
Approve and periodically review the internal ICT audit plans and material changes to them.
Allocate and periodically review the budget for digital operational resilience, including training.
Approve and periodically review the policy on using ICT services from third-party providers.
Keep reporting channels so it is informed about provider arrangements, planned material changes and major ICT-related incidents.
Members of the management body must also keep their knowledge and skills current enough to understand and assess ICT risk, including through regular training. Except for microenterprises, entities must either establish a role to monitor arrangements with ICT third-party providers or designate a member of senior management as responsible for that risk exposure.
The evidence here is unglamorous: minutes showing the body approved specific documents, dated records of training attended by its members, and a named person in the third-party monitoring role. A framework that the security team wrote and nobody above it signed does not meet Article 5, however good it is.
What the framework itself must contain
Article 6 requires a sound, comprehensive and well-documented ICT risk management framework. It includes the strategies, policies, procedures, ICT protocols and tools needed to protect information and ICT assets, including software, hardware, servers and physical infrastructure.
Three requirements in Article 6 tend to catch teams out.
The review cycle. The framework must be documented and reviewed at least once a year, or periodically for microenterprises. It must also be reviewed after major ICT-related incidents, following supervisory instructions, and following conclusions from resilience testing or audits. A review is evidence only if it produces a dated record of what was considered and what changed.
Independence. Entities other than microenterprises must assign ICT risk management to a control function with sufficient independence. They must keep ICT risk management, control and internal audit functions appropriately separated, using the three lines of defense model or an equivalent internal risk management and control model. Internal audit must audit the framework regularly, and there must be a formal follow-up process for its findings.
The digital operational resilience strategy. This is a distinct document, not a relabeled security policy. It sets out how the framework supports the business strategy, the ICT risk tolerance level, information security objectives with key performance indicators, the ICT reference architecture, and how the entity detects, protects against and recovers from incidents.
The functional chain, Articles 7 to 14
The remaining articles follow a familiar sequence, close to the functions of NIST CSF 2.0. The table shows what each requires and the evidence a supervisor would reasonably expect to see.
| Article | What it requires | Evidence to keep |
|---|---|---|
| 7: ICT systems, protocols and tools | Systems that are up to date, reliable, have enough capacity, and are technologically resilient | Capacity reviews, lifecycle and patch status for key systems |
| 8: Identification | Identify, classify and document ICT-supported business functions, information assets, ICT assets and their dependencies | Asset inventories, dependency maps, yearly classification reviews, risk scenario reviews |
| 9: Protection and prevention | Security policies, access control, strong authentication, network protection, change management and patching | Approved policies, access review records, change tickets, configuration baselines |
| 10: Detection | Mechanisms to detect anomalous activity promptly, with multiple layers of control and alert thresholds | Monitoring coverage, alert rules, triage records |
| 11: Response and recovery | An ICT business continuity policy, response and recovery plans, business impact analysis, and plan testing | Approved plans, test reports, crisis management records |
| 12: Backup and recovery | Backup policies, restoration procedures, segregated backup systems, recovery time and point objectives | Backup schedules, restore test results, documented objectives |
| 13: Learning and evolving | Post-incident reviews, lessons learned, and security awareness and resilience training for all staff | Review reports, training completion records |
| 14: Communication | Crisis communication plans for staff, clients and the public | Approved communication plan, named spokespeople |
Two items in this chain deserve attention because they are specific to DORA.
Article 8 asks entities other than microenterprises to assess ICT risk on legacy systems regularly, at least yearly, and before and after connecting new technologies, applications or systems. Few existing programs schedule this explicitly.
Article 11 expects the continuity and response and recovery plans to be tested, including after substantive changes to the systems they cover. A plan reviewed on paper is not a tested plan. If you have run tabletop exercises but never a technical recovery, expect questions.
Proportionality and the simplified framework
DORA does not expect a small payment institution to run the same framework as a large bank. Article 4 requires implementation in proportion to the entity's size, risk profile, and the nature, scale and complexity of its services.
Article 16 goes further. It sets a simplified ICT risk management framework for certain smaller and less interconnected entities, with lighter documentation and governance requirements. The regulatory technical standards on ICT risk management specify the content of both the full and simplified frameworks, including expectations for policies such as access control, encryption, network security, ICT operations and change management.
Proportionality is a basis for calibration, not exemption. If you scale a requirement down, record why: the size, the risk, and the reasoning. A supervisor who disagrees with your judgment will at least see that you made one. Whether your entity qualifies for the simplified framework is worth confirming with counsel.
Where ISO 27001 helps and where it stops
An ISO 27001 management system gives you much of the machinery: a risk assessment method, a statement of applicability, internal audit, management review and corrective action. If you already run an ISMS, you are not starting over.
The gaps are specific. ISO 27001 asks top management to demonstrate leadership, but it does not list the approvals DORA assigns to the management body. It does not require a digital operational resilience strategy, a yearly legacy system assessment, or recovery time objectives per function. Its scope is set by you, and DORA's is not: every ICT asset supporting a critical or important function has to be inside it.
Treat the mapping as a gap analysis, not a translation. Go article by article, note which existing control satisfies each requirement, and write down what is missing. Your risk register should then carry ICT risks in terms the management body can set tolerance against.
An evidence checklist for the framework
These are the artifacts that let you show a supervisor the framework operates, not merely that it exists:
- Not done:
Management body minutes approving the framework, the resilience strategy, the continuity policy and the third-party policy, each dated
- Not done:
Training records for management body members
- Not done:
The framework document, with a version history showing the yearly review
- Not done:
A record of each event-driven review: after a major incident, a test or an audit
- Not done:
An organizational chart showing the independent control function and internal audit
- Not done:
Asset and dependency inventories, with the date of the last classification review
- Not done:
Legacy system risk assessments
- Not done:
Continuity and recovery plan test reports, with findings and fixes
- Not done:
Internal audit reports on the framework and the follow-up of findings
- Not done:
Post-incident review reports
The point-in-time nature of these records matters. A yearly review you cannot date did not happen, as far as a supervisor is concerned. For an overview of how this chapter fits the rest of the regulation, see DORA explained for ICT service providers and our DORA framework page.
How TrustLynce helps
TrustLynce keeps ICT risks, scores and treatment plans in a risk register the management body can review against its stated tolerance. Policy management versions each framework document and tracks acceptance, so the yearly review leaves a dated version history.