DORA ICT Risk Governance Between Big4 Advisory Projects

In this article ↓

1. Why the gap creates a compliance exposure under DORA
2. What must remain active between advisory projects
3. How to structure ICT risk governance between Big4 engagements
4. Step 1: Assign named ownership before the advisory engagement closes
5. Step 2: Define the minimum maintenance cadence in the handover package
6. Step 3: Establish a management body reporting cycle
7. Step 4: Maintain incident classification governance
8. Step 5: Define the re-engagement trigger
9. What the NCA sees when the inter-project period is not structured
10. Frequently asked questions
11. Does DORA require ongoing ICT risk governance between advisory projects?
12. Who should own the ICT risk function when an advisory engagement ends?
13. What is the minimum governance activity required between Big4 DORA engagements?
14. Can a vCISO retainer cover the period between Big4 advisory engagements?
15. How CyAdviso structures inter-project ICT risk governance

Last reviewed: 18 August 2026

---

When a Big4 DORA advisory engagement closes, the deliverable arrives: a gap assessment report, a remediation roadmap, a set of updated policies. The project account closes. The advisory team moves to the next client.

The ICT risk management obligation does not close. DORA requires EU-licensed fintechs to maintain an ICT risk management function on an ongoing basis. The management body remains accountable for overseeing that function continuously (Article 5(2)). The ICT risk register, incident classification governance, and third-party oversight procedures must continue to operate, regardless of whether an advisory team is engaged.

The period between Big4 engagements is where the most common supervisory findings originate. The risk register reflects the state at the time of the last advisory project. Incident classification is informal. The management body has not received ICT risk reporting since the engagement closed. When the NCA arrives, it finds a function that existed on paper at the time of an advisory project but has not operated since.

This article explains how EU-licensed fintechs can structure ICT risk ownership during the period between advisory projects, what minimum governance activities must continue, and what the management body needs to document to evidence ongoing function under DORA.

This article is the practical case of a wider principle: why an episodic engagement cannot satisfy DORA's continuous function requirement. For that underlying argument and the snapshot-versus-function distinction, see DORA gap assessment and ongoing ICT risk governance →. The focus here is the specific interval after a Big4 advisory project closes, and how to keep the function operating across it.

---

Why the gap creates a compliance exposure under DORA

DORA Article 5(4) requires the management body to maintain "updated" knowledge of ICT risks. That word, updated, carries supervisory weight. It means the knowledge must be current at the time of examination, not at the time of the last advisory project.

Article 6(1) requires the ICT risk management framework to be "sound, comprehensive and well-documented." EBA supervisory guidance treats sound as meaning the framework must actually operate, not merely exist on paper. A framework documented in an advisory engagement that has not been updated since fails this test.

Article 8 requires continuous identification and classification of ICT assets and risks. Article 10 requires anomaly detection to be active. Article 13 requires post-incident review processes. None of these functions are satisfied by a report delivered six months ago.

The structural problem is that Big4 advisory projects are designed to produce a snapshot: where the entity is today against DORA requirements. They diagnose the gap. They document the remediation. They train the team. Then they leave. The ongoing function must be owned internally or by a retained external provider. Without that, the interval between projects is a compliance gap.

---

What must remain active between advisory projects

Not everything in the DORA framework requires the same operational intensity between advisory engagements. Some elements require active maintenance; others can operate at reduced cadence with clear ownership.

Active at all times:

ICT risk register: The register of ICT assets and associated risks (Article 8) must reflect the current environment. New systems adopted after the advisory engagement ended must be added. Vendor changes must be captured. The register does not maintain itself.

Incident classification and governance: When an ICT incident occurs, the entity must classify it according to the DORA classification criteria (Article 18) and apply the appropriate response and reporting obligations. This process cannot wait for an advisory team to re-engage.

Third-party ICT provider oversight: The register of third-party ICT providers (Article 28(3)) must remain current. New providers, renewed contracts, material changes to existing providers: all must be captured and assessed.

Management body reporting: The management body must receive regular ICT risk reporting (Article 5(2)). A six-month gap followed by an advisory engagement report is not regular reporting.

Operating at defined cadence:

Framework review cycles: The full review of the ICT risk management framework (Article 6(5)) operates at least annually, and additionally following major ICT incidents, supervisory instructions, or testing or audit conclusions, not continuously. But those cycles must be scheduled and tracked.

Testing programme: The ICT testing programme (Articles 24-27) operates on defined cycles. But those cycles must be scheduled, documented, and reported to the management body.

---

How to structure ICT risk governance between Big4 engagements

The following steps describe a minimum structure that keeps the ICT risk function operational between advisory projects without requiring ongoing advisory fees at the same intensity as a gap assessment or full policy build.

Step 1: Assign named ownership before the advisory engagement closes

Before the Big4 engagement concludes, the management body must formally assign ICT risk function ownership to a named individual or external provider. This is the most consistently overlooked step. Advisory teams deliver their reports, present recommendations, and leave. The question of who owns the function after they leave is often not resolved explicitly.

