DORA and Identity Verification Providers: What a Financial Entity Must Ask of an ICT Third-Party Service

For information; not legal advice.

A bank that verifies a new customer through a vendor's application programming interface has handed one step of its onboarding to someone else. Before the regulation applied, the rules for that handover were scattered across guidelines on outsourcing and, in some Member States, circulars of the national supervisor. Since 17 January 2025 the European Union has had one regulation that governs the relationship between a financial entity and the providers of its digital services, and a verification vendor sits inside it. This article reads that regulation from the side of a buyer of identity verification and from the side of the vendor who has to answer the buyer, and it asks three plain questions. Is a verification service within the regulation. What does the buyer have to do before it signs, in the contract and afterwards. What does the vendor have to be able to hand over.

The article is a reading aid and not a compliance opinion. It does not say that any firm or product complies with the regulation. It contains no statement about the compliance of the company that publishes this site, and no such statement should be inferred from it.

Four limits of the sources are stated here, before the detail. First, the regulation and the Commission's technical standards were read in the Official Journal versions published by the Publications Office of the European Union. Second, the web pages of the European supervisory authorities for banking and securities could not be opened in the way the fetch tool works, so the register of information was read through the implementing regulation itself, through a question-and-answer document that the banking authority published as a PDF, and through the list of designated critical providers that the securities authority published as a PDF. Third, the question-and-answer document is staff material and says of itself that it gives no legal interpretation, so the dates taken from it should be checked against the current version. Fourth, the Commission's answer on what counts as an ICT service is known here only through a notice of the Luxembourg supervisor, and the answer itself was not read.

For the surrounding European framework, see the article on the EBA guidelines on remote customer onboarding and the articles on retention and erasure of identity data and on the verification session lifecycle.

What the regulation covers, and who it binds

The regulation is Regulation (EU) 2022/2554, on digital operational resilience for the financial sector, signed on 14 December 2022 and published in the Official Journal on 27 December 2022. It says in its last article that it applies from 17 January 2025. The Commission's page of implementing and delegated acts describes the regulation as giving the Commission the power to adopt acts that specify how competent authorities and market participants comply with its obligations.

The scope article lists the entities to which it applies. Among them are credit institutions, payment institutions including exempted ones, account information service providers, electronic money institutions, investment firms and crypto-asset service providers, together with trading venues, insurers and many other kinds of financial firm. The last item on the list is ICT third-party service providers, which are therefore subject to the regulation themselves, and the regulation calls the entities on the earlier items collectively "financial entities". The article also removes some firms from the scope, such as certain managers of alternative investment funds and small pension institutions, and lets Member States exclude some national institutions.

For the purposes of this article, the relevant financial entities are the ones that must verify customers: credit institutions, payment and electronic money institutions, investment firms and crypto-asset service providers. The same list is the customer base of most verification vendors in the European market. The article on crypto-asset service providers and the transfer rules covers the anti-money laundering side of one of these groups, and this article covers the operational side.

Is a verification service an ICT service

The answer depends on two definitions. The regulation defines "ICT services" as digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services, and excluding traditional analogue telephone services. It defines an "ICT third-party service provider" as an undertaking providing ICT services. The definitions are in the article on definitions, as points 19 and 21 of the list.

A verification service that a financial entity calls through an interface or embeds through a software development kit is a digital service provided through ICT systems to an external user. Whether it is provided "on an ongoing basis" is a question of the contract. A contract for continuing use of the service, with a service level, falls within the words; a single one-off engagement would be a different matter. That is the article's reading of the definition and not a finding of any authority.

The Luxembourg supervisor, in a communiqué of 9 April 2025, draws the attention of supervised entities to the joint questions and answers of the European supervisory authorities on what types of services are ICT services. It says that the Commission's answer confirmed that the definition of ICT services intentionally maintains a broad scope. It strongly recommends that supervised entities review the answer in detail, whether they are in scope of the regulation themselves or provide services to entities that are. The supervisor adds that financial services provided by professionals of the financial sector are not ICT services, except for a defined group of services under its national law on the financial sector, which in its view are ICT services in all cases.

The register of information, discussed below, has a closed list of types of ICT services, numbered from S01 to S19. The list includes ICT development, ICT security management services, the provision of data, data analysis, ICT consulting, and the three forms of cloud service. It has no entry named for identity verification, so a financial entity has to pick the nearest type, and the choice is the entity's.

