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. Questions an NCA may ask 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's governance and ICT-risk-framework articles, taken together (Article 5 oversight, Article 6(5) review cadence, Article 8 continuous identification), function as a de-facto continuity requirement for EU-licensed fintechs, though no single article names a standalone continuous ICT risk management function. 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.

In our client work, we repeatedly see supervisory findings originate in the period between Big4 engagements. 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

None of these articles individually mandates a standalone continuous function; together, they leave no gap where ICT risk oversight can lapse.

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 makes this moment specific: unlike a general gap assessment, a Big4 advisory engagement ends on a contractual date, hands over a named deliverable set (a gap assessment report, a remediation roadmap, a set of updated policies), and the outgoing team has no further obligation once the contract closes. The open questions are not whether the entity has a gap assessment on file, but who takes the handover package, on what date, and what would trigger re-engaging Big4 or another provider.

---

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 inventory: Article 8 requires identifying, classifying, documenting and continuously monitoring ICT-supported functions and assets; in practice, most entities evidence this through a maintained ICT risk register that reflects 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)), using the standard templates set out in Commission Implementing Regulation (EU) 2024/2956, must remain current. New providers, renewed contracts, material changes to existing providers: all must be captured and assessed.

Management body reporting: senior ICT staff report to the management body at least yearly under Article 13(5), with Article 5(2) establishing the underlying oversight responsibility. 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 to the management body is a reasonable minimum in our advisory practice; quarterly is the outer limit we would recommend. This is a CyAdviso governance recommendation, not a DORA-mandated cadence: the only explicit reporting-cadence requirement in this cluster is Article 13(5), which sets a minimum of at least yearly for senior ICT staff findings-reports to the management body.

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.

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.

---

Questions an NCA may ask 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, though not as a single named requirement. DORA's governance and risk-management articles, taken together (Article 5 oversight, Article 6(5) review cadence, Article 8 continuous identification), function as a de-facto continuity requirement. A Big4 advisory engagement produces a point-in-time deliverable; it does not, by itself, keep that ongoing function running once the engagement closes. 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. DORA's Article 8 requires financial entities to identify, classify and document ICT-supported functions and assets on a continuous basis, and to maintain risk inventories. It does not name a specific artifact called an "ICT risk register": in practice, most entities evidence this obligation through a maintained ICT risk register.

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

An external vCISO can operate the day-to-day ICT risk function and, under Article 6(10), take on compliance-verification tasks on the entity's behalf, subject to applicable Union and national sectoral law. Accountability for the control function (Article 6(4)) and management-body oversight (Article 5) stays with the entity; it is not outsourced. 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, consistent with the oversight duty in Article 5(4) and the at-least-yearly reporting minimum in Article 13(5).

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.