Article 35 Powers of the Lead Overseer: requirements and evidence

What DORA Article 35 powers mean for a critical ICT provider

Once the ESAs designate an ICT provider as critical, the question for its leadership is what the Lead Overseer can actually require of it. Article 35(1) gives the Lead Overseer a set of escalating powers: to request information, to conduct general investigations and inspections, to request reports on remedial actions, and to issue recommendations. Information requests run under Article 37, investigations and inspections under Articles 38 and 39. The recommendations can cover security requirements, contract terms, planned subcontracting, and refraining from certain subcontracting with third-country providers that poses a clear and serious risk. The provider is not the only party affected. The financial entities that use its services remain subject to their own DORA duties, but the ESAs, acting as Lead Overseers, are the authorities that address the provider directly. Competent authorities follow up on those recommendations under Article 42.

The escalation path matters most for planning. Under Article 35(6), if a critical provider fails in whole or in part to comply with measures required under points (a), (b) or (c) of Article 35(1), the Lead Overseer must, after at least 30 calendar days from notification of the measures, adopt a decision imposing a periodic penalty payment. Under Article 35(7) and (8), those payments accrue daily until compliance, for no more than six months after notification of the decision, at up to 1 % of the provider's average daily worldwide turnover in the preceding business year. The Lead Overseer weighs gravity and duration, intent or negligence, and cooperation. Non-endorsement of a recommendation under Article 35(1)(d) follows a different path: public disclosure and follow-up by competent authorities, not penalty payments. Leadership should confirm with its own counsel how these provisions interact with its contracts and national enforcement.

Two things make compliance hard in practice. The first is evidence readiness across many customers. A provider serving numerous financial entities must produce consistent information for each of them, and an information request can arrive for the whole service rather than one client. The second is the cross-border subcontracting chain, where each layer of a hosting, support or software supply chain may fall under a planned subcontracting recommendation. Teams should map every subcontractor that supports a service, record where it operates, and check whether they could answer an information request about it within a short window. Under Article 35(3), the Lead Overseer must consult the Oversight Forum and give the provider 30 calendar days to show the expected impact on customers outside DORA's scope before recommendations are issued, so that response is a window worth preparing for in advance.

Which providers and services fall under Article 35 powers

Article 35 powers reach only a narrow set of ICT providers, but the edges of that set decide how much work lands on a financial entity and its provider. The cards below separate who is in scope, which services and subcontractors feed a critical service, and the location and role checks that change what the Lead Overseer can ask for.

Providers designated as critical

Article 35 applies only to ICT third-party service providers that the ESAs have designated as critical under Article 31. Being a large or important vendor is not enough. Check the current designation list for each provider in your register, because designation is the trigger for every power in this article. A provider that is not on the list stays under your Article 28 to 30 obligations, not the Lead Overseer's direct powers.

Third-country providers with an EU subsidiary

A non-EU provider can be designated critical and fall under Article 35 through its EU subsidiary, which the designation rules treat as the point of contact for oversight. Confirm which legal entity holds the contract with your institution, which entity receives information requests, and whether the subsidiary has the staff and systems to produce data held elsewhere. A mismatch here can delay an information request.

Services that feed a critical function

Recommendations can cover the ICT services a critical provider delivers to financial entities, including those that support an entity's critical or important functions. Map which of your services run on the designated provider, which depend on its platform or data, and which are standalone. Services that only touch a designated provider at the edge may stay outside the recommendation scope, so record the reasoning in writing.

Subcontractors located outside the EU

Article 35 lets the Lead Overseer recommend that a critical provider refrain from planned subcontracting with a third-country provider where the arrangement poses a clear and serious risk. A subcontractor's location therefore changes the scope of the work. Ask each critical provider for its subcontracting chain, the country where each subcontractor processes or stores data, and any planned changes that would need to be reviewed.

Subcontractors with a role in critical functions

A subcontractor is relevant to Article 35 when it performs a material part of the service behind a critical or important function, even if it sits inside the EU. Identify which subcontractors run security monitoring, hosting, identity or incident response for the provider. Those roles are where a recommendation on security requirements or planned subcontracting is most likely to reach your environment.