Critical or important function

The heaviest duties attach not to every ICT service but to ICT services that support a critical or important function. The regulation defines such a function as one whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or whose discontinued, defective or failed performance would materially impair the continuing compliance of the entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law.

Whether the onboarding of customers is such a function for a given firm is for the firm to decide, and the regulation does not decide it. The policy standard of the Commission requires the firm's policy to establish or refer to a methodology for determining which ICT services support critical or important functions, and to specify when the assessment is conducted and reviewed. A firm for which a failure of the verification step would stop it from opening accounts at all, and from meeting its own duty to verify identity, has a reason to ask the question about that step. That, again, is a reading.

The distinction matters because it decides how much the contract has to contain, how the firm gets out of it, and whether the firm has to tell its supervisor in advance. The sections below follow that order.

Before the contract

The regulation sets general principles for the management of ICT third-party risk in the article on general principles. A financial entity that has contractual arrangements for ICT services remains fully responsible for compliance with all its obligations under the regulation and under financial services law. Management of the risk is to be proportionate to the nature, scale, complexity and importance of the dependencies.

Before entering into a contractual arrangement, the entity has to do five things.

1. Assess whether the arrangement covers ICT services supporting a critical or important function.
2. Assess whether the supervisory conditions for contracting are met.
3. Identify and assess all relevant risks, including the possibility that the arrangement reinforces ICT concentration risk.
4. Undertake all due diligence on the prospective provider and ensure throughout selection and assessment that the provider is suitable.
5. Identify and assess conflicts of interest that the arrangement may cause.

The entity may enter into contractual arrangements only with providers that comply with appropriate information security standards. Where the arrangement concerns critical or important functions, the entity has to take due consideration, before concluding it, of the use by the provider of "the most up-to-date and highest quality information security standards", in the words of Article 28(5).

Concentration

The next article requires a preliminary assessment of concentration risk. The entity has to take into account whether a planned arrangement for a critical or important function would lead to contracting a provider that is not easily substitutable, or to having multiple arrangements for such services with the same provider or closely connected providers. It has to weigh the benefits and costs of alternatives, such as using different providers. Where the arrangement allows subcontracting, it has to weigh the benefits and risks, particularly for a subcontractor established in a third country, to consider the insolvency law that would apply and any constraint on urgent recovery of its data, and to assess whether long or complex chains of subcontracting affect its ability to monitor the functions and the supervisor's ability to supervise it. Where the provider is established in a third country, it also has to consider compliance with Union data protection rules and the effective enforcement of the law in that country.

For a vendor, this part of the regulation turns into questions about where the service runs, who else it depends on, and how easily a customer could leave.

The Commission's standard on the policy

A delegated regulation of the Commission, Delegated Regulation (EU) 2024/1773, specifies the content of the policy that the entity must have on the use of ICT services supporting critical or important functions. It requires the policy to take account of the type of service, the location of the provider and of its parent company, whether the service is provided from a Member State or a third country, the nature of the data shared, whether the provider is supervised, whether the service is concentrated in one provider or a few, and how transferable the service is.

On due diligence it lists what the entity must assess before contracting: the provider's business reputation, abilities, expertise and resources, its information security standards, its organisational structure and internal controls, whether it uses subcontractors, whether it is located or processes or stores data in a third country, whether it consents to audits including on site, and whether it acts in an ethical and socially responsible manner. The standard lets the entity draw its level of assurance from five kinds of source: audits or independent assessments by the entity or on its behalf, independent audit reports made on request by the provider, audit reports of the provider's internal audit function, appropriate third-party attestations, and other relevant information. It adds that more than one kind should be used where appropriate.

The same standard limits what a firm may rely on over time. The firm shall not rely solely on third-party attestations or on audit reports of the provider over time, and the policy may allow them only where the firm is satisfied, among other things, that the scope covers the systems and key controls the firm identified, that the content is assessed on an ongoing basis and is not obsolete, that the issuing party is apt, and that the firm keeps the contractual right to request changes of scope and to perform individual and pooled audits. For a vendor, the consequence is that a document from an outside party is accepted as one input, and that the buyer's own audit right is expected to remain.

What the contract must contain

The article on key contractual provisions is the part of the regulation that a vendor's lawyers read first. It requires the rights and obligations of the entity and the provider to be clearly allocated and set out in writing, with the full contract including the service levels in one written document available in a durable and accessible format.

