Article 40: Ongoing oversight

Article 40’s ongoing oversight requirement means you must be ready to support EU oversight of any critical ICT third-party service provider through coordinated examinations led by a “Lead Overseer” and carried out with a joint examination team. Operationalize it by defining a regulatory-response workflow, assigning clear owners, and maintaining inspection-ready evidence packs mapped to oversight requests. (Regulation (EU) 2022/2554, Article 40)

Key takeaways:

• Treat Article 40 as an “inspection readiness” requirement for critical ICT third-party relationships. (Regulation (EU) 2022/2554, Article 40)
• Put a single accountable coordinator in place, with a cross-functional bench for exams, investigations, and remediation management.
• Maintain a living evidence register and pre-built supervisory response packs to avoid scramble, inconsistency, and missed deadlines.

Article 40 sits inside DORA’s Oversight Framework for critical ICT third-party service providers. While the legal text speaks to what the Lead Overseer must do, your practical exposure is straightforward: if you rely on a provider that is designated “critical,” you may face structured oversight activity (investigations or inspections) that requires fast, consistent, well-governed responses across security, ICT risk, resilience, procurement/vendor management, legal, and the business owner.

For a CCO or GRC lead, the fastest path to “operational” is to treat Article 40 as a standing operating capability, not a one-time compliance document. Your goal is repeatable execution: (1) knowing which providers are in scope, (2) knowing who answers what, (3) producing evidence on demand, and (4) tracking remediation to closure with proof.

This page translates the article 40: ongoing oversight requirement into a practical operating model: roles, workflow, evidence, and an execution plan you can run immediately. Regulatory text references are taken from the DORA primary source. (Regulation (EU) 2022/2554, Article 40)

Target keyword: article 40: ongoing oversight requirement

Use this requirement page as your internal standard for “inspection readiness” tied to DORA oversight of critical ICT third parties.

Regulatory text

Excerpt (operator-relevant): “When conducting oversight activities, in particular general investigations or inspections, the Lead Overseer shall be assisted by a joint examination team established for each critical ICT third-party service provider.” (Regulation (EU) 2022/2554, Article 40)

Plain-English interpretation

• Oversight of critical ICT third-party service providers is not ad hoc. It is organized, repeatable, and performed by a Lead Overseer with a joint examination team. (Regulation (EU) 2022/2554, Article 40)
• Your obligation is indirect but real: you need governance, documentation, and operational discipline so you can respond quickly and consistently to oversight-driven requests that touch your relationship with the critical provider (contracts, controls, incidents, testing, resilience, and remediation status).
• If you cannot produce coherent evidence across functions, you create supervisory friction: inconsistent answers, missing artifacts, delayed remediation, and unclear ownership.

What the operator must do (in one line)

Stand up an exam-ready oversight response capability for any critical ICT third-party dependencies: named owners, rehearsed workflows, and a maintained evidence set that can be produced and defended under investigation or inspection conditions. (Regulation (EU) 2022/2554, Article 40)

Who it applies to

Entity scope

• EU financial entities within DORA scope that contract with ICT third-party service providers, especially where a provider may be designated critical under DORA’s oversight framework. (Regulation (EU) 2022/2554)

Operational context (where this bites in practice)

• You outsource core systems, infrastructure, cloud, managed security, core banking platforms, payments processing, identity services, or other ICT services that materially affect operational resilience.
• You are asked to support (directly or indirectly) supervisory activity: document production, interviews, walkthroughs, technical evidence, or remediation attestations related to a critical ICT third party.

What you actually need to do (step-by-step)

1) Establish scope and ownership for “critical provider oversight readiness”

1. Create a scoped list of ICT third parties most likely to be “critical” to your operations (start with concentration, substitutability, and business impact).
2. Assign an accountable executive owner for third-party oversight readiness (often CISO, CIO, Head of ICT Risk, or Head of TPRM; Compliance coordinates).
3. Define an “Oversight Response Lead” (single throat to choke) for inbound oversight activity coordination across functions.
4. Build a cross-functional bench (ICT risk, security operations, resilience/BCM, procurement/TPRM, legal, privacy if relevant, internal audit, and the service owner).

