Article 35: Powers of the Lead Overseer

Article 35: Powers of the Lead Overseer requirement means you must be prepared for an EU-appointed Lead Overseer to request information, conduct assessments, and drive remedial actions regarding your critical ICT third-party service providers, and you must operationalize fast, consistent regulatory responses. Build a documented intake-to-closure workflow, map obligations to controls and owners, and retain evidence that you can produce complete, accurate packages on demand. (Regulation (EU) 2022/2554, Article 35)

Key takeaways:

• Treat Lead Overseer interactions as a “regulatory operations” capability: intake, triage, fulfillment, and closure with governance.
• Your biggest failure mode is evidence fragmentation across ICT, security, procurement, and legal; fix it with a single traceability register.
• Run readiness drills so you can respond without improvising, and track remediation to verified closure.

Article 35 sits inside DORA’s Oversight Framework for critical ICT third-party service providers (CTPPs). Even if you are not a critical ICT provider yourself, you can still feel Article 35 in practice: your regulated entity may depend on a provider that is designated “critical,” and supervisory scrutiny will cascade into your third-party risk management, contracting, incident handling, and resilience evidence.

For a Compliance Officer, CCO, or GRC lead, the operational goal is simple: ensure your organization can respond to Lead Overseer actions and requests in a controlled, auditable way, without losing time to internal confusion over ownership, data sources, or approval rights. Article 35 is not a “write a policy” obligation; it creates day-two expectations for how you coordinate with ICT, security, vendor management, and legal under supervisory time pressure. (Regulation (EU) 2022/2554, Article 35)

This page translates the article into an implementable playbook: who it applies to, what you need to build, what evidence to retain, and what exam teams typically probe. The target keyword for this requirement page is article 35: powers of the lead overseer requirement.

Regulatory text

Excerpt (provided): “For the purposes of carrying out the duties laid down in this Section, the Lead Overseer shall have the following powers in respect of the critical ICT third-party service providers:” (Regulation (EU) 2022/2554, Article 35)

Operator interpretation of that excerpt

• Article 35 establishes that a Lead Overseer has formal supervisory powers over critical ICT third-party service providers. Your operational duty is to be “supervision-ready” for any relationship that involves a provider in scope.
• The practical requirement for regulated entities is preparedness: you need mechanisms to (a) identify which third-party relationships might fall under oversight, (b) produce accurate information quickly, and (c) execute corrective actions with traceable closure when oversight drives remediation. (Regulation (EU) 2022/2554, Article 35)

What the operator must do (in plain terms)

• Create a controlled way to receive, authenticate, track, and respond to oversight-related requests and actions.
• Maintain a living evidence set on third-party ICT risk, resilience controls, and contractual rights so responses do not depend on heroic efforts across siloed teams.
• Prove closure: when remediation is required, you need governance, deadlines, validation, and artifacts. (Regulation (EU) 2022/2554, Article 35)

Plain-English interpretation of the requirement

Article 35: powers of the lead overseer requirement is about supervisory reach. The Lead Overseer can exercise powers over critical ICT third-party service providers, and regulated entities must be able to support that oversight by producing information and coordinating actions connected to those providers. The regulatory risk is not theoretical: the moment your organization cannot produce a coherent, supportable package about a critical provider relationship, you create supervisory friction and operational disruption. (Regulation (EU) 2022/2554, Article 35)

Translate this into an internal objective you can manage: “We can respond to Lead Overseer-driven requests about any critical ICT provider relationship with complete, approved, reproducible evidence, and we can execute and prove remediation.”

Who it applies to (entity and operational context)

Primary scope

• Critical ICT third-party service providers are the direct subject of the Lead Overseer’s powers. (Regulation (EU) 2022/2554, Article 35)

Practical scope inside a financial entity If you are a regulated entity under DORA, you should treat Article 35 as applicable whenever:

• You contract with an ICT third party that could be designated as critical, or
• You materially depend on a subcontractor chain that routes through a potentially critical ICT provider, or
• You are asked by a competent authority (or your own internal governance) to produce evidence tied to oversight activities concerning a critical provider. (Regulation (EU) 2022/2554, Article 35)

Functions that must participate

