DORA governs how financial entities manage ICT risk, and through their contracts it reaches every ICT provider that serves them. We help both sides prepare: the financial entity that must comply, and the provider that must prove it can be relied on.
For
You receive
Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025. It requires financial entities to keep a documented ICT risk-management framework under the responsibility of the management body (Articles 5 to 16, with a simplified framework for certain smaller entities in Article 16), to classify ICT-related incidents and report major ones to their competent authority through an initial notification, an intermediate report and a final report (Articles 17 to 19), and to run a digital operational resilience testing programme (Articles 24 and 25). Entities identified by their competent authority must also carry out threat-led penetration testing (TLPT) at least every three years, on live production systems supporting critical or important functions (Articles 26 and 27).
For an ICT provider, DORA works mainly through the customer. Financial entities remain fully responsible for compliance when they use ICT services (Article 28(1)). Before contracting they must carry out due diligence and use only providers that comply with appropriate information security standards (Article 28(4) and (5)). They record every ICT services contract in a register of information (Article 28(3)), and the contract must contain the provisions of Article 30. For services supporting critical or important functions, those provisions include precise service levels, business contingency plans and their testing, participation in the customer's TLPT, unrestricted rights of access, inspection and audit for the customer and its competent authority, and exit arrangements with a transition period. Where a provider's participation in TLPT could affect the quality or security of services to customers outside DORA's scope, or the confidentiality of their data, the parties may agree in writing on pooled testing, directed by one designated financial entity (Article 26(4)).
Some providers are designated as critical by the European Supervisory Authorities, on criteria such as systemic impact and substitutability (Article 31). The ESAs published their first list of designated critical providers on 18 November 2025 and must update it every year (Article 31(9)). Those providers come under direct oversight by a Lead Overseer, which can request information, conduct investigations and inspections, and issue recommendations (Article 35). For managed security service providers, Regulation (EU) 2025/37 brought managed security services into the Cybersecurity Act certification framework, and EUMSS is the candidate European scheme for them. Certification of that kind could support a customer's due diligence, but it would not replace the Article 30 clauses, the customer's own audit and access rights or its register of information.
Which of your services support your customers' critical or important functions, which Article 30 provisions each contract must therefore carry, where TLPT participation and audit rights apply, and whether the designation criteria of Article 31 are relevant to you.
Typical duration: 2 to 3 weeks
Clause-by-clause positions for Article 30(2) and 30(3): service descriptions and subcontracting, data locations, incident assistance, cooperation with authorities, audit and inspection rights, alternative assurance levels, TLPT participation and exit. Written for your legal counsel to adapt and use in negotiations.
Typical duration: 3 to 4 weeks
One indexed set of policies, procedures and records mapped to the questions financial customers typically ask in due diligence, and to the NIS2 Article 21 risk-management measures where your organisation is also a NIS2 entity. Each answer points to evidence, so questionnaires stop being written from scratch.
Typical duration: 4 to 8 weeks
Gap analysis of governance, the framework itself, incident classification and reporting procedures, the testing programme and the ICT third-party risk strategy against Articles 5 to 30, with a prioritised remediation plan.
Typical duration: 4 to 8 weeks
For a financial entity, or a provider expected to take part in a customer's test: scoping of critical or important functions and the systems behind them, risk management controls for testing on production, tester requirements under Article 27, and the conditions for pooled testing, mapped to Delegated Regulation (EU) 2025/1190, which mirrors TIBER-EU, and to your TLPT authority's practice. We do not perform the test.
Typical duration: 3 to 5 weeks
For managed security service providers: a gap review of your service against the current draft of the candidate EUMSS scheme, with a note on how the same evidence supports DORA due diligence from financial customers and NIS2 obligations.
Typical duration: 3 to 6 weeks
Unless a provider is designated as critical under Article 31, DORA addresses its obligations to the financial entity, not to the provider. They reach the provider through the contract: the Article 30 provisions, audit, access and inspection rights for the customer and its competent authority, cooperation with authorities, incident assistance, exit support and, for services supporting critical or important functions, participation in the customer's TLPT. In practice a provider that cannot meet these terms becomes difficult to contract.
Every ICT services contract must cover, among others, a full description of the services and subcontracting conditions, the locations where services are provided and data is processed, data protection and return of data, service levels, incident assistance at no additional cost or at a cost set in advance, cooperation with competent and resolution authorities, termination rights with minimum notice periods and participation in security awareness training (Article 30(2)). For critical or important functions, Article 30(3) adds precise performance targets, notification duties, business contingency testing, TLPT participation, unrestricted access, inspection and audit rights, and an exit strategy with a mandatory transition period.
Article 28(3) requires financial entities to keep a register of all contractual arrangements for ICT services provided by ICT third-party service providers, at entity, sub-consolidated and consolidated level, distinguishing those that support critical or important functions. The full register must be available to the competent authority on request, and its standard templates are set by Implementing Regulation (EU) 2024/2956. Providers are asked for the data that feeds it, including their legal entity identifier and, for services supporting critical or important functions, the subcontractors that effectively underpin them.
If your ICT services fall within the scope of a financial entity's threat-led penetration test, the entity must ensure your participation (Article 26(3)), and contracts for critical or important functions must oblige you to cooperate (Article 30(3)(d)). Where your participation could affect the quality or security of services to customers outside DORA's scope, or the confidentiality of their data, you and the entity may agree in writing on pooled testing: you contract an external tester directly, under the direction of one designated financial entity, and the test counts for each participating entity (Article 26(4)).
A managed security service provided to a financial entity on an ongoing basis falls within DORA's definition of ICT services, so the provider is an ICT third-party service provider and the contractual requirements above apply. Regulation (EU) 2025/37 made managed security services eligible for European certification, and EUMSS is the candidate scheme. A certificate could support the customer's due diligence and its assessment of your information security standards, but the financial entity remains responsible and still needs the Article 30 clauses, its audit rights and its register entry.
As of November 2026, EUMSS is a candidate scheme. The Commission has not adopted an implementing act establishing it, so no EUMSS certificate can be issued yet. ENISA ran a public consultation on a first draft from 24 July to 13 September 2026, and that draft starts with incident response services. Our founder is a member of the ENISA ad hoc working group on EUMSS; we do not predict adoption dates. Some steps pay off whatever the final text says, because bank questionnaires and the NIS2 Article 21 measures already ask for them: define the scope of each service you provide, keep evidence of how you handle incidents and of logging that shows who accessed which data and when, and keep records of your staff's competence and experience. Staff competence and access logging also match two of the security objectives that Article 51a of the Cybersecurity Act, inserted by Regulation (EU) 2025/37, sets for any such scheme (points (a) and (f)).
Under Regulation (EU) 2024/1689 (the AI Act), most AI used for security detection is unlikely to be high-risk. The relevant Annex III entry covers safety components in the management and operation of critical digital infrastructure, and recital 55 states that components intended to be used solely for cybersecurity purposes should not qualify as safety components. Classification still depends on each system's intended purpose, so each use case needs checking. The AI literacy obligation in Article 4 has applied since 2 February 2025; since Regulation (EU) 2026/1744 it requires providers and deployers to take measures to support the AI literacy of their staff, without guaranteeing a specific level. Banks' questions are more practical and follow their Article 28 due diligence and the Article 30 clauses: where the model runs and where their data is processed and stored, with advance notice of any change of location (Article 30(2)(b)), whether the model comes from a subcontractor, and how you control and notify model changes that could affect your ability to provide the service (Article 30(3)(b), for services supporting critical or important functions).
Bank due diligence questionnaires and the NIS2 Article 21 measures cover much of the same ground: risk analysis, incident handling, business continuity, supply chain security, secure development, access control and cryptography. Medium and large managed service and managed security service providers are themselves in NIS2 scope (Annex I). Building one control set with evidence behind each control lets you answer each customer, and your own NIS2 authority, from the same material.