Self-hosted open-source components

Self-hosted open-source software you run in your own infrastructure is usually not itself a critical ICT third-party service, but a commercial support, hosting or maintenance provider wrapped around it can be. Document which component is supplied by whom, who operates it, and which parts depend on a designated provider. This boundary decides whether a recommendation can touch your deployment or only the provider's own services.

How an assessor tests the Lead Overseer's powers in practice

This table sets out what the Lead Overseer's team checks when it tests a critical ICT provider's readiness for information requests, inspections and recommendations under Article 35. Read each row as a question the assessor asks, the evidence it expects, and where providers usually fall short.

Assessment area	What the assessor tests	Evidence the assessor expects	Common findings
Information request handling	Whether the provider can answer a request under Article 37 completely, accurately and within the deadline set in the request	A written response procedure with named owners, a log of past requests and responses, and sample packs showing how data was pulled and checked	Slow response to information requests, answers spread across teams with no single owner, and gaps in data that the provider cannot explain
Register of ICT services	Whether the provider can show which services it delivers to financial entities, which are supporting critical or important functions, and how they map to contracts	A current, complete register extract, version history, and a reconciliation against signed customer contracts	Services missing from the register, outdated entries after product changes, and no link between a service and its contractual terms
Subcontracting chain records	Whether every planned or current subcontractor is identified, its location is known, and its role in delivering the service is documented	Subcontractor list by service, contracts or flow-down terms, location of data processing, and records of prior notices to customers	Undocumented subcontractors, fourth-party dependencies unknown to the provider's own staff, and third-country subcontracting not assessed for risk
Inspection readiness	Whether staff, sites and systems can be shown to an inspection team without delay, and whether access and scope are clearly defined	Inspection playbook, escort and access procedures, system walk-through materials, and evidence of prior internal audits	No named inspection contact, scope disputes over what can be accessed, and internal audit reports not matched to current controls
Remediation tracking	Whether recommendations, security requirements and contract changes ordered under Article 35(1) are assigned, tracked and closed with proof	Remediation plan per recommendation, owners, due dates, status reports to the Lead Overseer, and closure evidence	Actions with no owner, status reported without evidence, and deadlines missed without a documented request for more time
Response to recommendations	Whether the provider has a documented process to review recommendations, consult its management body and reply to the Lead Overseer	Board or management minutes, impact analysis on customers outside DORA's scope, and the written reply sent	Recommendations forwarded without analysis, no record of management review, and replies that do not address each point
Periodic penalty readiness	Whether the provider can demonstrate progress toward compliance once measures are notified, since Article 35(6) to (8) tie penalties to failure to comply	Compliance tracker with dated milestones, correspondence showing good-faith effort, and records of cooperation	No tracker, progress that cannot be shown to the assessor, and delays attributed to internal approvals rather than technical limits

How a critical provider prepares for an oversight examination

The sequence gives a critical ICT third-party provider a documented way to answer each power the Lead Overseer can use under Article 35, from first request to any periodic penalty decision. Each step ends with a record that shows the provider can respond on time and prove it.

