DORA in 2026: duties, incidents, TLPT and ICT providers

The legal status of DORA as at 24 August 2026

DORA entered into force on 16 January 2023, but most of its provisions began to apply on 17 January 2025. That was not a deadline for starting an implementation project; it was the day from which entities within scope were expected to be discharging their obligations. ^[1]

The base regulation is supplemented by level-two acts. The most important cover the ICT risk management framework, incident classification, the content and deadlines of reports, the policy on the use of ICT services, the register of information, subcontracting and TLPT. Assessing compliance against the text of DORA alone is therefore incomplete.

Who DORA covers

Article 2(1) lists 20 categories of financial entity. They include credit, payment and electronic money institutions, investment firms, crypto-asset service providers within MiCA, financial market infrastructure, fund managers, insurance undertakings and intermediaries, institutions for occupational retirement provision, credit rating agencies, crowdfunding service providers and securitisation repositories. ^[1]

Scope must not be determined from the industry alone or from the colloquial label "fintech". The regulatory status of the specific entity has to be checked, together with the exclusions in Article 2(3). The proportionality principle adjusts how obligations are discharged to size, risk profile and complexity, but it does not create a general exemption for every small organisation.

ICT providers

An ordinary ICT provider does not become a "DORA financial entity" merely by signing a contract. Its obligations arise primarily from the contract with the financial entity. Providers designated by the European Supervisory Authorities as critical ICT third-party service providers (CTPPs) are in a different position: they fall under an EU framework of direct oversight.

ICT risk management and the responsibility of the management body

The management body bears ultimate responsibility for ICT risk management. It is to approve and oversee the governance framework, the roles, the resilience strategy, continuity and recovery plans, the budget and the policy on the use of ICT provider services. Its members should maintain sufficient knowledge to understand and assess that risk. ^[1]

The framework in Articles 5-16 covers six connected capabilities:

• identification of business functions, information and ICT assets and dependencies;
• protection and prevention, including access control, configuration, change and data security;
• detection of anomalies and incidents;
• response and recovery with defined objectives and procedures;
• learning from incidents and tests;
• communication, internal and external.

Delegated Regulation (EU) 2024/1774 expands the requirements on policies, asset management, cryptography, ICT operations, network security, change, continuity and reporting. It also details the simplified framework foreseen in Article 16 of DORA for defined categories of entity - not for any firm that considers itself small. ^[3]

ICT incidents: classification and reporting deadlines

An entity must record ICT-related incidents, manage them under a documented process and classify them using the criteria in Article 18 of DORA. The materiality thresholds are set by Delegated Regulation (EU) 2024/1772. The assessment covers clients and counterparties, duration and downtime, geographical spread, loss of data availability, authenticity, integrity or confidentiality, the criticality of the services affected and the economic impact. ^[4]

Once an incident is classified as major, three-stage reporting applies. Delegated Regulation (EU) 2025/301 sets the content and the deadlines; Implementing Regulation (EU) 2025/302 sets the forms and procedures. ^{[5] [6]}

In Poland, reports of major ICT incidents and notifications of significant cyber threats are filed through the SOID system provided by the KNF (the Polish Financial Supervision Authority). The KNF also publishes a fallback procedure for when the system is unavailable; a report submitted through the alternative channel must be registered in the system once service is restored. Access details and instructions should be verified directly on the KNF website before an incident occurs. ^[15]

Notifying a significant cyber threat is voluntary. Where a major incident affects clients' financial interests, Article 19(3) requires them to be informed without undue delay about the incident and the measures taken to mitigate it. A single incident can simultaneously trigger obligations under the GDPR or other legislation; a DORA report does not automatically substitute for other notifications.

Resilience testing and TLPT

The testing programme is to be risk-based and cover appropriate techniques: from vulnerability assessments, scans and configuration reviews through to scenario-based, continuity, performance, end-to-end and penetration testing. For systems and applications supporting critical or important functions, DORA provides for regular testing, and the scope should follow change and risk.

TLPT does not automatically apply to every entity

Advanced threat-led penetration testing (TLPT) is carried out by entities identified by the competent authority under the criteria in DORA and Delegated Regulation (EU) 2025/1190. The baseline frequency is at least once every three years, but the authority may reduce or increase it depending on the risk profile and operational circumstances. Microenterprises and entities applying the framework in Article 16(1) are excluded from this obligation. ^[7]

TLPT covers critical or important functions and production systems, including material dependencies on providers. The process comprises scoping, preparing the threat intelligence, controlled activity by the testing team, test closure and a remediation plan. An ordinary application penetration test does not become TLPT simply because it uses attack scenarios.

ICT providers, contracts and the register of information

Using an external service does not transfer regulatory responsibility. The financial entity must manage the risk across the whole contract lifecycle: from classifying the function and due diligence, through negotiation, monitoring and audit, to termination and an exit plan.

The register covers every ICT services contract

Article 28(3) requires a register of information on all contractual arrangements for the use of ICT services to be maintained and kept up to date. Contracts supporting critical or important functions must be clearly distinguished. The standard templates and taxonomies are set by Implementing Regulation (EU) 2024/2956. ^[8]

The contract must reflect the risk

Article 30 sets out the elements of contracts, including a description of the services and locations, data protection, incident support, obligations after the contract ends and cooperation with authorities. For services supporting critical or important functions, further requirements apply on service levels, continuity plans, participation in testing, access rights, inspection and audit, and exit strategies. Delegated Regulation (EU) 2024/1773 expands the content of the policy governing those contracts. ^[9]

Subcontractors