It then lists elements that the contract shall include for every ICT service, and a longer list for services that support critical or important functions. The table sets out the first list, with a reading in the third column of what each element means for a verification service. The third column is the article's reading and not the text of the regulation.

Additional elements for critical or important functions

For services that support critical or important functions the contract has to add the following elements.

• Full service level descriptions with precise quantitative and qualitative performance targets, to allow effective monitoring and corrective action without undue delay.
• Notice periods and reporting obligations of the provider, including notification of any development with a material impact on its ability to provide the services at the agreed levels.
• Requirements for the provider to implement and test business contingency plans and to have ICT security measures, tools and policies that give an appropriate level of security.
• The provider's obligation to participate and cooperate fully in the entity's threat-led penetration testing.
• The entity's right to monitor the provider's performance on an ongoing basis, with unrestricted rights of access, inspection and audit by the entity or an appointed third party and by the competent authority, and the obligation to cooperate during on-site inspections.
• Exit strategies, in particular a mandatory adequate transition period during which the provider continues to provide the functions or services, and which allows the entity to migrate to another provider or to bring the service in-house.

A derogation lets a microenterprise and the provider agree that the entity's audit rights are delegated to an independent third party appointed by the provider. The same article asks both sides to consider the use of standard contractual clauses developed by public authorities for specific services. In the text read for this guide the Commission's page does not list such clauses for verification services, and a firm should not assume that any exist.

Termination

The regulation lists the circumstances in which the entity must be able to terminate. They are a significant breach of law or of contract by the provider; circumstances found in monitoring that could alter the performance of the functions, including material changes affecting the arrangement or the provider; evidenced weaknesses in the provider's ICT risk management, in particular in the way it ensures the availability, authenticity, integrity and confidentiality of data; and a situation where the supervisor can no longer effectively supervise the entity because of the arrangement. A vendor contract written for the whole market usually does not give a customer all four rights, and a European bank will ask for them.

Subcontractors

A verification service is rarely one company's software end to end. It may run on a hosting provider, use a separate component for one step, and send messages through another company. The regulation answers this with a delegated regulation of its own, Delegated Regulation (EU) 2025/532, published in the Official Journal on 2 July 2025, on the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions.

Before signing, the entity decides whether the provider may subcontract such a service, and enters into the contract only where it has assessed that a set of conditions holds. They include that the provider is able to select and assess the abilities of its subcontractors, to identify all of them and notify the entity, and to give the entity the information it needs; that the provider's contracts with its subcontractors enable the entity to meet its own obligations; and that the subcontractor grants the entity and the authorities the same contractual rights of access and inspection as the provider does. The entity must also have assessed the effect of a possible failure of a subcontractor, the risks of the subcontractors' locations, and concentration risk. Reliance on the provider's own assessment of its subcontractors does not limit the entity's final responsibility.

The contract must then say which services may be subcontracted and on what conditions, and it must specify, among other things, that the provider is responsible for the services its subcontractors provide and monitors them, the monitoring and reporting duties towards the entity, the location of data processed or stored by the subcontractor, continuity of the service throughout the chain if a subcontractor fails, the business contingency and security requirements that flow down to the subcontractors, and the duty to notify the entity of any material change to the subcontracting.

Changes to the chain

The standard sets a procedure for material changes. The contract shall oblige the provider to inform the entity of any intended material change to its subcontracting in good time for the entity to assess the effect on its risks and on the provider's ability to meet its obligations. The contract shall contain a reasonable notice period within which the entity approves or objects, and the provider shall implement the change only after the entity has approved it or has not objected by the end of the period. Article 4(1), point (l), requires the contract to specify that the financial entity has the right to terminate the contract when the conditions laid down in Article 6 of the standard, or in Article 28(7) of the regulation, have been fulfilled. Article 6 then says that the entity has the right to provide in the contract that it is to terminate in three cases. In the first, the entity objected to material changes to the subcontracting and requested modifications, but the provider implemented the changes anyway. In the second, the provider implemented material changes before the end of the notice period without the entity's approval. In the third, the provider subcontracts an ICT service that supports a critical or important function and that the contract does not explicitly permit to be subcontracted. Having the right in the contract is a different thing from using it, and whether to terminate in a given case remains the entity's decision.

