DORA's Lead Overseer Inspects Your Provider, Not You: So Who Generates the Evidence That You Acted on the Findings?

The regulator with the deepest reach into your most critical vendor will never knock on your door.

It can walk into their operation centre, seal a room if it needs to, and read the systems your business actually runs on.

Then it writes to your supervisor, and the follow-up work becomes yours.

That asymmetry is the whole shape of the EU oversight regime for critical ICT third-party service providers. Every investigative power points at the provider. Every consequence lands on the financial entity. Most third-party risk programmes are still built as if the assessor in this relationship is you, assessing your vendor. Under this regime, a far better-resourced assessor has already been inside, and you will never see their working papers.

What you will see is a risk passed down to you and a clock.

Whose Systems Does DORA's Oversight Framework Actually Reach Into?

The Oversight Framework sits over designated critical ICT third-party service providers. It does not sit over you.

Article 39(1) lets the Lead Overseer, assisted by the joint examination teams, enter and conduct all necessary onsite inspections on "any business premises, land or property" of the provider, "such as head offices, operation centres, secondary premises", as well as off-site inspections. Article 39(2) gives the authorised officials power to enter those premises and to seal "any such business premises, books or records" for as long as the inspection needs.

Then read the scope line. Article 39(4): inspections "shall cover the full range of relevant ICT systems, networks, devices, information and data either used for, or contributing to, the provision of ICT services to financial entities."

Not systems dedicated to you. Systems contributing to.

The reach extends past the Union. Article 36 lets the Lead Overseer exercise those powers on premises in a third country, subject to four cumulative conditions: the inspection is necessary to perform its duties, it is directly related to services provided to Union financial entities, the provider consents, and the third-country authority has been notified and raised no objection. Consent is the load-bearing condition. Where the Lead Overseer cannot conduct those activities, Article 36(3) has it act on the facts and documents available and document the consequences of that inability, which then feed into its recommendations.

One contrast worth naming once. The register of information you maintain under Article 28(3) is what you hand up to your competent authority. It is not what the Overseer produces, and it is not what comes back down.

What Can the Lead Overseer Compel From a Critical Provider, and What Can It Never Ask You For?

Article 37(1) lets the Lead Overseer require, by simple request or by decision, "all information that is necessary" including business and operational documents, contracts, policies, ICT security audit reports, ICT-related incident reports, and "any information relating to parties to whom the critical ICT third-party service provider has outsourced operational functions or activities."

That final clause is provider-of-provider depth. It is a view into the chain below your vendor that your own contract may not give you.

Article 38(2) adds the investigation powers: examine records, data and procedures "irrespective of the medium on which they are stored", take certified copies, summon representatives for oral or written explanations and record the answers, interview consenting persons, and request records of telephone and data traffic.

Article 35(6) to (8) supplies the compulsion. Periodic penalty payments, imposed daily until compliance, for no more than six months, of up to 1% of the provider's average daily worldwide turnover in the preceding business year.

Now look at who is on the receiving end of every one of those. The provider. Not one of those powers produces a document addressed to you or a record you can drop into your own evidence file.

What flows toward your side is notice, not product. Article 38(5) and Article 39(3) require the Lead Overseer to inform the competent authorities of the financial entities using that provider in good time before an investigation or inspection. The competent authorities. Not you.

If the Overseer Never Assesses Your Firm, Why Does the Finding Still Land on Your Desk?

Because the regime was designed to move the finding, not the inspection.

Article 40(1) and (2) establish a joint examination team for each critical provider, staffed from the ESAs, from the competent authorities supervising the financial entities the provider serves, and on a voluntary basis from national competent authorities, all under a designated Lead Overseer coordinator. Members are required to have expertise in ICT matters and in operational risk.

Article 40(3): within three months of the completion of an investigation or inspection, after consulting the Oversight Forum, the Lead Overseer adopts recommendations addressed to the provider. Article 40(4): those recommendations are immediately communicated to the provider and to the competent authorities of the financial entities it serves.

