Why DORA for ICT service providers starts with your customers' contracts
DORA does not certify ICT service providers, so no authority or auditor will hand you a DORA certificate. The obligations reach you through the contracts your financial entity customers must sign under Article 30 and, for a small group of providers, through direct oversight by the European Supervisory Authorities. When a customer sends a DORA addendum or questionnaire, it is usually asking you to show that your service can meet the terms that customer is legally required to impose. Your organization owns its controls and remains accountable for them. An implementation partner can prepare systems, configurations and evidence, but only an independent auditor or assessor issues reports, and no such report substitutes for the customer's own due diligence.
The answer depends on two questions you should settle before replying. The first is whether your service supports critical or important functions for the customer. If it does, Article 30(3) requires the contract to include precise service level targets, tested business contingency plans, full participation in the customer's threat-led penetration testing, and unrestricted access, inspection and audit rights for the customer, its appointed third parties and the competent authority. If the service does not support such functions, the baseline terms in Article 30(2) still apply, covering service locations, data return on insolvency or termination, and incident assistance. The second question is whether you could be designated a critical ICT third-party provider. Only designated providers fall under the ESAs' Lead Overseer framework, and the ESAs' first list, dated 18 November 2025, names 19 providers. Most providers will never be on that list, so the practical work is contractual.
Start by mapping your customers' likely requests against your current paperwork. Confirm with each customer which of its functions your service supports and whether it has classified those functions as critical or important, because the classification decides which contract terms apply. Then check whether your standard terms state service locations, notice periods for location changes, and the cost basis for incident assistance, since Article 30(2) requires each of these. Ask your legal counsel to confirm how the terms apply in each member state where your customers operate. Document gaps as a short remediation plan with owners and dates, and have it reviewed by your compliance lead before you send any addendum to a customer.
How audit rights and TLPT participation work in practice
For an ICT service that does not support a critical or important function, DORA's contract rules still apply, but the strictest set of audit and testing obligations is not triggered. The financial entity customer needs enough information and access to assess the service, manage its risk and answer its supervisor, and the contract should reflect that. The provider's job is to make its operating evidence available in a form the customer can use, not to open every system to every request. Expect the customer to ask for the following:
- Audit access on defined terms: Written rights to request reports, questionnaires and relevant records, with the procedure, notice and confidentiality conditions agreed in advance.
- Service records: Availability, incident and change records for the services the customer uses, kept in a retrievable form.
- Location and data facts: Confirmation of where services are provided and data is processed, and notice before those locations change.
- Incident assistance: A clear obligation to help the customer with ICT incidents, with cost terms stated in the contract.
- Named contacts: A reachable owner for audit requests and evidence questions.
Before signing, confirm with the customer which of its requests will be handled through standard reports and which will need a formal audit, because that decides what your team must have ready.
When a service supports a critical or important function, the contract must go further. The customer must be able to set precise service level targets, require the provider to implement and test business contingency plans, and take part fully in the customer's threat-led penetration test. The customer, any third party it appoints and the competent authority must also receive unrestricted access, inspection and audit rights. Read these rights as the minimum a supervisor will expect to see in the contract, not as a negotiating opener.
- Unrestricted access and audit: Rights for the customer, its appointed auditors and the competent authority, covering systems, premises and records relevant to the service.
- Full TLPT participation: Cooperation with the customer's threat-led test, including access to personnel and technical scope the test requires.
- Tested contingency plans: Documented business continuity arrangements that the provider has tested, with results available to the customer.
- Service level targets: Measurable targets written into the contract, with reporting that lets the customer verify them.
- Subcontractor flow-down: Audit and security rights passed down to subcontractors that underpin the service.
Check that your logs, access records and test evidence can be produced for an auditor or tester without weeks of preparation, and agree in writing who sets the scope of each audit or test.
Article 26(4) of DORA addresses the case where a provider's participation in a threat-led penetration test could harm its other customers or their data. In that situation, the provider may contract directly with an external tester so that one pooled test covers several financial entities. The test is directed by one designated entity, which is normally one of the financial entities taking part. This option protects shared infrastructure without excluding the provider from testing, but it changes who directs the work and who signs what.
- Trigger: The provider must be able to show concretely how its participation could harm other customers or their data, and this reasoning should be documented.
- Direct contract: The provider, not the customer, contracts with the external tester under this option.
- Designated director: One designated entity directs the pooled test on behalf of the financial entities involved.
- Coordination terms: Scope, timing, data handling and reporting arrangements must be agreed among the provider, the tester and the participating customers.
- Customer coverage: Each participating customer still needs to confirm that the pooled test meets its own TLPT obligations.
Before relying on this option, ask your customers and the competent authority whether the pooled arrangement is accepted for your services, since the outcome depends on their decisions and the scope they set.
Subcontracting, LEI and EUID requests customers will send
Financial entity customers will ask ICT providers for identifiers, subcontracting details and register of information data before they sign or renew. The cards below cover the identifier rules, the subcontracting conditions, the data to keep ready and how to answer those requests without overpromising.
LEI or EUID for legal person providers
Implementing Regulation (EU) 2024/2956 requires customers to identify each provider that is a legal person with a valid and active LEI or EUID. Expect the request to cover your own entity and any subcontractor underpinning a critical service. Confirm that your identifier is registered, active and matches your legal name and registration details before a customer's register submission depends on it.
Subcontractor identifiers for critical services
The same implementing rule requires customers to ensure that subcontractors underpinning critical or important services also hold a valid and active identifier where they are legal persons. Ask your own suppliers for theirs now. A missing identifier at a subcontractor level can delay a customer's register entry even when your own record is complete.
Responsibility stays with the provider
Delegated Regulation (EU) 2025/532 requires that contracts allowing subcontracting of critical services keep the provider responsible for the subcontracted work. Customers will expect you to show how you monitor each subcontractor, pass down security and audit rights, and tell them in time about material changes so they can approve or object.
Notice of material subcontracting changes
Customers must have a notice period to approve or object to material subcontracting changes. Build the notice step into your change process: list which changes count as material, who approves them internally and how the customer is informed. Without this, a planned move to a new hosting or support subcontractor can breach the contract terms agreed with the customer.
Data to hold ready for requests
Keep a current record of your service locations, the subcontractors involved in each service, their identifiers, the data processed and the contract terms that govern them. Customers often ask for this in a single pack. Assign an owner to update it at each subcontracting change so the pack stays accurate between renewals.
Answering register of information requests
When a customer asks for data for its register of information, answer with what your records show and the date they were last checked. Do not promise the customer that its register will be accepted, that a supervisor will be satisfied or that a particular template field will pass validation. Those decisions sit with the financial entity and its competent authority.
How incident assistance and aggregated reporting work for providers
The sequence turns a provider's detection of an ICT incident into timely, accurate information that the customer can use for its own reports, with the customer keeping control of the reporting decision unless it has outsourced reporting by contract.
Detect and classify the incident internally
The provider's monitoring, service desk or security operations team identifies an event affecting the ICT service it supplies to a financial entity. The provider records what it knows about the service affected, the time of detection, the systems involved and whether other customers are touched. The output is an internal incident record with a timestamp and a named owner, which the provider can later show to the customer and to the competent authority if asked.
Notify each affected customer without delay
The provider informs every financial entity customer whose services the incident affects, using the notification route and contacts set in the contract. The contract should state how quickly and through which channel this happens, because the customer needs the information to meet its own classification and reporting duties. The output is a dated notice to each customer, with the provider keeping a copy of what was sent and to whom.
Supply information for the initial notification
The provider gives the customer the facts it needs for the initial report: what happened, when it started, which services and data are affected, and what containment has been done. Where the customer has asked for it, the provider also confirms whether the incident has a cross-border effect. The output is a written information pack that the customer can check against its own records before it files anything.
Provide updates for the intermediate and final reports
As the incident develops, the provider supplies updates on root cause, recovery progress, impact on the customer's clients and any changes to the figures already given. Each update is tied to a time and a version so the customer can reconcile what it reports to its authority with what the provider has said. The output is a running log of provider statements that the customer's incident file can reference at each reporting stage.
Confirm whether reporting is outsourced
The customer decides whether it reports the incident itself or whether the contract gives the provider authority to submit reports on its behalf. Only a contract that assigns this task to the provider changes who files. The output is a written statement in the contract or incident procedure, which both parties can point to, showing whether the provider reports or only supplies information.
Prepare an aggregated report with authority permission
Where the provider is the source of an incident that affects several financial entities in one member state and reporting has been outsourced to it, the provider may ask the competent authority to allow one aggregated report covering them. Implementing Regulation (EU) 2025/302, Article 7 sets this option, and it applies only once the authority has given permission. The output is a permission request and, if granted, a single report that maps each affected entity to its part of the incident.
Close the incident and record the evidence
After service is restored, the provider completes a post-incident review, records the root cause and corrective actions, and sends the final information to each customer. The provider keeps the incident file, notifications, reports and permissions together so that customers and supervisors can inspect them. The output is a closed incident record that the customer can add to its own register of incidents and its review of the provider.
When an ICT provider can be designated critical
A provider becomes subject to direct ESA oversight in one of two ways. The first is designation by the European Supervisory Authorities under Article 31, which the ESAs use to name critical ICT third-party service providers after assessing criteria such as the systemic impact of their services on financial entities. The second is a voluntary application under Article 31(11), open to providers not already on the list. Under Delegated Regulation (EU) 2024/1505, the ESAs decide an application within 6 months, and the applicant pays a non-refundable fee of EUR 50 000 (Article 4(3)) whatever the outcome. Before spending that money, a provider should check whether it is excluded at all. Article 31(8) removes ICT intra-group providers, financial entities that provide ICT services to other financial entities, providers already overseen under Eurosystem frameworks, and providers that serve only financial entities active in a single member state.
Exclusion is a legal question that depends on who the provider's customers are and where they operate, so a provider should confirm its own status with counsel before relying on any of these carve-outs. Customer mix changes over time, and a provider that once served only one member state may find that it no longer qualifies for the single-state exclusion. Track the customer footprint against each exclusion category and record the reasoning, since financial entity customers will ask for it during their own third-party risk reviews.
Third-country providers face an extra condition. Under Article 31(12), a designated critical provider established outside the Union must set up a subsidiary in the Union within 12 months of designation for financial entities to keep using it. Providers should also expect the designation list to be a living document. The ESAs' first list, dated 18 November 2025, names 19 providers across core infrastructure and business and data services. Confirm the current list and any changes directly with the ESAs and with your financial entity customers, and plan the designation route, the subsidiary timeline and the cost of an application as part of your DORA contract strategy.
What your team owns, what a partner can prepare, and what an auditor issues
DORA sets no certification, so no one can certify an ICT provider as DORA compliant. Responsibility splits across four roles: the provider owns its controls and contract responses, a partner prepares systems and evidence, the customer and competent authority supervise the contract, and an independent auditor issues any report.
Provider owns controls and contract answers
The ICT provider remains accountable for its own security controls, service levels, business continuity plans and the answers it gives customers under their contracts. A partner can help build these, but the provider must decide them, sign off on them and be able to explain them to a customer or supervisor. Check that named managers own each control area and that someone can answer customer questions about subcontractors and data locations without delay.
Partner prepares documentation and evidence
An implementation partner such as DeployOpen can prepare documentation, evidence packs, logging and access configuration inside the provider's own cloud accounts, data centers or air-gapped networks, and test readiness before a customer audit or supervisory request. This work is scoped and delivered in writing. The partner does not issue reports, attestations or certificates, and it does not take over the provider's accountability for what the systems actually do.
Customer and authority supervise the contract
Financial entity customers must write the contract terms DORA requires, including audit and inspection rights, incident assistance and data return. The customer and its competent authority can then test whether the provider delivers those terms. For services supporting critical or important functions, expect requests for access to logs, business continuity test results and subcontractor details. Ask early which evidence each customer will request so the provider can prepare it once.
Independent auditor issues any report
Only an independent auditor, assessor or certification body can issue a report on a provider's controls. DORA does not provide one, and the one attestation the Regulation provides for, under Article 26(7), concerns a threat-led penetration test and is issued by an authority, not a provider or auditor. Treat any offer of a DORA certificate for a provider as a warning sign, and confirm what an assessor will examine and what it will issue before engaging one.
Questions ICT providers ask about DORA
Does DORA apply directly to an ICT provider without a contract?
DORA binds financial entities directly, and it reaches ICT providers mainly through the contracts those entities sign. Article 2(1) lists ICT third-party service providers at point (u), so the Regulation names them, but the day-to-day duties a provider meets come from the clauses its financial entity customers must impose under Article 30. A provider that serves EU financial entities should expect those clauses to appear in its agreements, and it should check which of its services support critical or important functions, because that choice sets how demanding the terms are. Direct designation as a critical provider is a separate track that applies only to providers the ESAs choose to oversee. Confirm the exact application of point (u) with a qualified lawyer before relying on it in a contract.
How much work does a customer's DORA addendum usually need?
The effort depends mostly on how critical the service is to the customer and how much of the addendum is already covered by existing terms. Services supporting critical or important functions carry the heaviest requirements under Article 30(3), including precise service level targets, tested business continuity plans, full participation in the customer's threat-led penetration testing, and unrestricted audit and access rights. Other services need fewer clauses, but the location, data return and incident assistance terms under Article 30(2) still apply. Providers should map each clause to an existing policy, log, or report before negotiating, because most delay comes from clauses that need new evidence. Ask the customer which of its services it has classed as critical or important, and ask for its addendum template early.
Can a provider handle DORA contract work in-house?
A provider can handle much of the work in-house, especially the clause mapping, evidence gathering and security documentation, provided it has staff who understand both the contract and the technical controls. Work usually needs outside help where the provider lacks a clear view of its own subcontractors, its data locations or its recovery testing record, or where it must set up a TLPT pooled test under Article 26(4). The cost of in-house work is mostly internal time, which recurs each time a customer renews or changes its addendum. External help, where used, is paid for scoped work such as a gap review or a test. Ask any partner for a written scope before work begins, and keep ownership of the contract and its evidence with the provider.
What should an ICT provider ask for before signing a DORA contract?
A provider should ask for the clauses it must accept, the scope of its services mapped to the customer's critical or important functions, and the cost terms for incident assistance. Article 30(2) requires assistance with ICT incidents at no additional cost or at a cost set in advance, so the provider should agree that figure before signing. It should also confirm notice periods for location changes, data return terms on insolvency or termination, and the procedure for subcontracting approvals under Delegated Regulation (EU) 2025/532, which gives customers a notice period to approve or object to material changes. Under Implementing Regulation (EU) 2024/2956, each legal-person provider and critical subcontractor needs a valid and active LEI or EUID, so ask the customer what identifier it expects. Read the full terms with counsel.
Does DORA require an ICT provider to be certified?
No. DORA sets no certification scheme, so no authority or auditor issues a DORA certificate to a provider. Competent authorities supervise compliance using the powers in Article 50, and customers test providers through their contracts, audit rights and assurance evidence. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7), and that concerns the financial entity's test rather than the provider. Providers often still obtain independent assurance reports or standards certifications because customers ask for them during due diligence, but those are commercial choices, not DORA requirements. Ask each customer which evidence it will accept.
When does critical designation become a realistic question for a provider?
Designation becomes a question when a provider serves many financial entities and its services are hard for them to replace. The ESAs designate critical ICT third-party providers, and their first list, dated 18 November 2025, names 19 providers offering services ranging from core infrastructure to business and data services. Article 31(8) excludes some providers, including intra-group providers and those serving only financial entities active in a single member state. Providers not on the list may apply under Article 31(11), where the ESAs decide within 6 months and the applicant pays a non-refundable fee of EUR 50 000 under Delegated Regulation (EU) 2024/1505, Article 4(3). Third-country providers designated as critical must set up a Union subsidiary within 12 months. Review the criteria and the Commission's 2028 review with counsel before deciding.
How DeployOpen prepares ICT providers for customer DORA requirements
DeployOpen helps ICT service providers prepare the systems, controls and evidence that financial entity customers will ask for under DORA. We plan and implement self-hosted open-source platforms inside the client's own infrastructure, then document what they do, and an independent auditor or assessor issues any report.
How we scope
- We agree a written scope covering which services, customers and contract clauses the work addresses.
- Scope names the customer requirements in play, such as audit access, incident assistance and subcontracting notices.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work starts.
How we build
- We implement or harden self-hosted open-source platforms within your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access controls and backups so that operational evidence is produced as a by-product of running the service.
- Where needed, we run security testing on applications, APIs and infrastructure and track remediation of the findings.
How we hand over
- We deliver architecture records, configuration documentation and evidence packs mapped to the requirements named in scope.
- Your staff receive runbooks for incident handling, recovery testing and subcontractor monitoring they can operate without us.
- Your organization keeps ownership of its controls, contracts and reports, and an independent auditor or assessor issues any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial work.
- We can keep documentation and evidence current as platforms change, customers add requirements or contracts are renewed.
- Ask for a written quote that lists scope, deliverables, responsibilities and any recurring retainer costs before you commit.
