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

Legal status of DORA as of 29 August 2026

DORA entered into force on 16 January 2023, but most of its provisions have applied since 17 January 2025. That date was not the beginning of an implementation project; it was the date from which entities within scope were expected to comply.^[1]

The basic Regulation is supplemented by Level 2 acts. The most important concern the ICT risk-management framework, incident classification, reporting content and deadlines, policies for ICT services, the register of information, subcontracting, and TLPT. An assessment based only on the text of DORA is therefore incomplete.

Poland: the Act of 25 June 2025 amended sectoral legislation and the National Cybersecurity System Act, defined supervisory competences, and introduced national enforcement mechanisms. DORA itself remains the direct source of the main obligations of financial entities.^[2]

Who is covered by DORA

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

Scope cannot be determined from an industry label or the generic term "fintech". The regulatory status of the specific entity and the exclusions in Article 2(3) must be checked. Proportionality adjusts implementation to size, risk profile, and complexity, but does not create a blanket exemption for every small organization.

ICT providers

An ordinary ICT provider does not become a "DORA financial entity" merely because it signs a contract with one. Its obligations arise mainly from its contract with the financial entity. Providers designated by the European Supervisory Authorities as critical ICT third-party service providers (CTPPs) have a different status and are subject to direct EU oversight.

ICT risk management and management-body responsibility

The management body bears ultimate responsibility for ICT risk management. It must approve and oversee the risk-management framework, roles, resilience strategy, continuity and recovery plans, budget, and policy for ICT third-party services. Members of the management body are expected to maintain sufficient knowledge to understand and assess ICT risk.^[1]

Articles 5-16 cover 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;
• internal and external communication.

Commission Delegated Regulation (EU) 2024/1774 develops requirements for policies, asset management, cryptography, ICT operations, network security, change management, continuity, and reporting. It also specifies simplified frameworks under Article 16 for particular categories of entities, not for any organization that merely considers itself small.^[3]

ICT incidents: classification and reporting deadlines

A financial entity must record ICT-related incidents, manage them under a documented process, and classify them using the criteria in Article 18 DORA. Materiality thresholds are set by Delegated Regulation (EU) 2024/1772. Criteria include affected clients and counterparties, duration and downtime, geographic spread, losses of availability, authenticity, integrity or confidentiality, the criticality of affected services, and economic impact.^[4]

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

In Poland, major ICT incident reports and notifications of significant cyber threats are submitted through the SOID system provided by the Polish Financial Supervision Authority (KNF). KNF also publishes a contingency procedure for system outages. A report submitted by an alternative channel must be entered into the system after service is restored. Access data and procedures should be verified on the KNF website before an incident occurs.^[15]

Notification of a significant cyber threat is voluntary. Where a major ICT incident affects the financial interests of clients, Article 19(3) requires them to be informed without undue delay about the incident and measures taken to mitigate its effects. The same event may also trigger GDPR or other statutory reporting duties; a DORA report does not automatically replace them.

Resilience testing and TLPT

The testing program must be risk-based and use appropriate techniques, from vulnerability assessments, scans, and configuration reviews to scenario-based, continuity, performance, end-to-end, and penetration testing. Systems and applications supporting critical or important functions must be tested regularly, with scope adjusted to risk and change.

TLPT does not automatically apply to every entity

Threat-led penetration testing is required for entities selected by the competent authority under 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 risk profile and operational circumstances. Microenterprises and entities applying the simplified framework under Article 16(1) are excluded from the TLPT obligation.^[7]

TLPT covers critical or important functions and production systems, including material dependencies on third parties. The process includes scope definition, threat intelligence, controlled red-team activity, closure, and a remediation plan. An ordinary application penetration test does not become TLPT simply because it uses realistic attack scenarios.

Safety remains essential: scope, stopping conditions, confidentiality, crisis communication, and responsibility for production systems must be agreed before testing begins. DORA does not justify uncontrolled testing of production systems.

ICT providers, contracts, and the register of information

Using an external service does not transfer regulatory responsibility. A financial entity must manage risk across the full contract lifecycle: classification of the function and due diligence, negotiation, monitoring and audit, termination, and exit planning.

The register covers all ICT service arrangements

Article 28(3) requires an up-to-date register of information on all contractual arrangements for ICT services. Arrangements supporting critical or important functions must be clearly distinguished. Standard templates and taxonomies are established by Implementing Regulation (EU) 2024/2956.^[8]

