DORA ICT Risk Management Framework: Operationalising Articles 5-16 After Fifteen Months of Enforcement | FortisEU

DORA has been enforceable since January 17, 2025. Most financial entities met that date with documentation — ICT risk management frameworks drafted, governance structures approved, policies adopted. The documentation phase is largely complete across the sector. What is becoming apparent fifteen months in is that documentation and operational maturity are not the same thing.

The ICT risk management framework under Articles 5-16 of Regulation 2022/2554 is the structural core of DORA. It is not one requirement among many — it is the requirement that every other DORA obligation builds upon. Your incident reporting capability depends on the detection mechanisms defined in your framework. Your TLPT programme tests the resilience your framework is supposed to deliver. Your register of information documents third-party relationships governed by your framework's policies. If the framework is a paper exercise, everything downstream is theatre.

This post examines what the ICT risk management framework requires at an operational level, where the most consequential implementation gaps are emerging, and what supervisors are looking for when they assess framework maturity.

The Framework Architecture Under Articles 5-16

DORA's ICT risk management framework is structured in a deliberate sequence. Articles 5-6 establish governance and organisational requirements. Articles 7-8 cover systems and identification. Articles 9-10 address protection and detection. Articles 11-12 deal with response and recovery. Articles 13-16 cover learning, evolving, and communication. Each layer depends on the one before it.

The ESAs' Regulatory Technical Standards — particularly the RTS on ICT risk management framework (Commission Delegated Regulation 2024/1774) — provide the detailed implementation requirements. The RTS transforms the principles-based language of Articles 5-16 into specific, auditable obligations. If your framework implementation was based solely on the Level 1 text of the regulation, you are likely missing requirements that the RTS introduced.

Governance: Articles 5-6

Article 5 requires financial entities to have in place an internal governance and control framework that ensures effective and prudent management of ICT risk. Article 6 requires the management body to bear ultimate responsibility for the ICT risk management framework.

The operational substance of these articles is often underestimated. What supervisors look for is not whether the board has approved a policy document. They look for evidence that the management body actively engages with ICT risk — that decisions about risk tolerance, resource allocation, and control design are made at the appropriate level with adequate information.

Management body responsibilities under Art. 6(1) include:

Setting and approving the digital operational resilience strategy
Approving, overseeing, and periodically reviewing the ICT business continuity policy, the ICT response and recovery plans, and the ICT internal audit plans
Approving and periodically reviewing the entity's ICT risk tolerance level
Approving arrangements for the use of ICT third-party service providers
Ensuring adequate budget allocation for ICT security and digital operational resilience

The RTS specifies that the management body must be informed at least annually — and whenever significant ICT incidents or material changes occur — about the ICT risk management framework's effectiveness. This is not a formality. The information provided to the management body must be sufficient to allow informed decision-making about risk acceptance, control investment, and strategy adjustments.

Common governance gap: The management body approves the framework once and receives periodic reports, but the reports lack the specificity needed for actual governance. Telling the board "ICT risk is managed" is not governance. Telling the board "Our mean detection time for critical incidents is 23 minutes, three critical vulnerabilities in third-party components remain unpatched beyond SLA, and our recovery testing achieved 94% of target RTO across critical functions" is governance.

ICT Systems, Protocols, and Tools: Article 7

Article 7 requires financial entities to use and maintain updated ICT systems, protocols, and tools that are appropriate to the magnitude of operations, are reliable, have sufficient capacity, and are technologically resilient. The RTS elaborates this into specific requirements around ICT asset management, encryption, network security, and secure development.

The operational requirement is an accurate, current, and comprehensive ICT asset inventory. You cannot manage risk for systems you do not know you operate. The asset inventory must cover hardware, software, network components, and data assets — and must be maintained in a state that allows real-time querying.

Key RTS requirements under Art. 7:

Assets must be classified by criticality, aligned with the entity's identification of critical or important functions under Art. 8
Configuration baselines must be defined and deviations detected
Capacity management must ensure systems can handle peak loads and projected growth
Vulnerability management processes must ensure timely identification and remediation of vulnerabilities in all ICT assets

Where entities struggle is the linkage between asset inventory and criticality classification. Many entities maintain an asset register and separately maintain a list of critical functions. The two are not connected — which means they cannot answer the question supervisors care about: "Which specific systems support your critical functions, and what is the current risk posture of those systems?"

Identification: Article 8

Article 8 requires entities to identify, classify, and adequately document all ICT-supported business functions, roles and responsibilities, ICT assets, and their interdependencies. The RTS requires this identification to include mapping of all ICT assets to the business functions and processes they support.

