What Delegated Regulation (EU) 2025/295 asks critical ICT providers to disclose
If your ICT company may be designated as a critical third-party provider under DORA, or already has been, you must give the European Supervisory Authorities structured information about your services, ownership and supply chain. Commission Delegated Regulation (EU) 2025/295, published in the Official Journal on 13 February 2025, supplements DORA Article 41(1), points (a), (b) and (d). It sets the information content for voluntary designation applications, the information a Lead Overseer may request during oversight, the template for subcontracting arrangements, and how competent authorities assess the risks raised in Lead Overseer recommendations. The regulation exists because supervisors cannot judge concentration risk in the financial sector without a clear view of which providers serve which institutions and who those providers depend on in turn.
The application content is where most providers feel the workload first. Article 1 expects a legal entity identifier, the corporate structure, an estimated share of the Union financial sector, the services provided, the financial entity clients served, and a self-assessment of how substitutable each service is. Oversight requests under Article 2 reach further: contracts with financial entities and subcontractors, group structure and shareholders holding 25 % or more of capital or voting rights, management body minutes, security policies, data centre locations, audit reports and certifications, and extracts from monitoring and scanning systems. The difficulty is that these records sit in different places. Legal teams hold contracts, finance holds the shareholder register, security holds policies and scan extracts, and no single team holds the subcontractor chain. Confirm early which of these records exist, in what form, and who can release them.
Start with a map of your own group and subcontracting chains before any formal request arrives, and confirm with your legal and compliance advisers how the 25 % shareholder threshold and the subcontractor definitions apply to your structure. Assign an owner for each information category and test whether you can produce a complete, dated set within a short working period. Where this section raises questions about your specific designation status or the Lead Overseer's expectations, confirm them with the competent authority and the relevant ESA rather than relying on this summary.
Who this RTS applies to and which scoping choices change the work
Delegated Regulation (EU) 2025/295 governs what ICT providers hand to overseers, not what financial entities keep for themselves. The cards below cover who falls under it and the scoping choices that decide how much information a provider must assemble and from which legal entity.
Voluntary applicants for designation
ICT third-party providers that want to be designated as critical must file an application containing their legal entity identifier, corporate structure, estimated market share in the Union financial sector, services provided, financial entity clients, and a self-assessment of substitutability. Providers should confirm early which group entity will file and whether the market share estimate covers all group services or only those used by financial entities. Check the Article 1 list against what the provider can produce without contacting clients first.
Providers already designated as critical
Once designated, a critical provider must answer Lead Overseer requests for contracts with financial entities and subcontractors, group structure, governance minutes, security policies, data centre locations, audit reports and monitoring extracts. Providers should map which internal teams own each category and how quickly they can respond. Gaps in ownership usually surface during the first information request, not during planning.
Group entities holding the contracts
Many providers sign client contracts through a parent or a regional affiliate while the service runs on infrastructure owned by another group company. The information requested may therefore sit in several entities. Confirm which entity is the contracting party for each financial entity client, which entity holds the subcontracts, and how shareholdings of 25 % or more are documented across the group chart.
Subcontractors behind the service
The subcontracting template in Article 5 requires information on the chain of subcontractors supporting services to financial entities, not only the first-line supplier. Providers should trace hosting, support, managed monitoring and offshore operations to named legal entities and record which of them support the services in scope. Stale or incomplete subcontractor lists are a common reason an overseer will challenge a response.
Which legal entity answers the request
Requests may be addressed to the designated entity, but the documents behind them often belong to a different company in the group. Providers should decide in advance who signs responses, who holds the authority to provide the information, and how confidentiality and data protection terms apply when a sister company's records are shared. Illustrative case: a holding company answers for a cloud service whose operating subsidiary holds the audit reports.
Records held in other jurisdictions
Security policies, audit reports, monitoring data and contracts may be stored in other countries or on systems operated by other group members. Providers should inventory where each category of record sits, whether the holder can release it to the Lead Overseer within the requested timeframe, and whether local law restricts transfer. Document these locations before a request arrives, because data centre locations are themselves part of the information to be provided.
How the voluntary application and information requests fit together
Delegated Regulation (EU) 2025/295 sets up three separate information channels between an ICT provider and the oversight authorities, and they should be read together. The first is the voluntary application. Under Article 1, a provider that wants to be designated as a critical ICT third-party service provider must supply its legal entity identifier, its corporate structure, its estimated market share in the Union financial sector, the services it provides, the financial entities it serves, and a self-assessment of how substitutable those services are. The second channel opens once designation applies: under Article 2, the Lead Overseer can request contracts with financial entities and subcontractors, group structure and shareholdings of 25 % or more, management body minutes, security policies, data centre locations, audit reports and certifications, and extracts from monitoring and scanning systems. The third is the subcontracting template in Article 5, which standardizes how subcontracting arrangements are described to the overseer.
The three channels describe the same provider from different angles, so inconsistencies between them are easy to spot. A substitutability claim in the application, a subcontractor chain in the template and a contract list produced on request should tell the same story. Providers should confirm that the data they gave in the application is traceable to the contracts, group records and register entries they will later have to produce, and that their subcontractor list is maintained as a living record rather than rebuilt for each request.
Article 6 is where the information is tested against risk. Competent authorities use it to assess the risks addressed in the Lead Overseer's recommendations, so the evidence a provider supplied earlier becomes the basis for judging whether its response is adequate. The composition of the joint examination teams that support this oversight is set separately in Commission Delegated Regulation (EU) 2025/420, so financial entities and providers should check that regulation for who sits on those teams rather than assume it follows from this one.
How an assessor tests a provider's oversight information
This table compares each area of information a critical ICT provider sends under Delegated Regulation (EU) 2025/295, showing how the reviewing ESA or competent authority tests it and where submissions usually fall short. The reviewer is the ESA or competent authority, not an independent auditor, so no report or certificate is issued from this process. Use the rows to prepare evidence before a request arrives.
| Request area | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Designation application content | Check each element of the voluntary application against the Article 1 list for completeness and internal consistency | LEI, corporate structure, estimated Union market share, services provided, financial entity clients, self-assessment of substitutability | Market share estimates without stated method, and substitutability self-assessments that do not address exit feasibility |
| Contracts with financial entities and subcontractors (Article 2) | Compare contract terms against the services described and confirm the subcontracting chain is complete | Signed contracts, service descriptions and the list of subcontractors supporting those services | Subcontractor lists that omit downstream providers, or contracts that differ from the versions used in practice |
| Group structure and shareholders at 25 % or more (Article 2) | Trace ownership from the provider to ultimate owners and check that group entities providing services are covered | Organization charts, shareholder registers and entities holding 25 % or more of capital or voting rights | Charts that stop at the parent without showing intermediate holding companies, or outdated shareholder data |
| Governance and management body minutes (Article 2) | Review minutes for records of decisions on ICT risk, outsourcing and oversight recommendations | Extracts of minutes covering ICT risk, critical services and responses to supervisory findings | Minutes that record discussion without decisions, owners, or follow-up dates |
| Security policies (Article 2) | Check policies cover the ICT services provided to financial entities and are approved at the right level | Current approved policies, approval records and review dates | Policies that are generic, unsigned, or not mapped to the services in scope |
| Data centre locations (Article 2) | Verify locations match the service description and identify any processing outside the stated sites | Site list with function, operator and any third-country processing | Locations listed for the parent company only, or backup and disaster recovery sites missing |
| Audit reports and certifications (Article 2) | Confirm scope, period and issuing body of each report, and check whether findings were remediated | Independent audit reports and certificates issued by third parties, with scope statements and remediation tracking | Reports covering a different scope from the services provided, or expired certificates presented as current |
| Monitoring and scanning extracts (Article 2) | Sample logs and scan outputs for coverage, frequency and closure of findings | Extracts from monitoring and vulnerability scanning systems for the services in scope | Extracts too narrow to show coverage, or open high-severity findings without a stated plan |
| Subcontracting template (Article 5) | Check that each subcontracting arrangement is recorded using the prescribed template fields | Completed subcontracting information for each arrangement affecting critical functions | Missing locations or service descriptions for sub-tier providers, and inconsistency with the contract register |
| Handling of Lead Overseer recommendations (Article 6) | Competent authority assesses the risks each recommendation addresses and how the provider responded | Provider response, action plan, evidence of implementation and timelines against each recommendation | Responses that restate the recommendation without describing a measurable change or residual risk |
How a provider assembles its oversight information pack
This sequence shows how a designated critical ICT third-party provider can gather the information Delegated Regulation (EU) 2025/295 lets the Lead Overseer request, so that each item has a named owner, a verified source and a sign-off before it is shared.
Map legal entities and group structure
Start by listing every legal entity in the provider's group that touches the services in scope, with its legal entity identifier, its role and the country where it is registered. Record how the entities relate to one another and where the parent sits. The legal owner of this map is usually the general counsel or company secretary, working with group finance. It is complete when each entity has an identifier that can be checked against an official register and when the group chart matches the statutory filings. The signed entity map becomes the reference for every later step.
Build the contract register
Compile an index of every contract with financial entities that the provider has, and every contract with subcontractors that supports the same services. For each record, note the counterparty, the service, the locations where data is processed, the governing terms and the subcontracting links. Contract managers or the commercial team usually own this list, and legal reviews the entries that touch subcontracting. The register is finished when every contract can be traced to one line in the index and each subcontracting arrangement is linked to the service it supports. Ask your legal team to confirm which contracts fall within the requested scope before the index is shared.
Collect governance and security documents
Gather the governance and management body records, the security policies, the audit reports and certifications, and extracts from monitoring and scanning systems that the Regulation's Article 2 lists as available on request. Assign an owner to each document, such as the CISO for security policies or the internal audit function for audit reports. Check the version, the approval date and the scope statement of every document before it enters the library. Management body minutes should be redacted only under counsel's direction. The evidence library is complete when each item has an owner, a version and a recorded approver.
Verify shareholder thresholds and data centre records
Confirm which shareholders hold 25 percent or more of capital or voting rights, since Article 2 of the RTS asks for them by name. Cross-check the shareholder list against the share register and any beneficial ownership filings held in the provider's jurisdictions. Then reconcile the list of data centre locations against facilities records, cloud region settings and the contract register, so that no site appears in one record and not the others. Company secretariat and the infrastructure lead typically sign off this step together. It is done when both lists agree with the source records and the reconciliation is signed.
Set a refresh cycle tied to Lead Overseer requests
Agree how often each part of the pack is reviewed, and set triggers for an earlier refresh, such as a change in shareholding, a new subcontractor, a relocated data centre or a new audit report. Name an owner for the pack as a whole, usually a compliance or oversight coordinator, and keep an audit trail of every update. The Lead Overseer may request information at any time under the supervisory process, so the pack should be ready to be extracted quickly. Confirm the cycle and triggers with your legal and regulatory affairs team, and do not treat any interval as fixed unless it is set by your own policy or by the Lead Overseer's request.
Which documents answer each information request
Delegated Regulation (EU) 2025/295 lists the information a critical provider gives its Lead Overseer, and most of it is already held somewhere in the business. The cards below group that information by request area, name the artifact that answers each request, and set out how to keep each one current between requests.
Legal entity and corporate structure
Keep a current extract of the legal entity identifier, the group structure chart and the register of shareholders holding 25 % or more of capital or voting rights. These answer Article 2 requests on structure and also feed the designation application under Article 1, which asks for the legal entity identifier and corporate structure. Check that the chart matches the shareholder register and the latest filings, and record who approved each version and when.
Contract and subcontractor register
Hold the contracts with financial entity clients and the agreements with each subcontractor in one register, with the services covered, the locations of service delivery and the subcontracting chain. This answers Article 2 requests and feeds the template for subcontracting information in Article 5. Reconcile the register against procurement records each quarter so a new subcontractor cannot appear in a request without a contract on file.
Governance and management body minutes
Keep approved minutes of management body meetings where ICT risk, outsourcing and critical services were discussed, along with the decisions and the named owners of follow-up actions. Requests under Article 2 ask for these minutes, so they must record decisions in enough detail to show oversight, not only attendance. Review each set of minutes before filing and confirm that the approval status and version are recorded.
Security policies and monitoring extracts
Maintain the current security policies, the approval history for each, and dated extracts from monitoring and vulnerability scanning systems. Article 2 names these items directly, and assessors compare the extracts against the policies to check that the stated controls operate. Set a fixed schedule for policy review and for pulling extracts, and retain the query parameters used so each extract can be reproduced.
Data centre location records
Maintain a register of every data centre used to deliver services to financial entities, with its operator, physical address, the services hosted there and any backup or disaster recovery site. Article 2 asks for these locations, and a mismatch with the contract register or the subcontracting chain is an obvious point of challenge. Update the register whenever a site changes or a subcontractor moves hosting, and tie each change to a dated approval.
Audit reports and certifications
Store the independent audit reports and certifications that cover the services in scope, with their issue dates, scope statements and the period each one covers. Article 2 asks for these documents, and an assessor will check whether the scope matches the services named in the contract register. Track expiry dates and gaps between reporting periods, and record any exceptions so they can be explained before the next request arrives.
What preparing oversight information costs and what drives it
This table compares the main cost components of assembling the information Delegated Regulation (EU) 2025/295 asks critical providers to supply. Read it as a checklist for what each component involves, whether it is paid once or recurs, what moves its cost, and what to request in a written quote. No cost figures are supplied for this RTS, so treat the table as a scoping aid rather than a budget.
| Cost component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Legal entity and group structure mapping | One-time, with updates when the group changes | Number of legal entities, cross-border holdings, and shareholders at or above the 25 % threshold | Named deliverables, the entities in scope, and who validates ownership data |
| Contract and subcontractor register build | One-time build, then recurring updates | Count of financial entity contracts and subcontracting chains, and whether records are already centralized | Effort estimate per contract batch, the data fields covered, and the update cadence |
| Evidence collection and document control | Mostly one-time setup, recurring refresh on request | Volume of security policies, audit reports and certifications, and whether versioning and approval records exist | Document inventory, version control approach, and a list of documents the provider will not supply |
| Engineering time to pull monitoring and scanning extracts | Recurring when the Lead Overseer requests extracts | Number of monitoring and scanning systems, log retention, and how much export automation is in place | Hours per extract type, the data sources covered, and the assumptions behind the estimate |
| Internal review before submission | Recurring per submission cycle | Number of reviewers, consistency checks against contracts, and whether legal and security sign off separately | Reviewer roles, review steps, and the number of review rounds included |
| External review or advisory support | Optional, usually per engagement | Scope of independent review, the team's familiarity with DORA oversight, and how much internal work is already complete | Written scope, named deliverables, and effort estimates for each review stage |
Who prepares the information and who assesses it
The ICT third-party service provider carries the legal responsibility for everything it sends to the Lead Overseer. Its internal team decides what the RTS asks for, confirms each figure against its own records, and signs off the response. Legal and compliance map each Article 1 and Article 2 item to an owner. Contracts teams produce the financial entity agreements and subcontractor contracts the RTS requests. Security and engineering supply security policies, data centre locations, monitoring extracts and scanning outputs, and they confirm that those records are accurate as of the reporting date.
- Application content: legal entity identifier, corporate structure, estimated Union market share, services, financial entity clients and the self-assessment of substitutability.
- Shareholding and group data: holders of 25 % or more of capital or voting rights, and the group structure behind them.
- Subcontracting records: the template information on subcontracting arrangements under Article 5.
- Governance evidence: management body minutes and the approvals behind them.
- Ownership of submissions: a named accountable officer who approves each transmission.
The provider usually keeps outsourcing limited to preparation work. Legal opinions, final sign-off and the decision to submit stay in-house. Confirm with your own counsel which items require a legal review before release.
An implementation partner can help the provider organize the evidence behind the RTS. The work is preparation: structuring an evidence library so each requested item has a source document, an owner and a date, pulling monitoring and scanning extracts from the systems that produce them, and running an internal dry run that checks the package against the RTS before the provider sends anything. DeployOpen works in this role. It prepares systems, controls and evidence, but it does not issue assessments, attestations or opinions on whether a submission is adequate.
- Evidence library: an index that maps each Article 1 and Article 2 item to a file, a system of record and a responsible person.
- Monitoring extracts: exports from logging, vulnerability and monitoring tools, with the scope and time window documented.
- Dry run: an internal review of the full package by people who did not assemble it, logged as a gap list for the provider to close.
- Document control: version history and approval records for policies and contracts supplied as evidence.
- Handover: a written record of how each artifact was produced, so the provider can answer follow-up questions without the partner.
The partner's deliverables are inputs to the provider's submission. It does not decide which information is complete for the purposes of the RTS, and it does not represent the provider to the Lead Overseer. Ask any partner to state this boundary in its written scope.
The European Supervisory Authorities, acting as Lead Overseers for designated critical providers, receive and assess the information. Competent authorities for the financial entities that use the provider play a separate role: under Article 6 of the RTS they assess the risks addressed in the Lead Overseer's recommendations and how the provider's response deals with them. Their assessment is a supervisory judgment. It is not an audit report, and no outside firm issues it on their behalf.
- Application review: the Lead Overseer checks whether an application to be designated critical contains the Article 1 content.
- Information requests: the Lead Overseer asks for the Article 2 material and may test its completeness and consistency.
- Recommendation follow-up: competent authorities assess the risks behind each Lead Overseer recommendation and the provider's response.
- Joint examination teams: the composition of these teams is set separately by Delegated Regulation (EU) 2025/420, which is published in the Official Journal.
- Outcomes: the provider's compliance position is determined by the authority, not by its consultants or its own self-assessment.
For any question about how a specific authority will treat a submission, confirm the expectation directly with the authority or the Lead Overseer, through the channels they publish.
Where providers usually fall short on oversight requests
Delegated Regulation (EU) 2025/295 defines what a critical provider must hand the Lead Overseer, and the same information is requested again when recommendations are followed up. The gaps below recur because records are kept by business units or at group level rather than in one evidence set that matches the regulation's categories.
Shareholder records stop at group level
Article 2 asks for group structure and shareholders holding 25 % or more of capital or voting rights. Many providers hold a group chart that names the parent company but not the individuals or entities above it, so the ownership chain breaks at the first holding company. Check that every link from the provider up to its ultimate holders is documented, dated, and traceable to a register extract or equivalent source, and that the 25 % threshold is applied at each level.
Subcontractor chains mapped only one tier deep
Providers usually list their direct subcontractors but not the suppliers those subcontractors rely on. The template for subcontracting information under Article 5 expects the chain to be visible to the Lead Overseer, which means a provider needs to know where critical services end up. Ask each subcontractor to name its own material subcontractors, record that in the same register, and update it when a change is notified.
Contract copies scattered across business units
Article 2 covers contracts with financial entities and with subcontractors. When each business unit signs and stores its own agreements, the provider cannot produce a complete, current set on request, and versions may differ between units. Establish one controlled repository with an index of contracts, owners, and effective dates, and check that the copies in it match the signed originals.
Data centre locations recorded inconsistently
Article 2 requests data centre locations, and the same site may appear under different names, legal entities, or addresses across the asset inventory, the contracts, and the security policies. A Lead Overseer comparing these documents will spot the mismatch quickly. Reconcile site names and addresses against one authoritative list, and confirm which sites hold primary, backup, and recovery data.
Substitutability self-assessments without evidence
Article 1 requires a self-assessment of substitutability in the application for designation. A self-assessment that states a service can be replaced but gives no supporting material invites follow-up questions. For each claim, record the alternative providers considered, the migration steps and their dependencies, and any evidence of tested exit or portability, and mark where the claim is an estimate.
Recommendation responses without owners or tracking
Competent authorities assess how the risks in the Lead Overseer's recommendations are addressed under Article 6. Responses that are sent once and never tracked make it hard to show progress or closure. Assign a named owner to each recommendation, set internal target dates, record evidence for each action, and keep a log that the provider can present to its supervisor.
Questions providers ask about this RTS
Does a financial entity have to produce this information itself?
No. Delegated Regulation (EU) 2025/295 is aimed at ICT third-party providers, not at the financial entities that buy their services. It sets what a provider must include when it applies to be designated as critical, what a critical provider gives the Lead Overseer on request, and the template for subcontracting information. Financial entities still need their own register of information and their own contract and exit arrangements under DORA, but the designation and oversight submissions sit with the provider. Read the Delegated Regulation (EU) 2025/295 text to confirm which articles apply to your organization's role.
How long does preparing these submissions take?
The answer depends on scope, and no fixed duration applies. Preparation time is driven by the number of group entities involved, the number of contracts with financial entity clients and subcontractors, how many services are in scope, and how much security and governance documentation already exists in a form that can be shared. A provider with a well-indexed contract repository and current audit reports will generally move faster than one that must reconstruct its subcontracting chain. Ask any implementation partner for a written schedule tied to the defined scope, with milestones for data collection, review and sign-off.
What does the work require from the provider's own team?
The provider's team must own the facts and the decisions, even when outside help assembles the material. Expect to need named people from legal or contracts, procurement, information security, governance, finance and group structure, plus someone who can speak for the provider's management body. Typical tasks include confirming the legal entity identifier and corporate structure, supplying shareholder information for holders of 25 % or more of capital or voting rights, locating contracts and subcontractor agreements, and approving security policies and monitoring extracts before they leave the organization. Agree these responsibilities in writing at the start so that no gap appears late in the process.
Can a provider prepare these submissions in-house?
Yes, a provider can prepare them in-house if it has staff with the contract, governance, security and regulatory knowledge the RTS requires and enough capacity to run the work alongside its normal operations. Many providers choose a hybrid model, keeping legal and governance sign-off internal while using an outside team to map information requests to existing evidence, close documentation gaps and check consistency across submissions. Whichever model you choose, the provider remains accountable for the accuracy of what it submits, and the competent authority or Lead Overseer decides on designation and oversight.
What does a fixed-scope engagement cover?
A fixed-scope engagement covers the work that is defined in writing before it starts. For this RTS, DORA's implementation partner, DeployOpen, can help map the information categories in the RTS to the provider's systems, documents and contracts, prepare evidence packs, identify gaps in the material the Lead Overseer may request, and organize the subcontracting information into the required template. The engagement does not include legal advice on the provider's obligations, and DeployOpen does not issue designation submissions on the provider's behalf as a certifying body. The written scope should list deliverables, timelines, assumptions and the client's responsibilities. DeployOpen does not publish a price list, so a quote follows from that written scope.
How do I know whether a consultant can help without taking responsibility for the submissions?
A capable consultant will state its role in writing and will not sign or certify the provider's submissions. Ask whether the firm prepares systems, controls and evidence, or whether it claims to issue reports or attestations. Under DORA, only the provider can submit its information, and only the competent authorities and the ESAs make designation and oversight decisions. Ask for the deliverables in the scope, who on the provider's side approves each one, how changes are tracked, and whether the firm has legal counsel involved. Any consultant that promises an outcome, such as designation, should be treated with caution. Request a written quote that separates preparation work from legal review.
How DeployOpen prepares oversight evidence for this RTS
DeployOpen works on the evidence side of Delegated Regulation (EU) 2025/295 Oversight activities RTS: the information a critical ICT provider assembles for its Lead Overseer. We prepare systems, documents and records inside the provider's own infrastructure, while the organization owns its responses and only the competent authorities and ESAs decide on designation and oversight outcomes.
How we scope
- Agree in writing which Article 1 designation items and Article 2 information requests are in the engagement.
- Map each requested document to a named system, owner and existing record in your environment.
- Confirm which subcontracting arrangements fall under the Article 5 template before any work starts.
How we build
- Set up repeatable collection of contracts, subcontractor lists and group structure records in a controlled repository.
- Configure logging and monitoring extracts so they can be exported in a form suitable for Lead Overseer requests.
- Document data centre locations, security policies and audit reports in a consistent, version-controlled format.
How we hand over
- Deliver an index linking each Article 2 information category to its source, owner and retention location.
- Provide a written record of how identified risks from Lead Overseer recommendations were tracked and addressed.
- Train your compliance and engineering staff to maintain the evidence set after the engagement closes.
How we support
- Offer ongoing support as a retainer for updates when information requests or subcontracting templates change.
- Review the evidence set on a schedule agreed in the written scope, so gaps surface before a request arrives.
- Confirm with your competent authority or Lead Overseer which format and channel they expect for submissions.
