# DORA Gap Assessment to Ongoing ICT Risk Governance

Source: https://www.cyadviso.com/dora-ongoing-ict-risk-vs-gap-assessment
Last reviewed: 2026-07-07
Tags: DORA, ICT Risk, Gap Assessment

A DORA gap assessment is a snapshot, not a compliance programme. DORA requires a continuous ICT risk function. Learn what EU fintechs must put in place next.

---

**Last reviewed: 7 July 2026**

**Key takeaways**

- A DORA gap assessment is a point-in-time snapshot of where your ICT risk framework falls short of Articles 5–16 — it is not, on its own, a compliance programme.
- DORA requires a continuous ICT risk management function: ongoing risk identification, register updates, management body reporting, and third-party review.
- The common failure is treating the gap report as the endpoint — the register goes stale, the management body stops receiving ICT risk reporting, and the NCA examines current state, not assessment history.
- The transition to ongoing governance means assigning a named owner (internal or vCISO retainer), establishing an operational cadence, and folding gap findings into a live risk register.

---

A DORA gap assessment produces a compliance snapshot: it identifies where your ICT risk framework falls short of Articles 5–16. DORA, however, requires a continuous ICT risk management function, not periodic project-based compliance. Many EU-licensed fintechs complete a gap assessment and then face supervisory findings when their NCA reviews ongoing ICT risk governance.

The distinction matters for a practical reason: a gap assessment is a point-in-time diagnostic. It shows what is missing at the moment of assessment. DORA requires that the ICT risk management function operates continuously, identifying new risks, updating the risk register, reporting to the management body, reviewing third-party ICT providers. This is a function, not a deliverable.

For EU-licensed EMIs, Payment Institutions, and CASPs, the most common pattern that generates post-assessment supervisory findings is this: the advisory engagement ends with a gap report, a remediation roadmap, and a set of policy documents. The compliance team marks the project closed. The risk register is not updated. The management body does not receive dedicated ICT risk reporting. When the NCA arrives, the gap assessment has become historical. The ongoing function was never established.

This article explains *why* a gap assessment alone does not fulfil DORA's ongoing ICT risk governance requirement, and what the transition to a continuous function looks like in practice. For which delivery model fits — a vCISO retainer versus a one-off project — and what an ongoing engagement includes, see [choosing an ICT risk governance model →](/hiring-a-vciso).

> **Note:** For a detailed guide to what a 30-day DORA gap assessment produces and how to structure the deliverable, see [the complete 30-day DORA gap assessment guide →](/dora-gap-analysis-30-days-fintech).

---

## What a DORA gap assessment is — and what it produces

A DORA gap assessment is a structured diagnostic. An advisory firm, external vCISO, or internal team maps the entity's current ICT risk practices against DORA Articles 5–16 and the EBA ICT and Security Risk Guidelines to identify:

- which requirements are already met;
- which require new or updated documentation;
- which require operational changes (new processes, new resources, or restructured governance);
- a prioritised remediation roadmap with effort estimates and deadlines.

The output of a gap assessment is typically a findings report and a remediation plan. These are valuable. They tell the entity where it stands and what it needs to do.

What a gap assessment does not produce — and cannot produce — is the ongoing ICT risk management function. The assessment is a snapshot. The function is what runs after the snapshot.

For what a structured gap assessment deliverable looks like, see [the DORA gap assessment guide →](/dora-gap-analysis).

---

## What DORA actually requires: the ongoing function

DORA Article 5(4) states that the management body "shall keep updated knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity, including by following specific training on a regular basis."

Article 6(5) requires the ICT risk management framework to be "reviewed at least once a year as well as upon occurrence of major ICT-related incidents, and following supervisory instructions or conclusions derived from relevant digital operational resilience testing."

Article 8 requires continuous "identification of all sources of ICT risk."

The cumulative effect of these requirements is a function that operates continuously, not one that produces deliverables and closes. The management body must maintain updated ICT risk knowledge. The framework must be reviewed and updated regularly. ICT risk identification is ongoing.