Delegated Regulation (EU) 2025/532 requires assessment of the subcontracting chain supporting critical or important functions. The contract should set out the conditions for subcontracting, notification of material changes, control rights and grounds for termination. Relying solely on an assessment carried out by the prime provider does not remove the financial entity's responsibility. ^[10]

CTPPs: direct oversight of critical providers

The European Supervisory Authorities - EBA, EIOPA and ESMA - published the first list of 19 critical ICT third-party service providers on 18 November 2025. It included entities from the Accenture, AWS, Google Cloud, IBM, Microsoft, Oracle and SAP groups, along with telecommunications infrastructure and data centre operators. The list is to be updated at least once a year. ^[11]

A lead overseer is designated for each CTPP. It assesses risk management, may conduct inspections and may issue recommendations. Designation as a CTPP is not a security certificate and does not release the financial entity from due diligence, concentration monitoring or preparing an exit strategy. ^[12]

Where a CTPP fails to cooperate with the exercise of oversight powers, the lead overseer may impose a periodic penalty payment of 1% of the provider's average daily worldwide turnover in the preceding business year for each day of infringement, for up to six months. This is not a general penalty tariff for financial entities. ^[1]

Voluntary information sharing

Article 45 allows financial entities to exchange cyber threat information and intelligence within trusted communities, provided the aim is to enhance resilience and the arrangements protect confidentiality, personal data and business secrets. This is an option, not an obligation to hand over entire log sets. The organisation should establish the legal basis, the data classification, minimisation and onward sharing rules in advance.

DORA, NIS2, the Polish Cybersecurity Act and the GDPR

DORA and NIS2

The NIS2 directive treats DORA as a sector-specific Union act of at least equivalent effect as regards ICT risk management and the reporting of major incidents by the financial entities it covers. That does not mean every legal question concerning a financial organisation is governed by DORA alone. The personal and material scope and the national provisions must be compared. ^[13]

DORA and the Polish Cybersecurity Act

The 2025 act inserted Article 16a into the Polish Cybersecurity Act, limiting duplication of certain obligations of operators of essential services in banking and financial market infrastructure within the area covered by DORA. The 2026 amendment transposing NIS2 does not change the principle that classification and obligations must be assessed against the current text of both regimes.

DORA and the GDPR

DORA protects operational resilience and covers ICT incidents; the GDPR governs the processing of personal data and breaches of its protection. These are different legal tests. An incident may require notification under both regimes, one of them, or neither - depending on the DORA classification and on the risk to the rights and freedoms of individuals. ^[14]

Organising the implementation and the evidence

1. Confirm the scope. Establish the regulatory status of entities and branches, the exclusions and the competent authorities.
2. Identify the functions. Determine critical or important functions, processes, owners and disruption tolerance.
3. Map the dependencies. Connect functions to assets, data, applications, locations and ICT providers.
4. Assess the risk framework. Verify management body decisions, policies, roles, resources, indicators and reporting.
5. Rehearse incidents. Practise classification, the two clocks on the initial notification, the forms, communication and the other reporting regimes.
6. Put the register in order. Agree identifiers, taxonomies, contract completeness and data quality control.
7. Fix the contracts. Prioritise services supporting critical or important functions and the subcontracting chains.
8. Build the testing programme. Tie tests to risk, change and functions; prepare TLPT only where the entity is actually subject to that duty.
9. Retain the evidence. A resolution, a report, a log, a test result and an accepted exception should each state the scope, the date, the owner and the follow-up action.

There is no universal cost or timeline for a DORA implementation. Both depend on the licensing model, the architecture, the state of the contracts, the number of providers, the quality of the inventory and the maturity of the incident process. An off-the-shelf policy without execution and evidence does not close the gap.

The most common mistakes

• confining the programme to the security function without business owners and the management body;
• treating every contract as outsourcing or, conversely, overlooking ICT services bought as part of a larger service;
• keeping the register only for providers of critical or important functions;
• lacking a round-the-clock capability to classify and approve an incident report;
• treating an ordinary penetration test as TLPT;
• accepting a provider's report as a substitute for the entity's own risk assessment;
• having no realistic exit strategy and no service restoration tests;
• assuming that ISO/IEC 27001 compliance automatically demonstrates DORA compliance.

Frequently asked questions

When did DORA start to apply?

From 17 January 2025. The Polish act aligning supervisory powers and national sanctions entered into force on 7 August 2025.

Does DORA apply to every company providing financial services?

No. The scope is set by a closed list of categories in Article 2, together with the exclusions. What decides is the regulatory status of the specific entity.

Does an ICT provider have to apply the whole of DORA itself?

Usually not as a financial entity. It does have to meet the client's contractual requirements. Providers designated as CTPPs are additionally subject to direct EU oversight.

How quickly must a major incident be reported?

As a rule the initial notification must be submitted no later than four hours after classification as major and no later than 24 hours after becoming aware of the incident. If classification only happens after 24 hours, the report is due within four hours of classification. An intermediate report follows within 72 hours and a final report within one month.

Must every entity run TLPT every three years?

No. The duty applies to entities identified by the competent authority using the DORA criteria and RTS 2025/1190. Three years is the baseline frequency, which the authority may change.

Does the register cover only critical providers?

No. It covers all contractual arrangements for ICT services, with clear identification of those supporting critical or important functions.

Does designation as a CTPP confirm that a provider is secure?

No. It means the provider is brought within an oversight framework because of its criticality. The financial entity remains responsible for its own assessment and risk management.

Is an ISO/IEC 27001 certificate enough for DORA compliance?

No. It can support some controls and evidence, but DORA contains its own requirements on the management body, reporting, testing, the register of information, contracts and provider oversight.