Search every question across sub-FAQs

Every ICT services contract must clearly allocate rights and obligations in writing and include the service level agreements in one paper or downloadable, durable, and accessible document. Article 30 also requires a complete service and function description; subcontracting conditions where relevant; service, processing, and storage locations with advance notice of changes; data-protection terms; data access, recovery, and return; incident assistance at no extra cost or at a cost set in advance; cooperation with competent and resolution authorities; termination rights and notice periods; and conditions for relevant provider participation in security-awareness and resilience training.

Where the ICT service supports a critical or important function, DORA adds a higher bar: full service level descriptions with quantitative and qualitative performance targets, provider reporting and notice obligations, business-contingency and ICT-security requirements, participation and cooperation in relevant resilience testing, ongoing monitoring rights, unrestricted access, inspection and audit rights for the financial entity or appointed third party and competent authority, and exit strategies with an adequate transition period.

Before signing, DORA requires the financial entity to assess whether the ICT service supports a critical or important function. DORA defines a critical or important function as one whose disruption would materially impair financial performance, soundness, continuity of services and activities, or continuing compliance with authorisation conditions or other financial-services-law obligations.

The assessment should be made before contract signature and reviewed when the service, supported function, data flow, provider, location, subcontracting chain, or business dependence changes. The 2024/1773 RTS also requires the contract policy to establish or refer to the methodology for determining which ICT services support critical or important functions and when that assessment is conducted and reviewed.

If an ICT service supporting a critical or important function may be subcontracted, the contract must say whether subcontracting is permitted and under what conditions. DORA also requires the financial entity to weigh the risks of subcontracting, including long or complex chains, third-country subcontractors, concentration risk, data protection, and whether the chain affects the entity's ability to monitor the contracted function or the authority's ability to supervise it.

The 2025/532 subcontracting RTS makes this more concrete. Before entering the contract, the financial entity must decide whether the provider may subcontract a critical or important ICT service or material part of it. The arrangement must identify eligible services and conditions, require the provider to identify relevant subcontractors, preserve access and inspection rights through the chain, address continuity and relevant location information, and require notice of material changes early enough for the financial entity to assess them before implementation.

The contract file should produce evidence for the DORA register of information as well as for legal, procurement, risk, security, outsourcing, and audit review. DORA requires a register for all contractual arrangements on the use of ICT services provided by ICT third-party service providers and requires it to distinguish arrangements that support critical or important functions from those that do not.

The 2024/2956 ITS turns that into structured register data. It requires templates for contractual arrangements, signing entities, providers, entities using ICT services, direct providers and subcontractors, ICT service supply chains, function identifiers, and assessments of ICT services supporting critical or important functions or material parts. The register information must be accurate, complete, consistent, integral, uniform, and valid.

The first gate is critical-service impact. Delegated Regulation (EU) 2024/1772 treats an incident as major only where it affects critical services and either a successful malicious unauthorised access threshold linked to possible data loss is met, or at least two other materiality thresholds are met.

Critical-service impact is not limited to total outages. The RTS treats an incident as affecting critical services if it affects ICT services or systems supporting critical or important functions, affects financial services provided by the financial entity that require authorisation, registration, or are supervised by competent authorities, or involves successful malicious unauthorised access to the financial entity's network and information systems.

Delegated Regulation (EU) 2024/1772 gives the main measurable thresholds. The incident team should record each criterion as met, not met, unknown, or estimated, and keep the data source for each answer.

Several criteria are not simple numeric tests. Reputational impact is met if the incident is reflected in the media, causes repetitive complaints from different clients or financial counterparts, leaves the entity unable or likely unable to meet regulatory requirements, or causes or is likely to cause the entity to lose clients or financial counterparts with a material impact on its business. Data-loss impact is assessed against availability, authenticity, integrity, and confidentiality.

Recurring non-major incidents can become one major incident collectively. Delegated Regulation (EU) 2024/1772 applies this where the incidents occur at least twice within 6 months, have the same apparent root cause, and collectively satisfy the major-incident test.

Financial entities must assess recurring incidents monthly. The recurring-incident rule does not apply to microenterprises and to the financial entities listed in DORA Article 16(1), based on the RTS text.

