DORA stands for Digital Operational Resilience Act. It regulates how financial entities and their ICT suppliers manage technology risk, respond to incidents, test resilience, and oversee third-party dependencies. It is not a cybersecurity certification framework — it is a binding EU regulation with direct enforcement consequences for financial entities and contractual consequences for the ICT companies that supply them.

17 January 2025. All obligations applied from that date — there was no phased implementation for financial entities. ICT third-party providers became subject to their customers’ contractual oversight obligations from the same date.

No. NIS2 is a broad cybersecurity directive applying across critical sectors. DORA is lex specialis for the financial sector — where both apply to the same obligation, DORA takes precedence. A financial entity that satisfies DORA’s ICT risk management and incident reporting requirements satisfies the equivalent NIS2 obligations. For ICT suppliers to financial entities, DORA is the primary framework to address.

Any undertaking providing digital and data services to a financial entity on an ongoing basis — including cloud computing, software, data analytics, data centres, and any ICT infrastructure service. The definition is broad. Most SaaS, API, and platform businesses supplying EU banks, insurers, or investment firms qualify regardless of whether they consider themselves technology companies or not.

A function whose disruption would materially impair a financial entity’s financial performance, operational continuity, or regulatory compliance. Financial entities classify their ICT dependencies against this threshold — suppliers supporting critical or important functions face heavier contractual obligations including more granular audit rights, sub-outsourcing controls, and business continuity requirements. The classification is the financial entity’s determination, not the supplier’s, but it has direct consequences for what your contract must contain.

A mandatory record maintained by every financial entity listing all contractual arrangements with ICT third-party providers. The European Supervisory Authorities have prescribed the format through Implementing Technical Standards — specific fields including provider identification, LEI, service classification, contract details, and subcontracting chain. Financial entities submit their Register of Information to regulators on request. ICT suppliers are regularly asked to provide the provider-side data fields their customers need to populate it.

A Legal Entity Identifier is a 20-character alphanumeric code that uniquely identifies a legal entity in financial transactions. The DORA Register of Information ITS requires LEIs for ICT third-party providers where one exists.

If your company does not have an LEI and your customers are asking for one to populate their register, you will need to obtain one — they are issued by accredited Local Operating Units and typically cost €65–€130 per year to register and maintain.

ICT third-party providers must disclose the chain of subcontractors behind their service to their financial entity customers, particularly where a subcontractor supports a critical or important function. Material changes to the subcontracting chain — adding, replacing, or removing a material subcontractor — must be notified before the change takes effect, giving the customer the right to object.

Most ICT suppliers have not mapped their subcontracting chain at the level of detail DORA requires and have not established a change notification process.

DORA sets reporting timelines for financial entities — four hours for initial notification of a major incident, 72 hours for an intermediate report, one month for a final report. ICT suppliers must notify their financial entity customers of incidents affecting their service within timeframes that allow the customer to meet these regulatory deadlines. The specific notification timelines must be written into the contract under Article 30. A supplier whose incident notification process cannot support a customer’s four-hour regulatory clock creates a contractual and regulatory problem for that customer.

A structured, intelligence-led security test that significant financial entities must conduct every three years. Where an ICT supplier’s systems are in scope — because they support a critical or important function — the supplier must participate. Participation requires controlled system access, multi-tenant safeguards where the same infrastructure serves multiple financial entity customers, and documentation of the testing process. Pooled testing arrangements — where multiple financial entities test the same supplier together — are permitted and increasingly common for widely-used platforms.

A formal designation made by the European Supervisory Authorities — EBA, ESMA, and EIOPA — based on systemic importance to the EU financial sector. Designated providers face direct supervisory oversight including information requests, on-site inspections, and binding recommendations. As of the first official list, only nineteen providers were designated, all hyperscale cloud and core-platform businesses. For most ICT suppliers, the relevant output of a designation assessment is a documented conclusion of non-criticality — which is itself a compliance record worth maintaining.

Where a third-country ICT provider is designated critical by the ESAs, it must establish a subsidiary inside the EU within twelve months of designation. This requirement applies only to designated critical providers — not to ICT suppliers generally. Third-country providers with a growing EU financial sector customer base should assess their designation risk annually, as systemic importance can increase as EU adoption grows.

Article 30 mandates specific provisions in all ICT third-party contracts with financial entities — service description, service level requirements, data location, security standards, incident notification timelines, audit and access rights, and exit provisions. A heavier set of provisions applies where the service supports a critical or important function. Pre-2025 contracts that do not include these provisions are non-compliant. Financial entities are required to remediate non-compliant contracts and are doing so across their supplier base.

In principle, yes — the Article 30 mandatory provisions are standardised. In practice, different customers apply different interpretations of what constitutes a critical or important function, have different audit right requirements, and may insist on customer-specific addenda. A baseline-compliant contract that includes all mandatory provisions reduces negotiation friction and gives customers less to push back on, but it will not eliminate customer-specific requests entirely.

AI systems used by financial entities for credit scoring, fraud detection, trading, risk assessment, or customer-facing functions are ICT services within DORA’s scope. The AI supplier is an ICT third-party provider subject to the same register, contract, subcontracting, incident notification, and penetration testing obligations as any other technology supplier. Where the AI system also falls under EU AI Act high-risk obligations, both frameworks apply simultaneously — DORA governs the operational resilience of the service, the EU AI Act governs the system’s classification, documentation, and conformity assessment.