For a verification vendor, the practical meaning is a change process for the technical chain: a new hosting region, a new component for one step, a new messaging provider. Under the standard these are material changes if they affect a service that supports a critical or important function, and the vendor cannot make them on its own timetable. That is a reading, and whether a particular change is material is for the entity to judge.

The register of information

The regulation requires every financial entity to maintain and update a register of information on all its contractual arrangements for ICT services provided by third-party providers, at entity level and at sub-consolidated and consolidated levels. The register must distinguish arrangements that cover services supporting critical or important functions from those that do not. The entity reports to the competent authorities at least yearly on the number of new arrangements, the categories of providers, the type of arrangements and the services and functions provided, and gives the authority the full register on request. It must also inform the authority in a timely manner about any planned arrangement for a critical or important function and when a function becomes critical or important.

The templates are in Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024. The recitals of the implementing regulation describe the register as built on keys that link the data across the templates, and the articles require the entity to ensure that the information is accurate and consistent, and to apply the data quality principles of accuracy, completeness, consistency, integrity, uniformity and validity.

What the register asks about a provider

Three requirements reach the vendor directly.

1. Identification. The entity must use a valid and active legal entity identifier or the European Unique Identifier, and where both are available both, to identify each provider that is a legal person. For a subcontractor that effectively underpins a service supporting a critical or important function, the entity must ensure through the direct provider that the subcontractor uses a valid and active identifier or provides its European Unique Identifier.
2. Rank. The entity assigns each provider a rank in the supply chain, and the rank of the direct provider is always one, while the rank of a subcontractor is always higher than one.
3. Subcontractors. The register must include information on all subcontractors that effectively underpin services supporting critical or important functions or material parts of them.

The template that assesses services supporting critical or important functions is numbered B_07.01. It asks, among other things, for the type of ICT service from the closed list; the substitutability of the provider, on a scale of not substitutable, highly complex, medium complexity and easily substitutable; where the provider is hard to substitute, the reason, which is either the lack of real alternatives or the difficulty of migrating data and workloads; the date of the last audit; whether an exit plan exists; the possibility of reintegrating the service, as easy, difficult or highly complex; and the impact of discontinuing the service, as low, medium or high. The instructions say that, where no audit has been performed, the date field is filled with 9999-12-31.

None of these fields can be filled in by the vendor, since each is the entity's own assessment. But a vendor can make the entity's task short or long, and the practical list of what a vendor should hand over is in the section on questions.

Dates

The banking authority's question-and-answer document of 28 March 2025 gives the reporting dates as follows. For the first reporting round, the competent authorities were to report the registers to the European supervisory authorities by 30 April 2025, with a reference date of 31 March 2025. From 2026 onwards, the deadline for competent authorities to report the registers to the authorities is 31 March of each calendar year, and the reference date is 31 December of the preceding year. The document is staff material, says that it gives no legal interpretation, and says that financial entities provide their registers to their competent authorities first. The dates by which each entity must give its register to its own supervisor are set nationally, and the document does not state them.

Luxembourg offers one national example. Its supervisor published a notification form for planned arrangements for critical or important functions, and said that the notification must be made as early as possible before the planned implementation date, and in any case at least three months before, or one month before when a Luxembourg support professional of the financial sector is used. It also said that arrangements in place before 17 January 2025 that were not notified under Circular CSSF 22/806 because they do not qualify as a critical or important ICT outsourcing under that circular are not required to be submitted as notifications, though they need to be listed in the Register of Information. The exception is therefore narrow, and it does not excuse a notification that was mandatory under the earlier circular and was missed. A buyer in another Member State should look for its own supervisor's rule.

Exit

The regulation requires exit strategies for services supporting critical or important functions. They have to take into account risks at the level of the provider, such as failure, deterioration of quality, business disruption and termination. The entity must be able to exit without disruption to its business, without limiting its compliance with regulatory requirements and without detriment to the continuity and quality of its services to clients. Exit plans must be comprehensive, documented and sufficiently tested and reviewed periodically, and the entity must identify alternative solutions and develop transition plans that enable it to remove the contracted services and the data from the provider and transfer them securely and integrally to other providers or in-house.

The Commission's standard on the policy repeats the point at the level of each contract. It requires a documented exit plan for each arrangement and its periodic review and testing, based on plausible scenarios, with a schedule compatible with the exit terms of the contract.