This is where the ICT risk management framework either becomes operationally meaningful or remains an abstraction. The identification requirement is not satisfied by a high-level architecture diagram. It requires a dependency map that connects business processes to applications, applications to infrastructure, infrastructure to third-party services, and all of these to the data they process.

The identification must also include ICT risks. Each identified risk must be documented with: the risk source, the threat, the vulnerability exploited, the potential impact, the likelihood assessment methodology, the current control environment, and the residual risk level. This is not a one-time exercise. Art. 8(5) requires entities to review the risk identification at least annually and after significant changes.

Practical implementation pattern:

Start with critical or important functions as defined under Art. 3(22) — the functions whose disruption would materially affect the entity's financial performance, service delivery, or compliance
Map each critical function to the ICT assets that support it — applications, databases, infrastructure components, and third-party services
For each ICT asset supporting a critical function, identify the threats, vulnerabilities, and potential impact of disruption or compromise
Document the controls mitigating each risk and assess residual risk
Establish triggers for re-assessment: material changes, significant incidents, new threat intelligence, and periodic review cycles

The output should be a living risk register — not a static document, but a queryable model that can answer questions like: "Which critical functions are affected if this third-party provider experiences an outage?" or "What is our aggregate exposure to vulnerabilities in end-of-life operating systems?"

Protection and Prevention: Article 9

Article 9 covers ICT security policies and procedures, network security, access control, physical security, and data protection. The RTS details the specific requirements for each area, including minimum standards for encryption, authentication, and network segmentation.

The most operationally demanding requirement in Art. 9 is the ICT security policy framework. The RTS requires the entity to establish, maintain, and implement a comprehensive set of policies covering: information security, network security, cryptography and encryption, ICT operations security, ICT project and change management, physical security, human resources security, identity and access management, ICT asset management, and ICT security awareness.

Each of these policies must be more than a document. They must be operationalised — meaning the entity can demonstrate that the policy is implemented through technical controls, that compliance with the policy is monitored, and that deviations are detected and addressed.

Access control under Art. 9(4): The RTS is specific about access management requirements. Entities must implement the principle of least privilege, segregation of duties, and need-to-know access controls. Privileged access must be strictly controlled, monitored, and time-limited where possible. Access rights must be reviewed periodically and promptly revoked when no longer needed — particularly for staff who change roles or leave the organisation.

Encryption under Art. 9: The RTS requires encryption for data at rest and data in transit, based on the classification of the information assets and the results of the risk assessment. Key management procedures must be documented, and cryptographic controls must be periodically assessed for continued adequacy.

Change management: All changes to ICT systems must follow a defined change management process that includes risk assessment, testing, approval, rollback procedures, and post-implementation review. Emergency changes must be subject to the same controls retrospectively. This is an area where supervisors frequently find gaps — entities have a change management policy but cannot demonstrate that all changes, particularly emergency changes, actually followed it.

Detection: Article 10

Article 10 requires entities to have in place mechanisms to promptly detect anomalous activities, ICT network performance issues, and ICT-related incidents. The RTS specifies requirements for continuous monitoring, alerting, and log management.

The detection requirement connects directly to incident reporting obligations. If your detection capability is immature, your incident classification will be delayed, and your reporting timelines will be at risk. The 4-hour initial notification window under Art. 19 assumes that incidents are detected and classified rapidly — an assumption that fails if detection depends on manual observation or delayed log review.

RTS detection requirements include:

Continuous monitoring of ICT systems supporting critical or important functions
Defined detection thresholds calibrated to the entity's risk appetite and the criticality of monitored systems
Log collection and retention for all ICT systems, with logs protected against tampering and stored for a period sufficient to support incident investigation (the RTS requires a minimum retention period)
Automated alerting for events that exceed defined thresholds
Correlation capabilities that can identify patterns across multiple systems and data sources

The operational challenge is not deploying a SIEM or a monitoring platform. It is tuning detection thresholds so that the security operations function can distinguish meaningful signals from noise. An entity that generates thousands of daily alerts and investigates a fraction of them does not have a mature detection capability — it has a false sense of security. FortisEU's approach to continuous control monitoring addresses this by integrating detection with control effectiveness measurement.

Learning and Evolving: Article 13

Article 13 is the requirement that separates mature frameworks from static ones. It requires financial entities to gather information on vulnerabilities and cyber threats, ICT-related incidents, and digital operational resilience testing results, and to use this information to improve their ICT risk management framework.

This is a continuous improvement obligation. The framework must demonstrably evolve based on:

Lessons learned from ICT-related incidents and near-misses
Findings from digital operational resilience testing (both basic testing under Art. 24 and advanced testing under Art. 26)
Threat intelligence relevant to the entity's threat landscape
Information shared through ICT-related information-sharing arrangements under Art. 45
Post-incident reviews, including analysis of whether existing controls performed as designed