A gap assessment satisfies none of these requirements on its own. It establishes a baseline. DORA requires what comes after the baseline.

---

## Gap assessment vs ongoing ICT risk governance: the core difference

| Dimension | Gap assessment | Ongoing ICT risk governance |
|---|---|---|
| **Scope** | Point-in-time mapping against DORA Articles 5–16 | Continuous identification, classification, and mitigation of ICT risks |
| **Frequency** | Once (or at specific intervals, typically annually) | Always active; no defined end state |
| **Output** | Findings report and remediation roadmap | Updated risk register, management reports, evidence package |
| **Regulatory acceptance** | Starting point: establishes baseline; does not fulfil ongoing-function requirement | Satisfies DORA's continuous ICT risk function requirement when operational |
| **Typical provider** | Advisory firm or vCISO on a project basis | vCISO retainer or in-house ICT risk function |
| **Management body role** | Receives findings report; approves remediation plan | Receives regular ICT risk reporting; makes recorded ICT risk decisions |
| **Evidence produced** | Gap register, remediation plan, updated policies | Risk register updates, incident records, management meeting minutes, third-party review logs |

The table illustrates the structural difference. An advisory project produces a deliverable and ends. An ongoing ICT risk function runs between and beyond advisory engagements.

---

## The compliance vacuum: what happens when the function is not established

After a gap assessment engagement ends, EU-licensed fintechs commonly enter what practitioners refer to as a compliance vacuum — a period where the gap report exists but the ongoing function has not been established.

During this period:

- the ICT risk register reflects the state at the time of assessment, not current risks;
- new ICT assets, cloud services, or third-party providers are adopted without being added to the risk register;
- the management body has not received ICT risk reporting since the advisory engagement concluded;
- incident classification continues informally, without the DORA-aligned taxonomy the gap report recommended;
- the remediation roadmap sits in a folder, with items partially completed.

When the NCA arrives, whether six months or two years after the assessment, they examine current state, not assessment history. A gap report does not substitute for operational evidence. A remediation roadmap does not substitute for a functioning risk register.

The compliance vacuum is not a deliberate choice. It is a structural outcome when the gap assessment is treated as the compliance programme, not the beginning of one.

{/* [HUMAN-FILL: anonymized vignette — category (EMI/PI/CASP) + regulator-as-subject + outcome, C-1 name-scan before publish. Natural slot: one anonymized case where a gap report was treated as the programme, the function lapsed, and what the supervisory review found. No client name, no fabricated numbers ([live-check]). */}

---

## What ongoing ICT risk governance looks like in practice

Under DORA, ongoing ICT risk governance involves a set of recurring activities that must be resourced and operated continuously. These are not one-time deliverables:

**Risk register maintenance:** The ICT risk register must be updated when the risk landscape changes: new ICT assets, new third-party providers, new regulatory requirements, or post-incident. An annual gap assessment cycle does not produce a current risk register. The function that maintains it must be active.

**Management body reporting:** The management body must receive regular ICT risk reports — not only at the time of a policy review. The report should cover current risk posture, recent incidents, third-party ICT developments, and remediation progress. These reports must be documented.

**Third-party ICT review cycles:** The Register of Information must be maintained and reviewed. New SaaS tools, cloud providers, and critical software vendors must be assessed and added. Concentration risk must be evaluated at least annually.

**Incident management:** When an ICT incident occurs, it must be classified against the DORA classification criteria (Article 18 and Commission Delegated Regulation (EU) 2024/1772), reported if it meets the major incident threshold (Article 19), and reviewed post-incident to update the risk framework (Article 13). This requires a function that is available when an incident occurs, not one engaged annually.

**Framework review:** The ICT risk management framework must be reviewed regularly and updated when material changes occur. This includes changes to technology architecture, third-party dependencies, regulatory requirements, and incident findings.

These activities require ongoing engagement with the entity's ICT environment. Annual assessments and advisory engagements are not enough.

