DORA ICT Risk Ownership: Why Compliance Alone Falls Short

In this article ↓

1. What DORA requires: the ICT risk management framework under Articles 5–16
2. What the compliance function covers — and where it stops
3. The ICT risk management function: what DORA Articles 8–16 require operationally
4. What supervisors examine: the ICT risk function under scrutiny
5. The common pattern: absorbed ownership without operational capacity
6. Frequently asked questions
7. Does DORA require a dedicated ICT risk officer?
8. Can a compliance officer handle DORA ICT risk management?
9. What is the difference between the compliance function and ICT risk management under DORA?
10. What should the management body document to evidence ICT risk ownership?
11. How CyAdviso structures the ICT risk function for supervisory readiness

Last reviewed: 23 June 2026

---

Under DORA, the management body is accountable for approving and overseeing the ICT risk management framework (Article 5(2)). The compliance function, even a well-resourced one, cannot substitute for a dedicated ICT risk owner. That distinction matters. It is also the source of the most common governance finding in early DORA supervisory reviews.

For a CEO, this is not an abstract governance point. When an NCA finds nominal ownership, accountability under Article 5 does not sit with the compliance team — it sits with the management body. The exposure is personal before it is organisational.

DORA Articles 5 through 16 define the ICT Risk Management Framework: not as a document, but as a function that must be assigned, resourced, and operated continuously. A compliance officer monitors regulatory adherence. ICT risk management requires ongoing identification, classification, and mitigation of ICT threats. That is a distinct operational function. It does not run on a policy review schedule.

For EU-licensed fintechs operating as EMIs, Payment Institutions, or CASPs, conflating these two functions is one of the most common patterns that generates supervisory findings. The policy exists. The compliance team has reviewed it. The NCA arrives and finds that the ICT risk management framework has operated in name only.

Below: what DORA requires of the ICT risk function, why a compliance officer cannot absorb that function without dedicated operational capacity, and what a functional structure looks like under supervisory scrutiny. This article sets out the anatomy of ownership — who is accountable and what the function must do. Whether that owner needs a dedicated ICT Risk Officer job title is a separate question, covered in does DORA require a dedicated ICT risk officer? →.

---

What DORA requires: the ICT risk management framework under Articles 5–16

DORA Title II (Articles 5–16) establishes the ICT Risk Management Framework as a mandatory governance structure for all EU financial entities within scope. The framework defines not only what must exist on paper, but what must operate continuously.

The ownership chain is explicit. Article 5(2) places ultimate accountability on the management body. The board must approve the ICT risk management framework, define risk appetite, and ensure adequate resourcing. Article 5(4) adds a harder requirement: the management body must maintain updated knowledge of ICT risks. Updated, in supervisory practice, means regular engagement. Not an annual sign-off on a policy document that IT prepared.

Article 6(1) requires a framework that is "sound, comprehensive and well-documented." EBA supervisory guidance is clear on what "sound" means: the framework must actually operate. A document that sits in a folder is not a sound framework. Article 6(4) then requires it to be reviewed and updated regularly, or following material incidents, supervisory instructions, or relevant digital operational resilience testing. There is no stable endpoint. The review obligation is continuous.

The result is a framework that must be actively owned and continuously operated. Ownership cannot sit with a function that audits compliance periodically. It requires someone engaged with the entity's ICT environment on an ongoing basis.

---

What the compliance function covers — and where it stops

The compliance function under EU financial regulation monitors whether the entity adheres to its regulatory obligations. A compliance officer:

• maps applicable regulations and translates them into internal policies and procedures;
• monitors processes and controls for regulatory adherence;
• reports compliance breaches and near-misses to senior management;
• maintains relationships with NCAs on regulatory queries;
• tracks regulatory developments and updates internal frameworks accordingly.

This is a monitoring and advisory function. It answers the question: "Are we doing what regulations require?" ICT risk management under DORA answers something different: "What could go wrong with our technology right now, and what are we doing about it?"

A compliance officer can confirm that an ICT risk management framework document exists and that it has been reviewed against DORA requirements. They cannot own the ongoing identification and mitigation of ICT threats unless separately qualified, resourced, and engaged with the entity's live technical environment.

DORA does not prohibit a compliance officer from fulfilling both roles. It does require that both functions are genuinely exercised. Where a compliance team absorbs ICT risk management as an additional task without the operational capacity to execute it, the framework fails the "sound" test under Article 6(1).

---

The ICT risk management function: what DORA Articles 8–16 require operationally

DORA's requirements for the ICT risk management function go well beyond policy maintenance.

Article 8 requires continuous identification and classification of ICT assets and the risks affecting them. This is not a once-a-year exercise. It demands ongoing engagement with the entity's technology architecture: servers, applications, cloud services, vendor dependencies. Article 9 adds security measures, access controls, and ICT policies that must be updated as the threat environment changes. Article 10 requires mechanisms to detect anomalous activity and potential incidents, which means technical monitoring systems need to be active and regularly reviewed.

The response layer runs through Articles 11 and 12: business continuity and incident response plans with clear activation criteria and tested recovery capabilities. These are not policy documents. They are operational plans. They must be tested. Supervisors will ask for test records. Article 13 then requires post-incident review processes that feed findings back into the risk framework, creating a feedback loop that keeps the framework current rather than historical.

Article 28 rounds out the function: a register of all third-party ICT providers, assessment of concentration risk, and contractual clauses aligned to DORA requirements. That register does not maintain itself. Someone has to track new vendors as they are adopted, review contracts on renewal, and assess what happens if a critical cloud provider fails across multiple functions simultaneously.