Then the handoff. Article 42(3) requires competent authorities to inform the relevant financial entities of the risks identified in those recommendations, and states that "when managing ICT third-party risk, financial entities shall take into account the risks referred to in the first subparagraph."

Sitting behind all of it, Article 28(1)(a): a financial entity using contractual arrangements for ICT services "shall, at all times, remain fully responsible" for compliance with its obligations.

So the chain runs like this:

→ an inspection you did not attend → of systems you have no right to audit → conducted by a team you are not on → producing a finding you did not write → that becomes an obligation you must evidence

Five steps, and you only control the last one.

What Runs in the 60 Days After a Recommendation Reaches Your Competent Authority?

Two 60-day clocks, and they belong to different parties. Compliance teams routinely conflate them.

The provider's clock is DORA Article 42(1). Within 60 calendar days of receiving the recommendations, the critical provider must either notify the Lead Overseer of its intention to follow them or give a reasoned explanation for not following them. Article 42(2) then allows public disclosure, naming the provider and the type and nature of the non-compliance, where it fails to notify or where its explanation is not deemed sufficient.

Your clock is Article 42(4). Where a competent authority deems that a financial entity fails to take into account, or to sufficiently address within its management of ICT third-party risk, the specific risks identified in the recommendations, it notifies the entity of the possibility of a decision being taken within 60 calendar days of receipt of that notification, "in the absence of appropriate contractual arrangements aiming to address such risks."

Read the exit ramp the text actually names. It is contractual arrangements addressing the risk. Not a policy update. Not an internal memo dated after the notification arrived.

The decision at the end is Article 42(6): as a measure of last resort, competent authorities may require a financial entity to temporarily suspend, in part or completely, the use of the service, and where necessary to terminate the relevant contractual arrangements. Article 42(8) softens the landing by requiring authorities to grant the time needed to adjust contracts and to deploy exit strategies and transition plans as referred to in Article 28. It does not make the plan for you.

Note who gets the earliest warning of all. Article 35(3) gives the provider 30 calendar days to submit information before recommendations are even issued. By the time a risk reaches your desk, the provider has already had a hearing you were not part of.

Can the Overseer Block Your Provider's Next Subcontract, and Would You Even See It?

ICT subcontracting is where the information asymmetry gets sharpest.

Article 35(1)(d)(iii) lets the Lead Overseer issue recommendations on "any planned subcontracting", including arrangements the provider plans to enter into with providers or ICT subcontractors established in a third country, where it deems the further subcontracting may trigger risks for the provision of services by the financial entity or risks to financial stability, based on information gathered under Articles 37 and 38.

Article 35(1)(d)(iv) goes further, recommending that the provider refrain from entering a further subcontracting arrangement where three cumulative conditions hold: the envisaged subcontractor is established in a third country, the subcontracting concerns critical or important functions of the financial entity, and the Lead Overseer deems it poses a clear and serious risk to the financial stability of the Union or to financial entities, "including to the ability of financial entities to comply with supervisory requirements."

And the plumbing that feeds it: providers transmit their subcontracting information to the Lead Overseer using the template developed under Article 41(1), point (b).

Direction matters here. The structured subcontracting picture moves upward, to the Overseer. Your view of tier two and tier three still depends on your contract and on what your provider chooses to tell you. The recommendation is addressed to the provider, and under Article 42(1) the provider is entitled to decline it with a reasoned explanation.

Meanwhile Article 39(7) makes your contract the lever for their behaviour: where a provider opposes an inspection, the Lead Overseer informs it of the consequences, including the possibility that competent authorities require financial entities to terminate their contractual arrangements with that provider.

Your contract is an instrument of someone else's enforcement. That is a good reason to know exactly what is in it.

Which Lens Should You Be Building: an External Assessor Crawling Your Supply Chain, or Attested Signal From Inside Your Own Perimeter?