---

## Moving from gap assessment to ongoing governance: the transition

The gap assessment creates the foundation. The transition to ongoing governance involves three steps:

**1. Assign ongoing ownership.** The ICT risk management function must have a named owner with the operational capacity to maintain the risk register, report to the management body, and respond to incidents. This may be an internal resource or an external vCISO on a retainer basis. For context on the hiring decision, see [choosing an ICT risk governance model →](/hiring-a-vciso).

**2. Establish the operational cadence.** Define the recurring activities: how often the risk register is reviewed, what triggers an out-of-cycle update, what the management body ICT risk reporting schedule looks like, and what the annual third-party review covers. Document this cadence so it can be demonstrated to an NCA.

**3. Integrate the gap findings into the live function.** The remediation roadmap from the gap assessment should feed into the ongoing function, not sit in a separate document. Open items from the assessment should appear in the risk register and management reporting until they are resolved.

[Latvijas Banka, the Latvian National Competent Authority](/dora-bank-of-latvia), like other EU NCAs, examines whether the ICT risk function is genuinely operational when conducting supervisory reviews. A gap report without an operational function does not satisfy the supervisory expectation.

---

## Frequently asked questions

### Is a one-off DORA gap analysis enough for ongoing compliance?

No. A gap analysis identifies shortfalls against DORA Articles 5–16 at a point in time. It does not substitute for the ongoing ICT risk management function DORA requires. Supervisors examine whether the function operates continuously, whether the risk register is current, whether the management body receives regular ICT risk reporting, and whether incidents are classified and reviewed. A gap report satisfies none of these requirements on its own.

### What should a fintech do after completing a DORA gap assessment?

After a gap assessment, the fintech must transition from a remediation project to a continuous ICT risk governance function. Specifically: assign ongoing ownership of the ICT risk management function (internal or vCISO retainer), establish a recurring management body reporting cadence, integrate gap findings into a live risk register, and define the process for maintaining the Register of third-party ICT providers. The gap report is the starting point, not the endpoint. See [choosing an ICT risk governance model →](/hiring-a-vciso) for structuring the ongoing function.

### What is the difference between a DORA gap analysis and ICT risk governance?

A gap analysis is a diagnostic: it shows what is missing against DORA's requirements at a point in time. ICT risk governance under DORA is the ongoing function that identifies, classifies, and mitigates ICT risks continuously. The gap analysis tells you where the gaps are. The governance function fills and maintains them. Treating the gap assessment as the compliance programme is the most common pattern when fintechs receive supervisory findings after an advisory engagement.

### How often should the DORA ICT risk framework be reviewed?

DORA Article 6(5) requires review "at least once a year" and additionally following major ICT incidents, following supervisory instructions, or following relevant digital operational resilience testing conclusions. In practice, this means a formal annual review cycle with additional triggered reviews. The risk register should be updated more frequently — typically quarterly, or whenever material ICT changes occur. "At least once a year" is the regulatory floor, not the recommended cadence for a functional ICT risk management programme.

---

## How CyAdviso supports the transition to ongoing ICT risk governance

CyAdviso works with EU-licensed fintechs that have completed a gap assessment or identified a compliance vacuum to establish the ongoing ICT risk management function. Based on engagements under EU financial-sector supervision, the work typically involves:

- reviewing existing gap assessment findings and remediation status;
- designing the ongoing governance structure: risk register cadence, management body reporting, incident management process;
- acting as the ongoing ICT risk function owner (vCISO retainer) or supporting an internal owner's setup;
- producing the evidence package that satisfies NCA supervisory expectations.

The goal is a functional ICT risk management structure that continues to operate between assessments, not one that resets every time an advisory project ends.

To discuss the transition from gap assessment to ongoing governance, [schedule a consultation with CyAdviso](https://cal.com/andrey-gubarev/15min) or contact us at info@cyadviso.com.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-ongoing-ict-risk-vs-gap-assessment