Deliverable: a one-page RACI and contact tree for oversight events.

2) Implement a regulatory-response workflow (request intake → response → closure)

Build a workflow that handles both “simple doc request” and “inspection mode”:

1. Intake and triage
   • Capture request source, scope, due dates, data sensitivity, and impacted providers.
   • Classify urgency and escalation level.
2. Legal/compliance gating
   • Confirm disclosure boundaries and privilege strategy with legal.
   • Confirm messaging alignment to avoid inconsistent statements.
3. Tasking and production
   • Break requests into tasks with owners and due dates.
   • Use standardized evidence naming and version control.
4. Quality review
   • Perform a “two-person rule” review: technical owner + compliance/legal.
   • Check for consistency across artifacts (dates, system names, control IDs).
5. Submission and log
   • Submit through the required channel.
   • Log exactly what was sent, when, and by whom.
6. Remediation management
   • Convert findings into tracked corrective actions with owners, milestones, and validation evidence.

Practical tool: in Daydream, teams commonly manage this as a regulatory-request queue tied to an evidence register, so each response is traceable to a control owner and artifact set.

3) Maintain an “oversight evidence register” mapped to Article 40 readiness

Article 40 is short, but your evidence needs are not. Maintain a living register that maps:

• Requirement → control(s) → owner → system(s) → artifact(s) → location → last refresh date

Minimum evidence categories to index (keep it practical):

• Third-party inventory and criticality rationale for ICT providers relevant to resilience.
• Contracts and addenda relevant to ICT risk management, audit/inspection rights, incident notification, subcontracting, and service descriptions.
• Operational resilience evidence tied to the third party (test results, dependency mapping, RTO/RPO or service objectives if you use them internally, failover evidence where applicable).
• Security oversight evidence (risk assessments, control reports you receive, issues tracking, security exception decisions).
• Incident coordination artifacts (runbooks, contact lists, escalation paths, post-incident reviews involving the provider).
• Remediation artifacts (CAP logs, validation results, closure approvals).

This aligns with the practical risk factors in the fact pack: unclear accountability and fragmented evidence are the common failure modes you need to design out. (Regulation (EU) 2022/2554, Article 40)

4) Run readiness drills and close gaps with proof

Your aim is execution muscle memory.

• Tabletop an inspection scenario: “Joint examination team requests evidence in short order.”
• Test: Can you identify owners? Produce correct artifacts? Provide consistent narratives?
• Log gaps as corrective actions and close them with validation evidence (not just “policy updated”).

5) Prepare the third party engagement model for oversight friction

Even though Article 40 speaks to supervisors, your third party relationship must withstand scrutiny.

• Confirm the provider has named points of contact for regulatory-related inquiries.
• Ensure your contract management process can quickly locate the right clauses and statements of work.
• Track subcontractor dependencies for the service chain where relevant to your risk assessment and resilience posture.

Required evidence and artifacts to retain

Use this as a checklist for your audit/evidence repository. Keep versions and timestamps.

Evidence type	What “good” looks like	Owner
Oversight response procedure	Written workflow for intake, legal review, production, submission, and remediation tracking	Compliance / Legal
Oversight RACI + contacts	Named primary and backup roles, tested contact paths	GRC / TPRM
Critical ICT third-party list	Clear scope statement and rationale for focus providers	TPRM / ICT Risk
Evidence register	Requirement-to-artifact mapping with locations and refresh cadence	GRC
Request log	Immutable record of requests, submissions, and approvals	Compliance
CAP register + validation	Findings mapped to actions, with closure evidence and sign-off	Control owners / Internal Audit

Common exam/audit questions and hangups

Expect questions like:

• “Show how you identify and maintain an inventory of ICT third parties that are critical to operations.”
• “Who is accountable for responding to oversight investigations or inspections? Show the workflow.”
• “Provide an evidence pack for Provider X: contract, oversight artifacts, incidents, remediation, and governance minutes.”
• “Demonstrate that remediation closes with validation, not self-attestation.”
• “Show how legal/compliance reviews supervisory submissions for consistency and confidentiality.”