Once the incident is classified as major, the reporting clock starts. Delegated Regulation (EU) 2025/301 requires the initial notification as early as possible, within 4 hours from major classification, and no later than 24 hours from awareness of the ICT-related incident. If classification as major happens later than 24 hours after awareness, the initial notification is due within 4 hours from that later classification.

The same RTS requires an intermediate report within 72 hours from the initial notification even if the incident status has not changed, an updated intermediate report without undue delay and whenever regular activities recover, and a final report no later than one month after the intermediate report or latest updated intermediate report. If a deadline cannot be met, the financial entity must inform the competent authority without undue delay, explain why, and do so no later than the missed deadline.

The DORA register of information is the financial entity's maintained and updated record of all contractual arrangements on the use of ICT services provided by ICT third-party service providers. DORA Article 28 requires the register at entity level and, where relevant, at sub-consolidated and consolidated levels.

The register must distinguish arrangements that support critical or important functions from arrangements that do not. That classification determines which additional assessment fields and supply-chain records apply, while DORA Articles 28 to 30 set the related contract, subcontracting, audit, and exit obligations.

The financial entity is responsible for maintaining and updating the register. In a group, the register can be maintained at entity, sub-consolidated, and consolidated levels, but the information still needs to let each financial entity meet its own DORA obligation.

The register covers all contractual arrangements for ICT services from direct ICT third-party service providers. For groups, it must also reflect intra-group ICT service arrangements and reconcile the intra-group contract with contracts between the ICT intra-group service provider and external providers in the same service chain. The ITS requires at least the first extra-group subcontractor in that chain even when the ICT service does not support a critical or important function.

Implementing Regulation (EU) 2024/2956 organizes the register into linked templates rather than one flat spreadsheet. The important design choice is to use the same keys consistently: contract reference number, entity and provider identifiers, function identifier, and type of ICT service.

At minimum, teams should make sure their source systems can populate the templates for the maintaining entity, in-scope entities and branches, contractual arrangements, signing entities, ICT third-party providers, ICT service supply chains, functions, assessments, and internal terminology.

Critical or important function status should be assessed before entering into an ICT service arrangement and revisited when a service, function, provider, data location, or subcontracting chain changes. DORA treats the criticality or importance of the supported function as central to ICT third-party risk.

For subcontractors, the register does not require every remote supplier in every chain. The 2024/2956 templates require subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them, including subcontractors whose disruption would impair the security or continuity of the service. A separate group rule requires at least the first external subcontractor used by an ICT intra-group service provider, even when the service is not critical or important.

DORA requires financial entities to report at least yearly to competent authorities on new ICT-service arrangements, provider categories, contract types, ICT services, and functions being provided. It also requires them to make the full register, or requested sections, available to the competent authority on request.

The implementing regulation is explicit that the register is maintained through standard templates with defined columns, rows, single-value data elements, identifiers, and closed lists. The practical export should therefore preserve the template structure and keys rather than turning the register into a narrative report.

The register should be backed by evidence that each field can be traced to a contract, provider record, business-function owner, risk assessment, audit record, exit plan, or source system. Implementing Regulation (EU) 2024/2956 requires six data-quality principles: accuracy, completeness, consistency, integrity, uniformity, and validity. Financial entities must regularly review the register and promptly correct errors and discrepancies.

The evidence must support day-to-day maintenance. Contract owners, business-service owners, ICT risk, procurement, legal, and group reporting teams should use the same identifiers and reflect changes in services, functions, providers, subcontractors, data locations, or criticality in the templates.

Identified financial entities must carry out TLPT at least every 3 years. A competent authority may reduce or increase that frequency where the entity's risk profile and operational circumstances require it. Article 16 entities and microenterprises are excluded from TLPT.

Commission Delegated Regulation (EU) 2025/1190 refines that selection process. It uses the term TLPT authority for the public authority, delegated national financial-sector authority, or competent authority responsible for TLPT-related tasks. That TLPT authority assesses whether a financial entity is required to perform TLPT, participates in every phase of the test, and validates key documents and decisions.