Contracts must reflect risk

Article 30 specifies required contractual elements, including descriptions of services and locations, data protection, incident support, post-termination duties, and cooperation with authorities. Services supporting critical or important functions are subject to additional requirements concerning service levels, continuity plans, participation in testing, access and inspection rights, audit rights, and exit strategies. Delegated Regulation (EU) 2024/1773 develops the policy for managing these arrangements.^[9]

Subcontracting

Delegated Regulation (EU) 2025/532 requires assessment of subcontracting chains that support critical or important functions. Contracts should specify conditions for subcontracting, notification of material changes, oversight rights, and grounds for termination. Reliance solely on the main provider's own assessment does not remove the financial entity's responsibility.^[10]

CTPPs: direct oversight of critical providers

The European Supervisory Authorities published the first list of 19 designated critical ICT third-party providers on 18 November 2025. It included entities from groups such as Accenture, AWS, Google Cloud, IBM, Microsoft, Oracle, SAP, and operators of telecommunications and data-centre infrastructure. The list is to be updated at least annually.^[11]

A Lead Overseer is appointed for each CTPP. It assesses risk management, can conduct inspections, and can issue recommendations. CTPP designation is not a security certificate and does not relieve a financial entity of due diligence, concentration-risk monitoring, or exit planning.^[12]

If a CTPP fails to cooperate with oversight powers, the Lead Overseer may impose a periodic penalty payment equal to 1 % of the provider's average daily worldwide turnover in the previous business year for each day of non-compliance, 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 where the purpose is to improve resilience and the arrangements protect confidentiality, personal data, and trade secrets. This is an option, not an obligation to share complete log sets. An organization should define the legal basis, data classification, minimization, and onward-sharing rules in advance.

DORA, NIS2, KSC, and GDPR

DORA and NIS2

NIS2 treats DORA as sector-specific Union law with at least equivalent effect for ICT risk management and major incident reporting for covered financial entities. That does not mean every legal issue affecting a financial organization is regulated exclusively by DORA. Scope, subject matter, and national provisions must be compared.^[13]

DORA and the Polish KSC

The 2025 Polish act inserted Article 16a into the KSC to avoid duplication of certain duties for operators in banking and financial-market infrastructure where DORA applies. The 2026 KSC amendment implementing NIS2 does not change the need to assess both legal regimes using their current texts.

DORA and GDPR

DORA protects operational resilience and deals with ICT incidents; GDPR regulates personal-data processing and personal-data breaches. They use different legal tests. One event may need reporting under both regimes, under one, or under neither, depending on DORA classification and the risk to individuals' rights and freedoms.^[14]

How to organize implementation and evidence

1. Confirm scope. Determine regulatory status, branches, exclusions, and competent authorities.
2. Identify functions. Define critical or important functions, processes, owners, and disruption tolerance.
3. Map dependencies. Link functions to assets, data, applications, locations, and ICT providers.
4. Assess the risk framework. Verify management decisions, policies, roles, resources, metrics, and reporting.
5. Exercise incidents. Test classification, both initial-notification clocks, forms, communications, and parallel reporting regimes.
6. Clean up the register. Align identifiers, taxonomies, completeness of contracts, and data-quality controls.
7. Remediate contracts. Prioritize services supporting critical or important functions and their subcontracting chains.
8. Build a testing program. Link tests to risk, change, and functions; prepare TLPT only where the entity is actually subject to it.
9. Retain evidence. Resolutions, reports, logs, test results, and accepted exceptions should identify scope, date, owner, and follow-up action.

There is no universal cost or implementation timeline for DORA. It depends on licensing, architecture, contract quality, provider count, inventory quality, and incident-process maturity. A policy document without execution and evidence does not close a gap.

Common mistakes

• limiting the program to the security department without business owners and management involvement;
• treating every agreement as outsourcing or, conversely, ignoring ICT services embedded in broader services;
• maintaining the register only for providers of critical or important functions;
• no 24/7 capability to classify and approve an incident report;
• treating an ordinary penetration test as TLPT;
• accepting a provider report as a substitute for the financial entity's own risk assessment;
• no credible exit strategy or service-recovery testing;
• assuming ISO/IEC 27001 certification automatically proves DORA compliance.