Search every question across sub-FAQs

Every ICT services contract should clearly allocate rights and obligations in writing, include service level agreements, describe the ICT services and functions being provided, identify service and data-processing locations, protect availability, authenticity, integrity and confidentiality of data, and cover data access, recovery and return if the provider fails, is resolved, discontinues operations, or the contract ends.

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 should require provider identification of relevant subcontractors, notice of material changes, same access and inspection rights through the subcontracting chain, continuity obligations, location and data-location information where relevant, and termination rights where impermissible or unapproved material subcontracting changes occur.

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. It includes ICT services or systems supporting critical or important functions, authorised or supervised financial services, and 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 can be met through media coverage, repeated complaints, inability or likely inability to meet regulatory requirements, or likely material client or counterparty loss. 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, updated intermediate reporting without undue delay when 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 and explain why before the relevant 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 distinction matters because it drives extra contract, assessment, subcontracting, exit, audit, and reporting expectations.

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 also needs to reflect intra-group ICT service arrangements and the link between intra-group contracts and external ICT third-party provider contracts where they sit in the same ICT service supply chain.

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.

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 the template information to be accurate and consistent, regularly reviewed, and promptly corrected when errors or discrepancies are found.

Evidence should be operational rather than decorative. A strong register package shows that contract owners, business-service owners, ICT risk, procurement, legal, and group reporting teams are using the same identifiers and that changes in services, functions, providers, subcontractors, data locations, or criticality are reflected in the templates.

The authority decision is central. DORA says financial entities identified under Article 26 must carry out TLPT at least every 3 years, and competent authorities identify those entities using impact, financial-stability, ICT-risk, maturity, and technology-feature criteria.

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.

Delegated Regulation 2025/1190 starts from the financial entity's impact, systemic character, and ICT risk profile. It points the TLPT authority to impact-related factors such as size, cross-border services, interconnectedness, criticality, substitutability, business-model complexity, and whether the entity belongs to a systemic group sharing ICT systems.

It also points to ICT-risk factors such as the entity's threat landscape, dependence of critical or important functions on ICT, ICT architecture complexity, use of ICT third-party or intra-group providers, supervisory review outcomes, business-continuity maturity, response-and-recovery maturity, and real-time monitoring, detection, analysis, and response capability.

Selection triggers a supervised testing process, not an immediate red-team exercise. After notification from the TLPT authority, the financial entity must initiate TLPT and submit initiation information within 3 months. That information includes a project charter, control team lead contact details, intended use of internal or external testers, communication channels, and a code name.

The financial entity must then submit a scope specification document within 6 months of the authority notification. The management body approves the scope specification document, and the TLPT authority approves it if it is complete and supports an appropriate and effective TLPT.

The scope record should explain why each critical or important function and supporting ICT system is included or excluded. Annex II to Delegated Regulation 2025/1190 requires the scope specification to list all critical or important functions identified by the financial entity and, for included functions, the relevant ICT systems, outsourcing status, ICT third-party provider, jurisdictions, and preliminary flags.

Provider selection also needs evidence. The control team must assess testers and threat intelligence providers against DORA Article 27 and the RTS requirements before contracting, provide evidence to test managers, and not proceed where the TLPT authority concludes that the selected providers or testers do not comply with the applicable requirements.

A selected entity should preserve both selection evidence and testing evidence. Selection evidence explains why the entity was identified, who the authority contact was, what scope was approved, and whether the test was individual, joint, or pooled. Testing evidence shows that the authority-supervised process was completed and that remediation is owned.

The active red team testing phase must last at least 12 weeks. After testing, the RTS requires red team and blue team reports, replay and purple teaming activities, a test summary report, remediation plans, and an attestation. The attestation is for mutual recognition and does not remove the financial entity's responsibility for the test impact or remediation.

DORA Article 4 says financial entities must implement ICT risk management rules proportionately, taking into account their size and overall risk profile and the nature, scale, and complexity of their services, activities, and operations. The same proportionality lens also applies to ICT-related incident management, digital operational resilience testing, and ICT third-party risk management where the relevant chapters provide for it.

That means a smaller, lower-complexity entity can justify simpler governance, fewer layers of documentation, narrower testing depth, or less complex supplier oversight than a large systemic entity. The justification must still be tied to real ICT risk facts, not to a preference for lighter compliance.