Map each Article 35 power to an owner
Start by listing the Lead Overseer's powers under Article 35(1): information requests, general investigations, inspections, requests for reports on remedial actions, and recommendations on security requirements, contract terms, planned subcontracting and certain third-country subcontracting. Assign each power to a named executive owner, a legal reviewer and a technical lead, and record who receives notices and who can sign responses. The output is a powers register that names an owner, a deputy and the source documents for each power, reviewed by the management body or the function that answers to it. Confirm the internal reporting lines with your own governance documents, since DORA does not prescribe them.
Build the information request response process
Information requests under Article 37 are the most frequent exchange a critical provider will have with the Lead Overseer, so the process must be repeatable. Define intake, logging, triage by subject matter, legal review, evidence collection, sign-off and submission, and assign a tracker entry to every request with its deadline as stated in the request. Test the workflow with an internal mock request before any real one arrives. The output is a request log, a template response pack and a documented approval chain that shows who can release information and which items require legal review first.
Prepare evidence for investigations and inspections
General investigations and inspections under Articles 38 and 39 test whether the provider's services, systems and records match what it has told customers and the Lead Overseer. Build an evidence library organized by DORA subject area, covering security controls, continuity arrangements, incident records, subcontracting chains, testing results and governance minutes. Run a readiness walk-through in which a reviewer who did not build the controls asks for proof of each claim and checks that the material can be produced quickly. The output is an indexed evidence set with a named custodian for each item and a record of the walk-through findings, closed or assigned.
Track the expected-impact statement and consultation
Under Article 35(3), the Lead Overseer must consult the Oversight Forum before using these powers, and the provider has 30 calendar days before recommendations are issued to show the expected impact on customers outside DORA's scope. Prepare a standing impact analysis that identifies which non-DORA customers, such as clients in other jurisdictions or sectors, would be affected by likely security, contract or subcontracting changes. Log the date of each notice and calculate the 30-day window from it. The output is a ready impact statement, a dated notice log and an agreed contact for the consultation period.
Track recommendations and remedial action reports
Recommendations under Article 35(1) and requests for reports on remedial actions create open obligations that must be tracked to closure. Record each recommendation, its subject (security requirements, contract terms, subcontracting or third-country subcontracting), the implementation owner, the planned milestones and the evidence that will show completion. Review open items at a set cadence with the management body or its delegate. Note that non-endorsement of a recommendation is handled through public disclosure and follow-up by competent authorities under Article 42, so the provider's record of its reasons and actions matters. The output is a recommendations register with status, owner and closure evidence for each item.
Monitor periodic penalty exposure and rights
Under Article 35(6) to (8), a periodic penalty payment may be imposed only after at least 30 calendar days from notification of the required measures, if the provider fails to comply with the measures in Article 35(1)(a) to (c). The payment runs daily until compliance, for no more than six months after notice of the decision, and can reach up to 1 % of average daily worldwide turnover in the preceding business year. Article 35(9) to (11) add that such payments are administrative, enforceable under national civil procedure, publicly disclosed unless disclosure would seriously jeopardise markets or cause disproportionate damage, and subject to the provider's right to be heard and access to the file. Finance and legal should model exposure with their own turnover figures, and the provider should confirm its rights of hearing and file access with counsel. The output is a documented exposure model, a compliance tracker for each required measure and a hearing and file-access procedure ready for use.

How periodic penalty payments are triggered and limited

A periodic penalty payment under Article 35 is a last step, not a first response. It can only be imposed when a critical ICT third-party provider fails, in whole or in part, to comply with a measure the Lead Overseer required under Article 35(1)(a), (b) or (c). Those measures cover requests for remedial reports, security requirements and contract terms. Before any payment decision, the Lead Overseer must first notify the provider of the measures and allow at least 30 calendar days to pass. Compliance teams at providers, and at the financial entities that depend on them, should track the notification date and the deadline it sets, because the clock starts there and not when a finding is first discussed.

Once the decision is adopted, the payment runs daily until the provider complies, but for no more than six months from notification of the decision. The daily amount can reach up to 1 % of the provider's average daily worldwide turnover in the preceding business year. The Lead Overseer sets the level by weighing the gravity and duration of the failure, whether it was intentional or negligent, and how far the provider cooperated. Providers should keep records of every remedial step, every exchange with the Lead Overseer and any reasons for delay, since cooperation and duration are the factors most directly shaped by documented conduct. Financial entities should confirm in their contracts how they would learn of such a decision, because it may affect the continuity of services they rely on.

Procedural protections apply throughout. The provider has the right to be heard and access to the file before a decision is final. The penalty payments are administrative, enforceable under national civil procedure, and allocated to the EU general budget. Unless disclosure would seriously jeopardise markets or cause disproportionate damage, the decision is published. Non-endorsement of recommendations under Article 35(1)(d) follows a different path. It is handled through public disclosure by the Lead Overseer and follow-up by competent authorities under Article 42, not through periodic penalty payments. Readers should confirm the current procedural rules and any national implementing arrangements with their competent authority or provider, since the Article 35 mechanics are fixed in the Regulation but their practical application will develop through supervisory practice.