Exit has a special meaning for a verification service, because the service produces records. A bank that changes vendor still has customers whose verification was done under the old one. The records the contract must return in an easily accessible format include the data the service processed, and whether they are enough to show an examiner how a past customer was verified is a question for the exit plan. The article on receiving results by polling or webhook describes what a result contains, and the article on retention explains why the bank, and not the vendor, usually holds the long-term record.

Oversight of critical providers

The regulation also sets up a direct oversight framework for the ICT providers that matter most to the sector. The European supervisory authorities, through their Joint Committee, designate the providers that are critical for financial entities, on criteria that include the systemic impact of a large-scale failure, the systemic importance of the entities that rely on the provider, the reliance of entities on its services for critical or important functions, and the degree of substitutability. The authorities publish and update the list yearly. The designation does not apply, among others, to financial entities that provide ICT services to other financial entities, to intra-group providers, or to providers that serve only financial entities active in a single Member State.

The list published by the authorities on 18 November 2025 names 19 providers. The article does not name them. Designation concerns providers that are critical across the sector, and it is not a mark of quality for any provider or a condition for being used by financial entities. A provider that is not designated is still a provider whose contract, subcontractors and exit the entity must manage under the articles above.

What the regulation does not do

The regulation does not decide how a customer's identity must be verified. That is the subject of the anti-money laundering rules, and the EBA guidelines article reads them. The two sets of rules meet where a bank outsources a verification step: the anti-money laundering rules say what the step must achieve, and this regulation says how the relationship with the provider that performs it is to be run.

The articles read for this guide create no approval scheme for ordinary providers. They set duties for the financial entity, and they set an oversight framework for designated critical providers. A statement by a vendor that it is ready for the regulation is therefore a statement about its contract terms, its records and its subcontractors, and the buyer can test it against the lists above.

What a firm can decide now

The texts leave room, and a firm has to use it with a reason. Six decisions follow from the reading above.

1. Decide whether the verification step supports a critical or important function, write the reasoning down, and review it when the step changes.
2. Decide the type under which the service is recorded in the register, and who owns the entries.
3. Decide which subcontracting the contract allows, and the notice period within which the firm approves or objects to a change in the chain.
4. Decide which outside documents the firm accepts as assurance about the provider, and how the firm keeps its own audit right alive beside them.
5. Decide the exit scenario in advance: where the records go, in what format, and how verified customers are handled if the vendor changes.
6. Decide who answers the supervisor's request for the register, and from which source the entries are produced.

Questions to put to a provider

• Which legal entity signs the contract, and what are its legal entity identifier and European Unique Identifier?
• Which subcontractors does the service use, in which order in the chain, and in which countries do they process or store data?
• How and when does the provider notify a change to that chain, and how long a notice period does it accept for the customer to object?
• In which regions are images, extracted fields and results processed and stored, and what notice does the provider give before changing them?
• What does the provider supply for the customer's own audit: access to the provider, on-site if needed, and for the supervisor?
• What service levels does the provider commit to, with which quantitative targets, and how are they reported?
• What help does the provider give in an incident, and at what price, set before the incident?
• What can the customer export at the end of the contract, in what format, and for how long after termination?
• What transition period does the provider offer, and how does the provider support the customer's exit test?

Where this sits in a verification flow

A flow built on NeuroVision KYC places the identity steps in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The individual steps are described on the document verification page. This article does not state that these steps, or any service of the company that publishes this site, meet the requirements of the regulation, and it makes no claim about the company's own position under it.

To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 28 October 2026.

• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, Publications Office of the European Union, Official Journal of 27 December 2022.
• Delegated Regulation (EU) 2024/1773 on the policy regarding contractual arrangements for ICT services supporting critical or important functions, Publications Office of the European Union.
• Delegated Regulation (EU) 2025/532 on subcontracting of ICT services supporting critical or important functions, Publications Office of the European Union, 2 July 2025.
• Implementing Regulation (EU) 2024/2956 on standard templates for the register of information, Publications Office of the European Union, 2 December 2024.
• Implementing and delegated acts, Digital Operational Resilience Regulation, European Commission.
• Frequently asked questions: reporting of registers of information under DORA, European Banking Authority, version of 28 March 2025.
• List of designated critical ICT third-party service providers, European supervisory authorities, 18 November 2025.
• Definition of "ICT services" under DORA and new forms for ICT third-party arrangements, Commission de Surveillance du Secteur Financier, Luxembourg, 9 April 2025.