There are only two architectures on offer, and the regime above rules one of them out.

The first is the external assessor. More questionnaires, more scanners, more third-party agents given standing access into your stack so a vendor platform can tell you about your vendors. It is an attempt to rebuild, from outside, a lens that a joint examination team with entry powers, sealing powers and traffic-record powers already holds. You will not out-inspect the Lead Overseer. You will just add another party with credentials into your environment, at exactly the moment a 2026 CISO is being told to shut that exposure down.

The second is attested signal from inside your own perimeter. The lens you genuinely control covers your obligations, your contracts, your dependencies and your evidence. So run the labour there. Your own agents, under your IAM, your logging and your DLP, discover which business functions the provider supports, which contractual clauses exist and which are missing, which controls are live and which are asserted. They push attested signal back. No credential ever leaves your boundary.

That only works if the thing receiving the signal is deterministic. At Aigis, regulations are ingested through a pipeline that produces structured compliance data with every obligation traced to a verbatim quote from the legal text. Grounded in source law, not generated from a model's memory. One organizational profile maps deterministically against 245+ regulations across 28 jurisdictions, with overlap between DORA, NIS2 and GDPR resolved rather than re-answered.

The determinism is not a nice property. It is the precondition. An invented citation or a hallucinated control is precisely what collapses under an Article 42(4) conversation with your competent authority.

Your agents do the work. Our engine keeps it honest. Automation without exposure. Bring your own agent, Claude Code or any MCP client, over the platform's MCP and API surface.

What Does "Taking the Risk Into Account" Look Like as Standing Evidence Rather Than a One-Off Memo?

Article 42(3) gives you a verb with no format. Your competent authority will decide, under Article 42(4), whether you sufficiently addressed the risk. Build the artifact that answers that question before the notification arrives.

→ The identified risk bound to the canonical obligation it touches, not filed as a PDF attachment → The affected contractual arrangements named, with clause-level status against what Article 42(4) calls appropriate contractual arrangements → An owner per domain, timestamped, rather than a shared compliance inbox → Compensating controls with evidence referenced from systems you already run, so the reviewer confirms rather than collects → The exit strategy and transition plan already drafted, because Article 42(8) assumes one exists → Every line dated, immutable, and queryable

The audit pack becomes a query, not a project. That is the difference between explaining what you intend to do and showing what you already did, on a dated record. A posture you can defend in front of a regulator, a board, or a plaintiff.

If you are an EU financial entity mapping this by hand across your provider estate, start with third-party risk and see how the obligations bind to your risk register. Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.

FAQ: DORA Lead Overseer and Critical ICT Third-Party Provider Oversight

Does the DORA Lead Overseer inspect financial entities? No. The information, investigation and inspection powers under Articles 37, 38 and 39 are exercised in respect of designated critical ICT third-party service providers. Your firm remains supervised by its own competent authority, and under Article 28(1)(a) remains fully responsible at all times for its obligations.

What must a financial entity do when its competent authority passes on risks identified in a recommendation? Article 42(3) requires competent authorities to inform relevant financial entities of the risks identified, and requires those entities to take those risks into account when managing ICT third-party risk. Article 42(4) is where insufficiency is judged, with contractual arrangements addressing the risk named as the relevant remedy.

Can a supervisor force us to stop using a critical ICT third-party service provider? Article 42(6) allows a competent authority, as a measure of last resort, to require temporary suspension of the use of the service in part or completely, and where necessary termination of the contractual arrangements. Article 42(8) requires authorities to grant the time needed to adjust contracts and deploy exit strategies and transition plans.

Does the Lead Overseer see ICT subcontracting we cannot see? Often, yes. Article 37(1) reaches "any information relating to parties to whom the critical ICT third-party service provider has outsourced operational functions or activities", and Article 41(1), point (b) provides for a template through which providers transmit subcontracting information to the Lead Overseer. Your own visibility below tier one depends on what your contract secures.