Evidence that shows a provider can meet Article 35 requests

Article 35 requests arrive with short timelines and specific questions, so a provider needs evidence that already exists when the Lead Overseer asks. The cards below cover the procedures, records and registers that connect a request to a documented, owned and dated answer. Keeping them current between examinations matters more than producing them once.

Documented request-handling procedure

A written procedure that defines how an information request under Article 37 is received, logged, assigned, answered and approved. It should set who verifies facts, who signs off on the response, and how deadlines set by the Lead Overseer are tracked. Check that the procedure has been run at least once against a realistic test request, and that the log shows the steps were followed in practice.

Named contacts and escalation matrix

A current list of named individuals who can answer for security, continuity, contracts and legal matters, with deputies and out-of-hours coverage. The escalation matrix shows who decides when a request touches a subcontractor or a third-country location. Confirm that each named person has accepted the role and that contact details are verified at fixed intervals.

Register of ICT services and subcontractors

An up-to-date inventory of the ICT services the provider delivers to financial entities, the functions they support, and every subcontractor in the chain, including location and data processed. Examiners use it to test whether planned subcontracting or third-country dependencies were disclosed accurately. Reconcile it against contracts and the financial entities' registers of information at each review cycle.

Subcontracting change records

Dated records of every addition, replacement or change of a subcontractor, with the approval, risk assessment and customer notification attached. Recommendations under Article 35(1) can address planned subcontracting, so a clear trail shows which changes were reviewed before they took effect. Ask whether the records show who approved each change and whether any were made without notice.

Remediation plans with owners and dates

For each finding, a plan that names the control or service affected, the accountable owner, the actions and the target completion date, plus evidence that closure was verified. Recommendations and measures required by the Lead Overseer must be tracked to completion, because non-compliance is the trigger for periodic penalty payments. Review overdue items at every management meeting and record the decision when a date slips.

Records of past responses and consultation input

An archive of prior answers to information requests and inspections, along with the source documents used. It also includes the working file for the 30-day consultation response that Article 35(3) allows the provider to give on expected impact on customers outside DORA's scope. Preserve the drafts, reviewers and approvals so the provider can show how each statement was prepared and that it stayed consistent with earlier answers.

What meeting Article 35 readiness costs in money and effort

This table compares the main cost components of preparing for Lead Overseer powers, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, because no fee or duration figures have been published for this work and each must come from counsel, the vendor or your own scoping.

Cost component	Who is paid or who bears it	One-time or recurring, and what drives it
Internal legal and compliance time	Your own staff, or time borrowed from the contract owner	Recurring. Grows with the number of critical provider relationships, the volume of information requests, and how often recommendations need a response.
Engineering time to produce technical evidence	Your platform, security and operations teams, or an implementation partner under a fixed-scope agreement	Mostly one-time to build the evidence pack, then recurring to refresh it. Driven by how many systems the provider's services touch and how well logs and configurations are already documented.
Tooling for records, logs and evidence retention	Software licenses, self-hosted infrastructure, or storage in your own environment	Recurring. Driven by retention periods, log volume and whether records are indexed for fast retrieval within the response windows you set internally.
External legal or regulatory counsel	Specialist EU financial regulatory lawyers, billed by the hour or under a retainer	One-time for contract and procedure review, recurring if counsel supports live supervisory exchanges. Ask for a fixed estimate per workstream.
External technical review	An independent security or audit firm you engage directly	Periodic. Driven by the scope of systems reviewed and whether the review is run before or after a regulator's request. Ask who owns the findings.
Contract amendments with the critical provider	Negotiated between your legal team and the provider, with your counsel	One-time per contract, with recurring review when the provider changes its terms. Driven by the number of providers and the depth of existing audit and cooperation clauses.
Procedures for handling a periodic penalty payment decision	Your legal team and governance functions, plus counsel if a decision is issued	Contingent. Preparing the procedure is one-time. Costs arise only in the event of a dispute, and depend on the right to be heard and file access.

Who owns Article 35 readiness and what can be outsourced