• Compliance / GRC (regulatory response owner, evidence governance)
• ICT risk management (control mapping, risk acceptance)
• Information security (testing, incident handling, monitoring evidence)
• Procurement / third-party management (contracts, SLAs, exit rights, subcontractor visibility)
• Legal (privilege management, response review, contractual enforcement)
• Business owners (service criticality, impact, continuity needs)

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

1) Build a single “Article 35 readiness register”

Create one register that ties together:

• In-scope third parties (including which services and business processes they support)
• Whether they are likely to be considered “critical ICT” in your dependency map (use your internal criteria; avoid guessing in writing)
• Control owners for each evidence area (security, resilience, incident, change, continuity)
• The authoritative system of record for each artifact
• Response RACI and approval flow for regulator-facing packages

This is the fastest way to prevent the common failure mode: five teams, five spreadsheets, no consistent versioning. Your register becomes the index you hand to internal audit and use during drills.

Operational tip: If you use Daydream, store the register as a requirement-to-evidence map with named owners, evidence pointers, and review status so you can produce a consistent “supervisory evidence pack” without rebuilding it every time.

2) Implement a regulatory-response workflow (intake → triage → fulfillment → sign-off → closure)

Treat Lead Overseer-related communications like incident response, not email administration.

Minimum workflow states:

1. Intake & authenticity check (who received it, channel, due date, scope)
2. Triage (is this oversight-related; which provider/service; severity; dependencies)
3. Tasking (assign evidence owners; set internal deadlines earlier than external ones)
4. Compilation (assemble artifacts; ensure version control; record sources)
5. Legal/Compliance review (consistency, confidentiality, contractual constraints)
6. Submission (approved package; delivery confirmation)
7. Closure & lessons learned (gaps logged; remediation created; evidence retained)

Control point that examiners care about: clear authority to coordinate across ICT and procurement, and a repeatable sign-off path that avoids last-minute debates.

3) Pre-stage “supervisory evidence packs” for critical ICT providers

For each in-scope provider relationship, assemble a pack that can be refreshed, not rebuilt. Include:

• Service description, architecture overview (at the level you can support)
• Dependency map (business processes, upstream/downstream integrations)
• Contract summary: audit/inspection rights, incident notification, subcontractor terms, exit/portability
• Security and resilience controls evidence (see artifacts section below)
• Open issues and remediation status

4) Run readiness drills and track corrective actions to validated closure

Run scenario drills that simulate:

• A short-notice information request on a provider outage
• A request for proof of testing, incident handling, and remediation outcomes
• A demand to demonstrate that contractual rights are enforceable in practice

Each drill must end with:

• A gap log
• A corrective action plan (CAP)
• Evidence that the CAP was completed and validated (screenshots, tickets, meeting minutes, test results)

This is where many programs fail: they create CAPs but cannot prove closure beyond “marked done.”

5) Put escalation paths in writing (and test them)

Define and test:

• Who can declare an oversight request “regulatory priority”
• Who can compel business owners to provide information
• Who can contact the third party, and under what contractual authority
• Who decides on response positions when facts are incomplete

Required evidence and artifacts to retain

Keep artifacts in a controlled repository with retention aligned to your regulatory and legal requirements (do not invent a duration; follow your internal retention schedule).

Evidence you should be able to produce on demand

• Article 35 readiness register (current + change history)
• Regulatory-response procedure and RACI
• Request log with timestamps, owners, approvals, and final submissions
• Third-party inventory scoped to ICT services and criticality rationale
• Contracts and amendments for in-scope providers, including audit/inspection, incident notice, subcontracting, and exit clauses
• Security assurance artifacts you rely on (assessments, test reports, issue logs)
• Incident handling runbooks and post-incident reviews tied to third-party events
• Resilience testing evidence and remediation verification
• Board or senior management reporting extracts where third-party ICT risk is governed

Artifact quality rules

• Every artifact should have an owner, a “last reviewed” marker, and a source-of-truth location.
• Preserve “evidence of operation,” not just policy text: tickets, test outputs, approvals, and remediation validation.

Common exam/audit questions and hangups

Expect questions in this pattern:

• “Show me how you identify relationships that could fall under Lead Overseer attention.”
  Hangup: teams confuse “critical vendor” (internal tiering) with “critical ICT third-party” (oversight context).
