---
title: "EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq"
source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq/items"
author: "Sorena AI"
description: "Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU DORA FAQ"
  - "Digital Operational Resilience Act"
  - "ICT incident reporting"
  - "ICT third-party contracts"
  - "TLPT"
  - "register of information"
  - "EU DORA"
  - "DORA FAQ"
  - "ICT risk management"
  - "major ICT incidents"
  - "ICT third-party risk"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence

Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.

*FAQ* *EU*

## EU DORA FAQ

Direct answers on DORA scope, proportionality, ICT risk management, ICT third-party contracts, register-of-information records, major ICT incident reporting, resilience testing, TLPT, and enforcement.

Use this page as a starting point for source-linked DORA triage; it avoids unofficial penalty caps, unsupported incident thresholds, and generic compliance checklists.

DORA is the EU Digital Operational Resilience Act for the financial sector. It sets uniform requirements for ICT risk management, major ICT incident reporting, digital operational resilience testing, ICT third-party risk, and oversight of critical ICT third-party service providers. This FAQ answers the questions teams usually need before assigning DORA work or validating evidence.

## Browse sub-FAQ modules

### [DORA ICT Third-Party Contracts FAQ](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md)

What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.

- 4 items

### [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md)

FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.

- 4 items

### [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)

FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.

- 6 items

### [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)

FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.

- 5 items

### [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md)

A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.

- 4 items

Browse all indexed questions: [/artifacts/eu/digital-operational-resilience-act/faq/items](/artifacts/eu/digital-operational-resilience-act/faq/items.md)

## All FAQ items

*Page 1 of 2. Showing 20 of 23 items.*

### [What must a DORA ICT third-party contract include?](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md#what-must-a-dora-ict-third-party-contract-include)

*Module: [DORA ICT Third-Party Contracts](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md)*

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.