Supervisors assess Art. 13 compliance by looking for a documented feedback loop: incident occurs → root cause analysis → framework gap identified → control improvement planned → improvement implemented → effectiveness verified. If this loop is not visible in your records, the framework is static and Art. 13 compliance is at risk.

Practical evidence pattern: Maintain a framework change log that records every modification to the ICT risk management framework, the trigger for the change (incident, test finding, threat intelligence, regulatory update), the approval, and the implementation date. This log is your primary evidence of Art. 13 compliance.

Communication: Articles 14-16

Articles 14-16 address ICT-related communication, including crisis communication, external reporting, and information sharing with competent authorities.

Article 14 requires entities to have in place communication plans for ICT-related incidents, including: plans for disclosure to clients and counterparts, plans for communication to staff, and plans for communication to external stakeholders. These communication plans must be tested as part of the entity's broader business continuity and incident response testing.

The operational requirement that many entities miss is that communication plans must be pre-approved and ready for activation. During a major ICT incident, drafting client communications from scratch while simultaneously managing technical response and regulatory reporting creates a bottleneck that degrades all three activities. Pre-drafted communication templates — covering the most likely incident scenarios for the entity's specific risk profile — reduce this to a review-and-adapt exercise rather than a creation exercise.

What Supervisors Assess: The Maturity Gradient

Supervisory assessments of ICT risk management frameworks are not binary pass/fail evaluations. They assess maturity across a gradient, and the expectations increase over time. What was acceptable as an initial compliance effort in January 2025 is no longer sufficient fifteen months later.

Level 1 — Documentation exists: The framework is documented, approved by the management body, and covers the required domains. This was the minimum for January 2025.

Level 2 — Implementation is demonstrable: Policies are implemented through technical controls. Access management is enforced. Change management is followed. Detection is operational. Evidence exists for each requirement.

Level 3 — Effectiveness is measured: The entity does not just implement controls — it measures whether they work. Recovery times are tested and recorded. Detection coverage is quantified. Access review completion rates are tracked. Vulnerability remediation SLAs are measured.

Level 4 — Continuous improvement is visible: Incidents and tests drive framework improvements. The framework version history shows evolution. Risk assessments are updated based on new information. The management body receives actionable reporting that drives decisions.

Supervisors in 2026 expect entities to be operating between Level 2 and Level 3. Entities still at Level 1 — documentation without demonstrable implementation — should expect supervisory findings.

The Integration Challenge

The most consequential weakness in many DORA implementations is treating Articles 5-16 as a standalone compliance exercise rather than integrating the framework with operational processes. The ICT risk management framework should be the lens through which every ICT decision is evaluated — procurement decisions, change requests, incident response, capacity planning, and technology lifecycle management.

When the framework exists in a document repository and operational decisions are made through separate processes that do not reference it, the entity has two parallel realities: the framework reality (compliant) and the operational reality (uncontrolled). Supervisors detect this gap quickly, because the evidence of framework operation — logs, metrics, decisions, and change records — either exists in operational systems or it does not.

FortisEU's risk management and compliance automation platform is designed to close this gap by embedding framework controls into operational workflows, generating the evidence trail that supervisors expect, and surfacing the metrics that management bodies need for informed decision-making.

Key Takeaways

The ICT risk management framework (Art. 5-16) is the structural core of DORA — not one requirement among many. Every other DORA obligation depends on framework maturity. If the framework is a paper exercise, incident reporting, testing, and third-party management are all undermined.
Documentation is necessary but no longer sufficient. Fifteen months after go-live, supervisors expect demonstrable implementation: technical controls enforcing policies, evidence of monitoring, and metrics proving effectiveness.
The governance requirement under Art. 6 demands specificity. Management bodies must receive information specific enough to drive decisions — not generic assurance that "ICT risk is managed." Recovery times, detection metrics, vulnerability exposure, and control effectiveness are the language of DORA governance.
Asset identification under Art. 8 must connect business functions to ICT assets to risks. A risk register that does not trace from critical functions through supporting systems to specific vulnerabilities and controls is not operationally useful and will not satisfy supervisory scrutiny.
Article 13 continuous improvement is the maturity differentiator. Maintain a framework change log that documents every evolution triggered by incidents, tests, or threat intelligence. This log is your primary evidence that the framework is alive and adapting.
Integration, not documentation, is the challenge. The framework must be embedded in operational decision-making — procurement, change management, incident response, capacity planning. A framework that exists parallel to operations rather than governing them will not withstand supervisory assessment.