• “Walk me through your process for responding to an oversight-style request.”
  Hangup: no defined intake channel, no internal deadlines, no legal review gate.
• “Prove this control operates, not that it exists.”
  Hangup: evidence is scattered across email and chat, not in a retrievable system.
• “How do you ensure remediation was effective?”
  Hangup: CAPs closed without validation evidence.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 35 as “the provider’s problem.”
   Fix: You still need internal operational readiness because oversight requests and remediation will affect your dependency, continuity, and governance posture. (Regulation (EU) 2022/2554, Article 35)

2. Mistake: No single accountable owner for oversight response.
   Fix: assign a “regulatory response owner” in Compliance/GRC with authority to pull in ICT, security, procurement, and legal.

3. Mistake: Evidence stored by team, not by requirement.
   Fix: maintain a requirement-to-evidence map (the register) so you can answer questions consistently across providers and services.

4. Mistake: Contract terms are assumed, not verified.
   Fix: do contract clause extraction for audit/inspection, incident notice, subcontractors, and exit. Store clause references and the executed agreement.

5. Mistake: Drills stop at tabletop notes.
   Fix: every drill must generate tracked actions and proof of closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 35, so this page does not cite specific actions.

Operationally, Article 35 increases supervisory immediacy around critical ICT dependencies. The risk is a cascade:

• Slow or inconsistent responses degrade supervisory confidence.
• Poor evidence discipline turns manageable requests into escalations.
• Weak remediation tracking leaves you exposed to repeat findings across cycles. (Regulation (EU) 2022/2554, Article 35)

Practical 30/60/90-day execution plan

First 30 days (stabilize response capability)

• Name the regulatory response owner and approve a lightweight RACI across Compliance, ICT, security, procurement, and legal.
• Stand up an oversight-request intake channel and a request log.
• Build the first version of the Article 35 readiness register for your top ICT third parties by business criticality.
• Draft the regulatory-response workflow and require legal/compliance sign-off before any external submission.

Next 60 days (make it repeatable)

• Convert the readiness register into provider-level evidence packs for the highest-dependency relationships.
• Perform a contract clause extraction for those providers and document gaps as remediation items.
• Run one readiness drill and produce a CAP with tracked actions and owners.
• Add version control and evidence repository conventions so packages are reproducible.

By 90 days (prove operation and close gaps)

• Run a second drill focused on a different scenario (incident-driven request vs. control-evidence request).
• Demonstrate remediation closure with validation artifacts for high-priority gaps.
• Implement executive reporting: open oversight-readiness gaps, CAP status, and evidence health by provider.
• If you use Daydream, configure automated control-to-evidence tracking and reminders so pack freshness does not depend on calendar heroics.

Frequently Asked Questions

Does Article 35 apply directly to my firm if we are not a critical ICT third-party provider?

Article 35 defines the Lead Overseer’s powers over critical ICT third-party service providers. If you are a regulated entity, you still need operational readiness because your dependencies on critical providers can trigger requests, remediation expectations, and governance scrutiny. (Regulation (EU) 2022/2554, Article 35)

What is the single artifact that makes Article 35 operational?

A requirement-to-evidence register that lists in-scope third parties, control owners, and the exact location of supervisory-ready artifacts. Without it, response work becomes a scramble across teams and systems.

How do we avoid sending inconsistent information to a Lead Overseer or competent authority?

Force all submissions through one workflow with legal/compliance review and version-controlled evidence sources. Keep a request log and store the final submitted package as the record copy.

What do auditors usually mean by “evidence of operation” for this requirement?

They want proof that your response and remediation processes run in practice, such as completed request tickets, approvals, drill outputs, corrective actions, and validation evidence. Policies alone rarely clear that bar.

Our third party refuses certain audit or inspection requests. What should we do?

Document the refusal, route it through legal and procurement, and track it as a contract and risk issue with defined remediation. Your evidence pack should show the contractual position, the escalation steps taken, and the current risk acceptance decision.

How can Daydream help without turning this into a tool-first project?

Use Daydream to maintain the register, assign accountable owners, and link each Article 35 obligation area to concrete artifacts and review cadences. That keeps your response posture consistent even when staff or providers change.