Each of these is an operational activity. It requires sustained engagement with the entity's ICT environment. A compliance officer who is not separately resourced for these tasks cannot fulfil them. Not because of unwillingness, but because these tasks require dedicated time and ongoing technical involvement.

---

What supervisors examine: the ICT risk function under scrutiny

When a National Competent Authority reviews an EU-licensed fintech under DORA, they examine whether the ICT risk management framework is functional, not whether it exists. The supervisory examination typically covers:

• Who is the named owner of the ICT risk management framework? What is their reporting line to the management body?
• Is the ICT risk register current? When was it last updated? What process maintains it between assessments?
• Does the management body receive regular ICT risk reporting, separate from compliance reporting? Are ICT risk decisions documented?
• Are ICT incidents classified against the DORA severity taxonomy (Article 17)? Who makes the classification decision, and when?
• Is the Register of third-party ICT providers maintained per Article 28? Has concentration risk been assessed?

The NCA is not checking whether the risk register exists. They are checking whether it reflects the current risk environment. That requires a function that remains active between supervisory reviews, not one that is engaged only when a notice arrives.

Nominal ownership without operational reality is among the most common findings in early DORA supervisory reviews across EU-licensed fintechs.

For related patterns, see the common DORA compliance mistakes → for Mistake #1, which covers the ownership confusion. The DORA board responsibilities checklist → covers how the management body should document its oversight of the ICT risk function. For precise terminology, the DORA glossary → defines the ICT Risk Management Framework and related roles.

Jurisdiction-specific supervisory expectations: Latvijas Banka, the Latvian National Competent Authority, and Lietuvos bankas, the Lithuanian National Competent Authority, have both issued supervisory expectations consistent with DORA Title II and EBA ICT Risk Guidelines.

---

The common pattern: absorbed ownership without operational capacity

The most common pattern CyAdviso encounters with EU-licensed fintechs is this: a compliance officer with strong regulatory knowledge is asked to add ICT risk management to their existing responsibilities. The gap assessment is completed. The policy is written. The compliance team reviews the framework annually.

When the NCA arrives, the picture is consistent. The ICT risk register reflects the state at the time of the advisory engagement, not the current environment. There is no evidence of ongoing risk identification under Article 8. ICT incident classification is handled by IT operations, with no documented governance link to the named risk owner. The management body has received compliance reporting, but not dedicated ICT risk reporting. The compliance officer, when asked about current third-party ICT dependencies, cannot answer because no one has been tracking them since the advisory engagement closed.

This generates findings. The compliance officer did not fail. DORA requires an operationally active function, not an additional compliance task assigned to an already-loaded team.

The solution is not necessarily a full-time hire. An external vCISO acting as ICT risk function owner can satisfy DORA Article 5 if the management body retains accountability and the function operates continuously. What DORA prohibits is the nominal designation without operational reality.

---

Frequently asked questions

Does DORA require a dedicated ICT risk officer?

DORA Articles 5–16 require a documented ICT risk management function overseen by the management body. DORA does not mandate a specific job title or require a full-time internal hire. The function must be clearly assigned, adequately resourced, and operationally active, not absorbed into an existing compliance role without capacity to execute the Articles 8–16 requirements. An external vCISO can fulfil the function if the management body retains accountability.

Can a compliance officer handle DORA ICT risk management?

A compliance officer can support ICT risk activities and monitor adherence to the ICT risk management framework. However, they cannot own the ICT risk management framework in name alone. DORA Article 5 places ultimate accountability at management body level, and Articles 8–13 require ongoing operational engagement with ICT assets, threats, and incidents. A compliance officer who is separately resourced and technically equipped could fulfil both roles. A compliance team absorbing ICT risk as an additional task without operational capacity cannot.

What is the difference between the compliance function and ICT risk management under DORA?

Compliance monitors regulatory adherence: it answers "are we doing what regulation requires?" ICT risk management under DORA (Articles 5–16) requires ongoing identification, classification, and mitigation of ICT threats. It is a technical and operational function that must run continuously. Compliance can confirm the ICT risk framework exists. ICT risk management ensures it operates. Supervisors examine both: whether the framework exists (compliance scope) and whether it functions (ICT risk scope).

What should the management body document to evidence ICT risk ownership?

The management body should document: formal approval of the ICT risk management framework (Article 5(2)); regular ICT risk reporting received from the ICT risk function, separate from compliance reporting; recorded management body decisions on material ICT risks; annual or triggered review of the framework (Article 6(4)); evidence of adequate resourcing of the ICT risk function. For a structured checklist, see the DORA board responsibilities guide →.

---

How CyAdviso structures the ICT risk function for supervisory readiness

CyAdviso works with EU-licensed fintechs — EMIs, Payment Institutions, and CASPs — to design and operate the ICT risk management function under DORA. Based on engagements under EU financial-sector supervision, the work typically involves:

• assessing whether the current compliance and ICT structures genuinely separate the two functions;
• defining the ICT risk function's scope, accountability, and reporting line to the management body;
• establishing the operational cadence: risk register maintenance, incident classification, third-party review cycles;
• building the evidence package that satisfies NCA supervisory expectations.

The outcome is a functional ICT risk management structure, not a policy document that generates findings on first review.

To discuss how your fintech can structure the ICT risk function under DORA, schedule a consultation with CyAdviso or contact us at info@cyadviso.com.