The critical ICT third-party service provider owns Article 35 readiness. Its management body and internal teams decide how to respond to information requests, how to scope inspections, which recommendations to accept, how to plan remedial actions and how to communicate with the Lead Overseer. Nothing in this tab can be handed to an outside firm without the provider keeping accountability for the outcome.

Response ownership: A named accountable executive approves every answer to an information request under Article 37 and is responsible for its accuracy.
Remediation decisions: Management decides whether to comply with each recommendation, documents the reasoning, and tracks the deadlines the overseer sets.
Subcontracting positions: The provider decides how it will address recommendations on planned subcontracting and third-country subcontracting that poses a clear and serious risk.
Governance records: Board and management minutes show oversight of the response, which an examiner will expect to see.
Overseer communication: A single point of contact manages the file, access requests and the right to be heard.

Before engaging any partner, confirm which decisions your management body has formally delegated in writing and which it has kept.

Where critical providers usually fall short on oversight requests

Article 35 powers arrive as information requests, investigations and inspections that often land on teams with no shared picture of the service. The gaps below tend to surface first when a Lead Overseer asks for evidence, and they share a root cause: ownership and records that were never built for an external examiner.

Incomplete subcontracting records

A Lead Overseer can recommend changes to planned subcontracting, so the provider must show who sits in each chain beneath the critical service, where they operate and what data or functions they touch. Gaps appear when subcontractors are recorded only in procurement files and not in the service register. Close them by reconciling the subcontracting chain against contracts and the register of information each quarter, and by checking that every onward subcontractor carries the flow-down terms the provider accepted.

No single owner for requests

An information request under Article 37 or an inspection notice under Article 39 can reach legal, security, operations and account teams at once, each answering differently. Without one accountable owner, deadlines slip and answers conflict. Name one regulatory liaison with authority to pull evidence and approve responses, and record who is the deputy when that person is unavailable.

Evidence scattered across teams

Control evidence such as access reviews, change records, test reports and incident logs often sits in separate tools owned by different teams. Assembling a response then takes days of manual searching and risks inconsistent versions. Build an evidence index that maps each DORA requirement to its source system, owner and retention location, and test that the index can produce a complete file within a set internal deadline.

Slow tracking of recommendations

Recommendations on security requirements or contract terms usually carry response expectations, and a missed step can lead to a decision on periodic penalty payments after at least 30 calendar days from notification of the measures. Recommendations that live only in email threads are easy to lose. Log each one with its source, due date, accountable owner and evidence of closure, and review open items at a standing governance meeting.

Contract terms that do not match practice

Recommendations often target contract terms, audit rights and cooperation duties that were drafted years earlier. When the operational reality differs from the signed text, the provider may be unable to commit to the change quickly. Compare each critical service contract against current operating practice, and identify which clauses need amendment before an oversight request arrives.

Questions buyers ask about Article 35 readiness

Does a financial entity have to meet Article 35 directly?

Not in the same way. Article 35 gives the Lead Overseer powers over designated critical ICT third-party service providers, so the direct obligations sit with those providers. Financial entities feel the effect through their contracts and through DORA's duties on managing ICT third-party risk, including the follow-up duties that apply once recommendations affect the services they use. Whether a provider in your chain is designated is a question to confirm against the official list of designated providers. If a critical provider supplies a service you depend on, ask in writing how it will tell you when a Lead Overseer measure could change that service or its contract terms.

How much effort does Article 35 readiness take?

The effort depends on how many systems are in scope, how much evidence already exists, and how quickly the provider can answer information requests. No effort or cost figure is supplied for this topic, so treat any estimate as something to confirm with your team or a written scope. The main drivers are:

Inventory quality: a current map of services, locations, subcontractors and data flows
Evidence maturity: documented security, continuity and change processes that already produce logs and records
Subcontracting chain: the number of layers and third-country links the Lead Overseer may ask about
Governance: whether the management body and named contacts can approve responses within the deadlines in each request

One-time work covers mapping and gap closure. Recurring work covers keeping evidence current so requests and inspections can be answered without a scramble.

Can an ICT provider prepare for Article 35 in-house?