- Do not treat a master services agreement as complete unless the service order, SLA, data-location terms, audit rights, incident-assistance obligations, termination rights, and exit terms are all documented in an accessible durable format.
- For critical or important functions, check whether the contract gives practical audit access and the right to take copies of relevant documentation where critical to provider operations.
- Map each required clause to the affected ICT service, supported function, provider legal entity, subcontracting condition, and register-of-information reference.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 30 sets the written contract requirements and the additional clauses for ICT services supporting critical or important functions.
- [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Specifies the policy content for contractual arrangements supporting critical or important functions, including lifecycle phases, due diligence, contractual clauses, monitoring, audit, and exit.

### [How should teams decide whether a contract supports a critical or important function?](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md#how-should-teams-decide-whether-a-contract-supports-a-critical-or-important-function)

*Module: [DORA ICT Third-Party Contracts](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md)*

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.

- Record the supported business function, not only the technology category.
- Assess operational, legal, ICT, reputational, data-protection, data-availability, provider-location, data-location, and concentration risks before contracting.
- Escalate contracts that are hard to substitute, concentrate several important services with one provider, or make recovery of data or services dependent on a complex supplier chain.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Defines critical or important functions and requires pre-contract assessment of whether ICT services support such functions.
- [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Requires a methodology for determining which ICT services support critical or important functions and requires pre-contract risk assessment and due diligence.

### [How do subcontracting terms affect DORA contract review?](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md#how-do-subcontracting-terms-affect-dora-contract-review)

*Module: [DORA ICT Third-Party Contracts](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md)*

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.

- List which critical or important ICT services or material parts are eligible for subcontracting.
- Require notice early enough for the financial entity to assess material subcontracting changes before they apply.
- Preserve equivalent access, inspection, and audit rights for the financial entity, competent authorities, and resolution authorities where subcontractors support critical or important functions.
- Treat intra-group subcontractors as subcontractors when they provide ICT services supporting critical or important functions or material parts of them.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 29 requires assessment of concentration and subcontracting risks for ICT services supporting critical or important functions.
- [Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Specifies what financial entities must determine and assess when ICT services supporting critical or important functions are subcontracted.

### [What register and evidence should a DORA contract review leave behind?](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md#what-register-and-evidence-should-a-dora-contract-review-leave-behind)

*Module: [DORA ICT Third-Party Contracts](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md)*

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.

- Keep the contract reference number, contract type, provider identifiers, signing entity, entities using the service, ICT service description, supported function identifier, critical-or-important-function assessment, and annual expense or estimated cost where required by the template.
- Keep the source evidence for due diligence: provider resources, information-security standards, business-continuity measures, audit reports or certifications used, location and data-location assessment, conflicts of interest, and concentration-risk assessment.
- Keep monitoring evidence: periodic reports, incident reports, service delivery reports, ICT security reports, business-continuity testing reports, KPI and KCI reviews, independent review or audit outputs, shortcomings, corrective measures, and closure evidence.
- Keep exit evidence: documented exit plan, periodic review and testing, transition schedule, alternative provider or in-house options, data-return plan, and contingency measures for service interruption, failed delivery, or unexpected termination.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 requires the register of information for ICT third-party contractual arrangements and requires documentation distinguishing critical or important functions.
- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Provides the standard register templates and data-quality requirements for contractual arrangements, providers, supply chains, functions, and critical-or-important-function assessments.
- [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Requires monitoring evidence, independent review, audit-plan coverage, documented assessments, and documented exit plans for contracts supporting critical or important functions.

### [What makes a DORA ICT-related incident major?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md#what-makes-a-dora-ict-related-incident-major)

*Module: [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md)*

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.

- Start with the DORA Article 18 criteria: clients, financial counterparts and transactions; reputational impact; duration and downtime; geographical spread; data losses; criticality of services; and economic impact.
- Confirm whether the affected ICT service, system, or financial service supports a critical or important function before applying the major-incident gate.
- Do not invent lower internal numeric triggers and present them as DORA thresholds. Internal severity triggers can escalate review, but the DORA major classification should map back to the regulatory criteria.
- If actual client, counterparty, transaction, duration, downtime, or loss data is unavailable at classification time, use estimates based on available data and update the report when better figures are available.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 18 sets the incident classification criteria and Article 19 establishes reporting of major ICT-related incidents.
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Specifies the major-incident classification rule, critical-service criterion, recurring incidents, and materiality thresholds.

### [Which materiality thresholds should the incident team test?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md#which-materiality-thresholds-should-the-incident-team-test)

*Module: [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md)*

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.

- Clients: more than 10% of all clients using the affected service, or more than 100,000 affected clients, meets the client threshold.
- Financial counterparts: more than 30% of financial counterparts carrying out activities related to the affected service meets the threshold.
- Transactions: more than 10% of the daily average number of transactions or more than 10% of the daily average value of transactions related to the affected service meets the threshold.
- Duration and downtime: incident duration longer than 24 hours, or service downtime longer than 2 hours for ICT services supporting critical or important functions, meets the threshold.
- Geographical spread: impact in two or more Member States meets the threshold.
- Data losses: adverse impact on business objectives or regulatory compliance from availability, authenticity, integrity, or confidentiality loss meets the threshold; successful malicious unauthorised access that may result in data loss is separately material.
- Economic impact: direct and indirect costs and losses exceeding, or likely to exceed, EUR 100,000 meet the threshold.

Sources for this answer:

- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Articles 1 to 9 define how to measure client, transaction, reputation, duration, geographical, data-loss, critical-service, and economic impact thresholds.

### [How do recurring incidents affect the threshold decision?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md#how-do-recurring-incidents-affect-the-threshold-decision)

*Module: [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md)*

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.

- Track apparent root cause, affected service, classification criteria, timestamps, and recurrence count for incidents closed as non-major.
- Run a monthly recurrence review before treating repeated low-impact incidents as permanently non-reportable.
- If repeated incidents collectively meet the major-incident test, preserve the dates and times of occurrence because the final report template asks for recurring-incident information.

Sources for this answer:

- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Article 8 sets the recurring-incident conditions and monthly assessment requirement.
- [Implementing Regulation (EU) 2025/302 on incident report templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - The report template includes final-report fields for recurring non-major incidents and date/time of recurring incidents.

### [What happens once the DORA major threshold is met?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md#what-happens-once-the-dora-major-threshold-is-met)

*Module: [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md)*

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.

- Initial notification evidence: incident reference code, detection date and time, classification date and time, incident description, classification criteria met, impacted Member States, discovery route, origin if available, business-continuity activation, and any reclassification.
- Intermediate report evidence: occurrence time, recovery time if applicable, how the classification criteria were fulfilled, incident type, threats and techniques, affected business processes and infrastructure, client financial-interest impact, other authority reporting, recovery actions, and indicators of compromise where applicable.
- Final report evidence: root cause, resolution summary, dates when the incident and root cause were resolved, direct and indirect costs and losses, recoveries, and recurring-incident information where applicable.
- Client communication is separate from competent-authority reporting: where a major ICT-related incident affects clients' financial interests, DORA requires informing affected clients without undue delay about the incident and mitigation measures.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 19 covers major ICT-related incident reporting, voluntary significant cyber-threat notification, and client information where financial interests are affected.
- [Delegated Regulation (EU) 2025/301 on incident reporting content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Specifies the initial notification, intermediate report, final report contents, and reporting time limits.
- [Implementing Regulation (EU) 2025/302 on incident report templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Provides the standard reporting fields and data glossary for major ICT-related incident reports.

### [What is the DORA register of information?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#what-is-the-dora-register-of-information)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Include contractual arrangements for ICT services, not only traditional outsourcing contracts.
- Record all direct ICT third-party providers and the ICT services they provide.
- Mark whether the service supports a critical or important function or a material part of one.
- Make the register available to the competent authority on request, either in full or in requested sections.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA), Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj?ref=sorena.io) - Article 28 requires financial entities to maintain and update the register and make it available to competent authorities.
- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Sets the standard templates and data structure for the DORA register of information.

### [Who maintains it, and what arrangements must be captured?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#who-maintains-it-and-what-arrangements-must-be-captured)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Use a unique and stable contractual arrangement reference number across the register templates.
- Capture standalone contracts, master or framework arrangements, and subsequent or associated arrangements such as order forms.
- Identify the entity signing the arrangement and the financial entity making use of the ICT service when those are different.
- For group registers, include the relevant financial entities and ICT intra-group service providers in the scope of consolidation.

Sources for this answer:

- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Explains entity, group, contract-reference, intra-group, and service-supply-chain template logic.
- [Regulation (EU) 2022/2554 (DORA), Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj?ref=sorena.io) - Keeps responsibility with the financial entity even when ICT services are provided by third parties.

### [Which fields matter most in the standard templates?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#which-fields-matter-most-in-the-standard-templates)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Provider identity: LEI or EUID for legal persons established in the Union, and LEI for legal persons not established in the Union.
- Contract details: arrangement type, annual expense or estimated cost, start and end dates, termination reason when relevant, governing law, service country, and notice periods where required.
- Service and data details: ICT service type, function identifier, storage and processing locations, data sensitivity, and level of reliance for critical or important functions.
- Assessment details: substitutability, reason for difficult substitution, date of last audit, exit plan, reintegration possibility, discontinuation impact, and identified alternatives.

Sources for this answer:

- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Provides the template list, keys, mandatory fields, closed lists, and data-format rules.

### [How should critical or important functions and subcontractors be handled?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#how-should-critical-or-important-functions-and-subcontractors-be-handled)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Document the methodology used to decide whether an ICT service supports a critical or important function.
- Map each critical or important function to the ICT services and providers that support it.
- For critical or important functions, capture the service supply chain with rank 1 for the direct ICT third-party provider and higher ranks for subcontractors.
- Keep subcontracting risk assessments separate from supplier assurances; reliance on provider assessments does not remove the financial entity's final responsibility.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA), Articles 28 to 30](https://eur-lex.europa.eu/eli/reg/2022/2554/oj?ref=sorena.io) - Requires pre-contract assessment, concentration-risk assessment, and additional contractual provisions for ICT services supporting critical or important functions.
- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Limits register subcontractor capture to subcontractors that effectively underpin ICT services supporting critical or important functions or material parts.
- [Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj?ref=sorena.io) - Specifies elements to assess when subcontracting ICT services supporting critical or important functions.

### [How is the register submitted or exported?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#how-is-the-register-submitted-or-exported)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Keep a reportable version of each template, not only dashboard views.
- Use ISO formats and closed-list values where the template requires them.
- Maintain evidence for the last update date, reporting date when applicable, and the competent authority to which reporting is made.
- When a competent authority asks for sections, export by template and key so contracts, providers, functions, services, and assessments still reconcile.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA), Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj?ref=sorena.io) - Sets the yearly reporting and competent-authority access requirements for the register.
- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Requires table-based templates, single-value data elements, and completion at entity, sub-consolidated, and consolidated level as applicable.

### [What evidence and data-quality checks should support the register?](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md#what-evidence-and-data-quality-checks-should-support-the-register)

*Module: [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md)*

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.

- Contract evidence: executed agreement, master agreement, order form, SLA, amendment, termination notice, and notice-period source.
- Provider evidence: LEI or EUID check, legal name, headquarters country, direct provider status, ultimate parent, and subcontractor list where required.
- Function evidence: business owner approval, function identifier, critical or important function assessment, reliance level, and impact of discontinuing the service.
- Assurance evidence: due diligence, information-security standard review, audit date, substitutability analysis, exit plan, alternative-provider assessment, and data-location validation.
- Quality evidence: reconciliation reports for duplicate contract references, missing mandatory fields, inconsistent identifiers, stale provider data, and unresolved template errors.

Sources for this answer:

- [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj?ref=sorena.io) - Requires regular review, prompt correction of errors, and data-quality principles for the register templates.
- [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj?ref=sorena.io) - Connects contract governance to risk assessment, due diligence, documentation, monitoring, record-keeping, exit strategies, and critical or important functions.

### [Who decides whether a financial entity must perform DORA TLPT?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md#who-decides-whether-a-financial-entity-must-perform-dora-tlpt)

*Module: [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)*

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.

- Do not treat TLPT selection as a generic company-size threshold; the official criteria are financial-sector and ICT-risk specific.
- Track the authority that made or communicated the TLPT selection decision, especially where the TLPT authority and the competent authority are different.
- If the entity is part of a group that shares ICT systems or uses the same ICT intra-group service provider, capture whether authorities considered individual, joint, or pooled testing.
- If an entity believes TLPT is not justified despite meeting a listed category or quantitative criterion, record the authority assessment rather than relying on an internal exemption.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA), Article 26](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the Article 26 rule that identified financial entities perform TLPT at least every 3 years and that competent authorities identify entities using impact, financial-stability, ICT-risk, maturity, and technology criteria.
- [Commission Delegated Regulation (EU) 2025/1190 on DORA TLPT](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Supports the TLPT authority role and the detailed criteria for identifying financial entities required to perform TLPT.

### [Which financial entities may be identified for DORA TLPT?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md#which-financial-entities-may-be-identified-for-dora-tlpt)

*Module: [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)*

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.

- Entity categories expressly addressed include credit institutions, payment institutions, electronic money institutions, central securities depositories, central counterparties, trading venues, and insurance or reinsurance undertakings.
- The RTS also allows TLPT authorities to assess other types of financial entities where qualitative factors make TLPT appropriate.
- Meeting an entity-category or quantitative criterion is not the end of the analysis: the TLPT authority can assess whether impact, financial-stability concerns, or ICT risk profile justify TLPT.
- Microenterprises and entities under the simplified ICT risk management framework should not be treated as TLPT candidates unless a grounded authority position says otherwise.

Sources for this answer:

- [Commission Delegated Regulation (EU) 2025/1190 on DORA TLPT](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Supports the impact, systemic-character, ICT-risk, entity-category, group/shared-system, and qualitative assessment criteria used for TLPT identification.
- [Regulation (EU) 2022/2554 (DORA), Recital 43 and Article 26](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports that only identified financial entities perform advanced TLPT and that microenterprises and simplified-framework entities are not the target of TLPT selection.

### [What happens after a financial entity is selected for TLPT?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md#what-happens-after-a-financial-entity-is-selected-for-tlpt)

*Module: [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)*

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.

- Appoint a control team lead responsible for day-to-day TLPT management and control-team decisions.
- Keep knowledge of planned or ongoing TLPT limited to the control team, management body, testers, threat intelligence provider, and TLPT authority on a need-to-know basis.
- Scope critical or important functions by considering their criticality, day-to-day importance, exchangeability, interconnectedness, geographic location, sector dependence, and available threat intelligence.
- Do not begin the testing phase until provider procurement or assignment is complete, the TLPT risk assessment has been consulted on with test managers, and authority validation points have been handled.

Sources for this answer:

- [Commission Delegated Regulation (EU) 2025/1190 on DORA TLPT](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Supports the post-selection preparation sequence, including 3-month initiation information, 6-month scope submission, control-team setup, risk assessment, provider evidence, and TLPT authority approval.
- [Regulation (EU) 2022/2554 (DORA), Article 26](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the requirement that TLPT covers several or all critical or important functions and is performed on live production systems supporting those functions.

### [How should scope, providers, and authority validation be documented?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md#how-should-scope-providers-and-authority-validation-be-documented)

*Module: [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)*

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.

- Keep the function inventory, inclusion and exclusion rationale, supporting ICT systems, outsourced-system facts, provider names, jurisdictions, and preliminary flags.
- Keep provider CVs, appropriate certifications, professional indemnity insurance evidence, references, conflict checks, separation of threat-intelligence and tester staff where relevant, and restoration-procedure commitments.
- If internal testers are proposed, keep the authority approval, conflict-of-interest analysis, resource evidence, and proof that the threat intelligence provider is external.
- If pooled or joint TLPT is considered, keep the authority feasibility assessment, designated financial entity, lead TLPT authority, participating entities, shared ICT provider facts, and each entity's own risk assessment.

Sources for this answer:

- [Commission Delegated Regulation (EU) 2025/1190 on DORA TLPT](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Supports scope specification content, provider-selection evidence, internal-tester conditions, pooled and joint TLPT coordination, and TLPT authority validation.
- [Regulation (EU) 2022/2554 (DORA), Articles 26 and 27](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the tester requirements, internal-tester approval conditions, pooled testing rule, ICT third-party participation, and full responsibility of the financial entity.

### [What evidence closes a DORA TLPT selection and testing cycle?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md#what-evidence-closes-a-dora-tlpt-selection-and-testing-cycle)

*Module: [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md)*

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.

- Keep the selected-entity rationale, authority notification, authority validations, and any decision on individual, pooled, or joint TLPT.
- Keep the targeted threat intelligence report, selected scenarios, red team test plan, weekly progress records, deviations, leg-ups, suspensions, and risk-management decisions.
- Keep the red team report, blue team report, replay and purple-teaming outputs, test summary report, and remediation plan with root causes, priorities, owners, expected completion, and risks of non-implementation.
- Keep the attestation showing dates, functions in scope, participating entities and providers, internal-tester use where relevant, active red team duration, involved TLPT authorities, and documents examined by the TLPT authority.

Sources for this answer:

- [Commission Delegated Regulation (EU) 2025/1190 on DORA TLPT](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Supports the 12-week minimum active red-team phase, closure reports, test summary report, remediation-plan content, and attestation details.
- [Regulation (EU) 2022/2554 (DORA), Article 26](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the Article 26 attestation, mutual-recognition purpose, remediation-plan submission, and continuing responsibility of the financial entity.

### [What does proportionality mean under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md#what-does-proportionality-mean-under-eu-dora)

*Module: [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md)*

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.

- Start with DORA scope: confirm the entity is a financial entity or ICT third-party service provider covered by Article 2, and check whether any Article 2 exclusion applies.
- For an in-scope financial entity, record the proportionality factors: size, overall ICT risk profile, nature of services, scale of operations, complexity, critical or important functions, outsourced ICT services, and exposure to disruption.
- Map what is being scaled: governance detail, control depth, documentation, testing frequency, remediation sequencing, supplier monitoring, or evidence retained for supervisory review.
- Do not treat proportionality as a waiver of the core obligation to manage ICT risk, handle incidents, report major ICT-related incidents, maintain required third-party records, or meet TLPT requirements when identified by the competent authority.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 4 defines DORA proportionality and Article 2 defines covered financial entities and exclusions.

## FAQ Pagination

- Canonical index (page 1): [/artifacts/eu/digital-operational-resilience-act/faq/items](/artifacts/eu/digital-operational-resilience-act/faq/items.md)
- Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL.
- Current page: 1 of 2

Pages: [1](/artifacts/eu/digital-operational-resilience-act/faq/items.md) | [2](/artifacts/eu/digital-operational-resilience-act/faq/items/page/2.md)

[Next page](/artifacts/eu/digital-operational-resilience-act/faq/items/page/2.md)

*Recommended next step*

*Placement: before sources*

## Use the FAQ to check your DORA workstream

Sorena can help convert DORA scope, incident, ICT contract, register, testing, TLPT, and enforcement questions into cited controls, record requests, and remediation tasks.

- [Open Research Copilot for DORA](/solutions/research-copilot.md): Ask source-linked questions about DORA scope, ICT incidents, contracts, testing, and evidence using the cited sources on this page.
- [Talk through DORA implementation](/contact.md): Review your DORA scope, incident reporting, ICT third-party, register, testing, and evidence gaps with Sorena.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq/items