Hangups examiners often focus on:

• Evidence scattered across tools without a register.
• Control owners who cannot explain artifacts.
• Conflicting narratives between security, procurement, and business owners.
• Remediation items aging without closure evidence.

Frequent implementation mistakes and how to avoid them

1. Treating Article 40 as “not applicable because it’s about the Lead Overseer.”
   Fix: operationalize “supportability” and “inspection readiness” for critical-provider dependencies. (Regulation (EU) 2022/2554, Article 40)

2. No single coordinator for supervisory interactions.
   Fix: appoint an Oversight Response Lead with authority to task functions and enforce deadlines.

3. Evidence hoarding without traceability.
   Fix: maintain an evidence register that maps each artifact to an owner and refresh expectation.

4. Overproducing documents, underproducing proof.
   Fix: bias toward artifacts that show execution (tickets, test results, incident timelines, closure approvals).

5. Remediation that closes on paper only.
   Fix: require validation evidence (re-test output, config snapshots, attested control operation) before closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement actions.

Operational risk still concentrates here:

• Poor oversight readiness increases the chance of late, incomplete, or contradictory supervisory responses.
• Weak remediation discipline creates repeat findings and increases supervisory attention.
• Fragmented ownership slows response during high-pressure investigations.

A practical 30/60/90-day execution plan

Use staged phases (no date math required) and ship incremental capability.

First 30 days (Immediate)

• Name the Oversight Response Lead and publish the RACI and escalation path.
• Stand up the request log and approval workflow (include legal/compliance sign-off).
• Draft the evidence register template and populate it for your top ICT third parties by criticality to your business.

By 60 days (Near-term)

• Build standardized “evidence packs” for priority providers (contract set, risk assessments, resilience artifacts, incident artifacts, remediation log).
• Run a tabletop drill that simulates an inspection request list; measure response friction and gaps.
• Convert gaps into corrective actions with owners and due dates; require validation evidence for closure.

By 90 days (Operationalized)

• Expand evidence packs to the broader set of high-impact ICT third parties.
• Add recurring governance: periodic review of the evidence register, CAP aging reviews, and readiness drill scheduling.
• If you use Daydream, connect the evidence register to your control owners and request workflow so every request routes to the right artifact and approver without manual chasing.

Frequently Asked Questions

Does Article 40 apply directly to financial entities, or only to the Lead Overseer?

The legal obligation in Article 40 describes how the Lead Overseer conducts oversight with a joint examination team. Your practical requirement is to be inspection-ready for oversight activity tied to critical ICT third-party service providers you depend on. (Regulation (EU) 2022/2554, Article 40)

How do I know which ICT third parties are “critical” for Article 40 purposes?

Article 40 references “critical ICT third-party service provider” status under DORA’s oversight framework. Operationally, start by identifying ICT third parties whose failure would materially disrupt services, then track regulatory developments and supervisory communications related to critical designation. (Regulation (EU) 2022/2554)

What’s the minimum viable evidence pack I should prepare?

Prepare a curated set: contracts and service scope, risk assessments and control attestations you rely on, incident and escalation runbooks, resilience testing evidence tied to the dependency, and a remediation log with closure proof. Index it in an evidence register so you can produce it consistently.

Who should own the regulatory-response workflow: Compliance, Legal, or ICT Risk?

Compliance usually owns coordination and process, Legal owns disclosure and privilege decisions, and ICT Risk/Security owns technical content. Assign one Oversight Response Lead to prevent gaps and conflicting submissions.

How do we avoid inconsistent answers across teams during an inspection?

Use a single request intake queue, enforce a review step with compliance/legal, and require submissions to reference the same evidence pack versions. Hold short alignment huddles during active requests to confirm narrative consistency.

We already have third-party risk management. What changes for Article 40 readiness?

Standard TPRM often focuses on onboarding and periodic reviews. Article 40 readiness adds “inspection mode”: rapid evidence production, coordinated interviews/walkthroughs, and disciplined remediation tracking that stands up under scrutiny. (Regulation (EU) 2022/2554, Article 40)