Yes, a provider can prepare in-house if it has staff who understand DORA's ICT third-party requirements, knows where its evidence lives, and has a clear internal approval path. The provider owns its controls and its responses to the Lead Overseer. An outside implementation partner can help prepare systems, documentation and evidence in the provider's own infrastructure, but it does not issue reports, decisions or outcomes. Independent auditors and assessors are a separate question, since none of them issues an Article 35 result. Ask whether your team could assemble a complete evidence pack for an inspection within a short period, and who would coordinate across legal, security and engineering when that happens.

What does the Article 35 work need from our team?

The work needs several roles working from the same records. Expect to involve a regulatory or legal lead who reads the Lead Overseer's powers against your contracts, a security lead who owns the controls, a platform or engineering lead who can produce logs, configurations and test results, a service owner who manages subcontractors and exit terms, and an executive sponsor who signs off responses. The team also needs access to the asset inventory, subcontractor list, incident records, change logs and recent testing results. Confirm early who is accountable for each response, because most delays come from unclear sign-off rather than from missing technical work.

How long does Article 35 preparation take?

No preparation duration is supplied for this topic, so confirm timing with your team before committing to a date. Timing depends on the number of services in scope, the current state of evidence, and how many subcontractors sit in the chain. The legal clock matters too. Periodic penalty payments can only follow a decision adopted after at least 30 calendar days from notification of the measures, and the payments run for no more than six months after notification of that decision. Build the plan around the response windows in the measures you receive, and ask any partner for a written schedule tied to a defined scope.

Can cooperation with the Lead Overseer avoid penalty payments?

Cooperation cannot be relied on to avoid penalties, but it is one factor the Lead Overseer weighs when setting the amount. Periodic penalty payments follow a provider's failure, in whole or in part, to comply with measures required under the information, investigation, inspection and remedial reporting powers. The payments are daily until compliance, for no more than six months after notification of the decision, at up to 1 % of average daily worldwide turnover in the preceding business year. The amount takes account of gravity, duration, intent or negligence, and cooperation. The provider keeps the right to be heard and access to the file. The full text is in the Article 35 section of DORA.

Does ignoring an Article 35 recommendation always lead to a fine?

No. Non-endorsement of a recommendation is handled differently from the measures that can trigger periodic penalty payments. Under DORA, a provider that does not endorse a recommendation faces public disclosure by the Lead Overseer, and follow-up by competent authorities under Article 42. Financial entities that use the provider then have to respond to the risks identified. That path can still be costly in customer trust and contract terms, so review each recommendation with legal and security owners rather than treating it as optional. Confirm the exact consequences for your provider with a qualified legal adviser, since the outcome depends on the provider's position and the authority involved.

How DeployOpen prepares systems and evidence for oversight

DeployOpen works on Article 35 Powers of the Lead Overseer as an implementation partner, not as an auditor or overseer. We scope the systems, records and evidence a critical ICT provider would need to answer information requests, inspections and recommendations, then build and document them inside the client's own infrastructure. Only the Lead Overseer and the competent authorities decide what is compliant.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map which information requests, inspection areas and recommendation topics apply to the systems in the written scope.
We confirm with the client's legal and compliance team which contracts, subcontractors and third-country dependencies fall within that scope.
The scope names the owner for each evidence item, so responsibilities are clear before any request arrives.

How we build

We configure logging, asset inventories and subcontracting records in self-hosted open-source platforms the client operates.
We prepare retrieval procedures so requested records can be produced accurately within the deadlines the client confirms with its overseer.
We build tracking for recommendations, remedial actions and the status of each planned change.
We test these procedures with the client's staff before any real request, so gaps surface early.

How we hand over

We deliver written procedures, system documentation and an evidence index mapped to the agreed scope.
We train the staff who will answer requests, inspections and recommendations, and document who signs off each response.
We record every configuration change and open item so the client can show its decisions and their timing.
The client keeps ownership of all records, credentials and decisions after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
Retainers can cover re-running retrieval tests, updating evidence when systems change, and reviewing new recommendations.
Before any retainer starts, we agree its scope and deliverables in writing, as with any engagement.
Questions about the legal effect of Article 35 on a specific provider should go to the client's counsel or the competent authority.