The named owner can be internal or an external retained vCISO. What matters is that the assignment is documented, the management body has formally approved it, and the reporting line is clear.

Step 2: Define the minimum maintenance cadence in the handover package

The advisory engagement should produce a maintenance schedule as part of the handover: what activities must happen, at what frequency, and who is responsible. For each item in the ICT risk register, what triggers an update? For third-party providers, what is the review cycle?

If the advisory team did not produce this, the entity should request it before the engagement closes. Without it, the period after the project ends is effectively ungoverned.

Step 3: Establish a management body reporting cycle

The management body must receive ICT risk reporting between advisory engagements. Monthly reporting on significant risk items is a reasonable minimum for most fintechs. Quarterly is the outer limit for lower-complexity entities.

The format can be a brief structured update: current state of the risk register, any incidents classified since the last report, any changes to the third-party provider environment, and any open items from the advisory recommendations. This keeps the management body's knowledge current, which is what Article 5(4) requires.

Step 4: Maintain incident classification governance

The entity needs a defined process for classifying incidents between advisory engagements. This does not require an advisory team. It requires a decision framework: who receives the initial incident report, who applies the DORA classification criteria, who decides whether it meets the reporting threshold.

If that process is not defined, the first ICT incident after an advisory engagement ends will be handled informally, with no audit trail.

Step 5: Define the re-engagement trigger

The entity should agree in advance what circumstances require a return to advisory intensity. Defined triggers include: a regulatory change affecting the ICT risk framework, a material ICT incident, a significant change to the technology environment, or preparation for a supervisory review. Without a defined trigger, the re-engagement decision is made reactively, often after a problem has already materialized.

---

What the NCA sees when the inter-project period is not structured

When a National Competent Authority reviews an EU-licensed fintech's ICT risk framework, it examines whether the function has been continuous, not just whether it was adequate at the time of an advisory report. The questions are specific:

When was the ICT risk register last updated? What was the trigger for that update? Who made the update, and who approved it?

Has the management body received ICT risk reporting since the last major advisory engagement? Can the entity show meeting records, report distributions, and documented management body responses?

Has any ICT incident occurred since the last framework review? How was it classified? Who made the classification decision?

A fintech that completed a thorough Big4 DORA gap assessment but allowed the function to go unmanaged for eight months between projects will face findings on continuity, even if the initial assessment was sound. The NCA is not examining the quality of the advisory output. It is examining the state of the function today.

Fintechs supervised by Latvijas Banka, the Latvian National Competent Authority and those supervised by Lietuvos bankas, the Lithuanian National Competent Authority are subject to the same DORA continuity requirements as fintechs elsewhere in the EU. For a practical view of the hiring decision when establishing a retained external ICT risk function, see the guide to hiring a vCISO. For what a gap analysis covers and what it leaves open, see what a DORA gap analysis includes.

---

Frequently asked questions

Does DORA require ongoing ICT risk governance between advisory projects?

Yes. DORA requires the ICT risk management function to operate on an ongoing basis. An advisory engagement may build or update the framework, but it does not fulfil the continuous function requirement. The function must remain active, with a named owner and regular management body reporting, between any advisory projects. A gap in operation is a gap in compliance, regardless of the quality of the advisory work that preceded it.

Who should own the ICT risk function when an advisory engagement ends?

The management body must assign named ownership before the advisory engagement closes. The owner can be an internal role or an external retained vCISO. What matters is that the assignment is documented and approved by the management body, and that the named owner has the operational capacity to maintain the minimum activities described in Articles 8, 10, 13 and 28 between reviews.

What is the minimum governance activity required between Big4 DORA engagements?

At minimum: maintaining an up-to-date ICT risk register; classifying and documenting any ICT incidents that occur; keeping the third-party ICT provider register current; and providing the management body with regular ICT risk reporting. These are not optional between advisory projects. They are the continuous function DORA requires.

Can a vCISO retainer cover the period between Big4 advisory engagements?

An external vCISO can fulfil the DORA ICT risk function if the management body retains accountability and the function operates continuously. A vCISO on a light retainer covering minimum maintenance activities is a common structure for EU-licensed fintechs that use advisory firms for periodic framework reviews. The two models are complementary: advisory projects for assessment and policy builds, retained vCISO for ongoing ownership between those projects.

---

How CyAdviso structures inter-project ICT risk governance

CyAdviso works with EU-licensed fintechs that use advisory firms for periodic DORA framework reviews. Based on engagements under EU financial-sector supervision, the inter-project period is one of the most common sources of supervisory findings. Our approach:

• agreeing the minimum maintenance schedule with the advisory team before they close the engagement;
• taking over named ICT risk function ownership at handover;
• maintaining the risk register, incident classification governance, and third-party oversight on behalf of the management body;
• delivering regular ICT risk reporting that keeps the management body's knowledge current in line with Article 5(4).

The goal is continuity without gaps. Advisory projects build and update the framework. The retained function keeps it operational between those projects.

To discuss how your fintech can maintain DORA-compliant ICT risk governance between advisory projects, schedule a consultation with CyAdviso or contact us at info@cyadviso.com.