A Warsaw-based payment institution receives a letter from the Polish Financial Supervision Authority (KNF) requesting evidence of its ICT risk management framework. The institution's IT team has been running informal patch cycles and undocumented vendor contracts for years. The DORA deadline passed on 17 January 2025 – and the gap between practice and requirement is now a supervisory liability.

The Digital Operational Resilience Act (DORA) – Regulation (EU) 2022/2554 – became directly applicable across all EU member states, including Poland, on 17 January 2025. It applies to more than 20 categories of financial entity, from banks and insurers to crypto-asset service providers and certain ICT third-party service providers. Entities that have not yet built a compliant ICT risk management framework face supervisory measures, reputational damage, and – for senior managers – potential personal liability.

This guide walks through the scope of DORA, the step-by-step compliance procedure, the three most common business scenarios in Poland, typical costs and timelines, and the mistakes that most frequently surface during KNF supervisory reviews. Each section opens with the direct answer, then develops the detail you need to act.

Which entities must comply with DORA?

DORA applies to a defined list of financial entities operating in the EU. The list is long – over 20 categories – and Polish law does not narrow it. If your entity holds a licence or authorisation from the KNF, the National Bank of Poland (NBP), or the Bank Guarantee Fund (BFG), it almost certainly falls within scope. The entry threshold for some categories is zero: even a small payment institution with a single licence is fully in scope from day one.

The core categories covered include credit institutions (banks), payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers authorised under MiCA, and central counterparties. DORA also captures credit rating agencies, crowdfunding service providers, and data reporting service providers. Each category carries the same core obligations, though a proportionality principle allows smaller entities to apply a simplified ICT risk management framework.

Critically, DORA extends beyond the financial entity itself. ICT third-party service providers – cloud platforms, data analytics vendors, software suppliers – that provide services to in-scope financial entities are subject to oversight by the European Supervisory Authorities (ESAs). Critical ICT third-party providers (CTPPs) designated by the ESAs face direct supervisory powers. This means a Polish fintech that supplies core banking software to a licensed bank is now part of a regulated supply chain, whether or not it holds its own financial licence.

  • Banks, credit unions, and electronic money institutions
  • Payment institutions and account information service providers
  • Investment firms, fund managers, and central counterparties
  • Insurers, reinsurers, and insurance intermediaries
  • Crypto-asset service providers (from MiCA authorisation)

One common misconception is that subsidiaries of foreign groups are covered by the parent's DORA programme. They are not. Each Polish legal entity that holds an EU financial licence must maintain its own compliant framework. A German bank's Warsaw branch, for example, must document its own ICT risk management processes and report incidents independently to the KNF. Group-level policies can inform local implementation, but they do not substitute for it.

What are the core DORA compliance requirements?

DORA structures its requirements across five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Each pillar carries specific documentation, process, and testing obligations. The first supervisory reviews in Poland are already underway, with the KNF having issued its first formal requests for ICT risk management documentation in early 2025.

The ICT risk management pillar requires a written framework covering identification, protection, detection, response, and recovery. The framework must be reviewed at least once a year and after every major ICT incident. Smaller entities applying the simplified framework still need a documented policy – the simplification reduces the granularity of controls, not the obligation to have them. Entities have been required to maintain this framework since 17 January 2025, with no transitional grace period.

Incident reporting is time-critical. Major ICT-related incidents must be reported to the KNF within four hours of classification, with a detailed intermediate report within 72 hours and a final report within one month. The classification criteria – covering the number of clients affected, transaction value disrupted, and duration of downtime – are set by the European Banking Authority (EBA) in binding technical standards. Missing the four-hour initial notification window is itself a reportable compliance failure.

We secured a full remediation plan for a payment institution client in the Mazowieckie region (autumn 2024), identifying 14 undocumented critical ICT vendors and restructuring all contracts to meet DORA's third-party risk requirements before the January 2025 go-live date.

The digital operational resilience testing pillar requires all in-scope entities to run basic testing annually – including vulnerability assessments and network security tests. Significant institutions must also conduct threat-led penetration testing (TLPT) at least every three years. TLPT must be performed by certified testers using a methodology approved by the relevant competent authority. For Polish banks designated as significant, this means coordinating with the KNF and, in cross-border scenarios, with the European Central Bank (ECB).

How should Polish entities structure their DORA implementation timeline?

The DORA deadline of 17 January 2025 has passed. Entities that have not yet completed implementation are already in breach. The practical question is now remediation sequencing: which gaps carry the highest supervisory risk, and in what order should they be closed? A structured remediation programme typically runs 90 to 180 days for a mid-sized institution, depending on the complexity of its ICT environment and vendor contracts.

Phase one – gap analysis – should be completed within 30 days. This means mapping all ICT assets, identifying in-scope vendors, and comparing existing policies against the five DORA pillars. The gap analysis produces a prioritised remediation list. The KNF has indicated in its supervisory communications that it will assess whether entities have a credible remediation plan, not just whether they have achieved full compliance on day one.

Phase two covers documentation and policy drafting. An ICT risk management framework, an incident classification and reporting procedure, a third-party risk register, and a resilience testing schedule are the minimum deliverables. For a payment institution with 20 to 50 staff, this phase typically takes 30 to 60 days with external legal and technical support. Budget estimates for this phase range from PLN 80,000 to PLN 250,000, depending on the scope of external advisory engagement.

Phase three is vendor contract remediation. DORA mandates specific contractual clauses in all agreements with ICT third-party providers. These include audit rights, service level commitments, data location provisions, and exit strategy requirements. Many legacy contracts – particularly cloud service agreements signed before 2022 – do not contain these clauses. Renegotiating or amending them takes time. Vendors such as hyperscale cloud providers typically offer standard addenda, but bespoke contractual arrangements require bilateral negotiation.

For organisations with cross-border data flows – a common scenario for Polish subsidiaries of international groups – DORA's third-party risk requirements interact directly with GDPR obligations. The data transfer mechanisms discussed in our analysis of data transfer from Poland to France are directly relevant when ICT vendors process personal data in non-EEA jurisdictions.

What do the three main business scenarios look like in practice?

DORA compliance looks different depending on the entity type, size, and operational model. Three scenarios recur most frequently in our practice: the Polish-owned payment institution, the subsidiary of a foreign financial group, and the fintech that supplies ICT services to licensed entities. Each faces a distinct compliance challenge and a different cost profile.

The Polish-owned payment institution typically holds a KNF licence under the Payment Services Act and processes transactions for retail or SME clients. Its ICT environment is often a mix of proprietary systems and cloud-hosted services. The core challenge is documentation: most institutions of this type have informal IT governance that must be formalised into a DORA-compliant framework. The simplified ICT risk management framework is available if the institution meets the proportionality criteria – but the institution must affirmatively assess and document its eligibility. Remediation cost typically falls between PLN 100,000 and PLN 180,000.

The subsidiary of a foreign financial group – say, a German asset manager with a Warsaw office – faces a different challenge. The parent group may already have a DORA programme, but the Polish entity must demonstrate independent compliance to the KNF. This means translating group-level policies into entity-specific documentation, establishing a local incident reporting procedure, and ensuring that the Polish entity's vendor contracts contain DORA-compliant clauses. Cross-border coordination adds complexity: the subsidiary must align its TLPT schedule with both the KNF and its home-state supervisor. For technology companies with IP considerations in Poland, our guide on IP protection strategy for Luxembourg tech companies in Poland provides relevant structural context.

The fintech ICT supplier is the most misunderstood scenario. A Polish company that provides core banking software, cloud infrastructure, or data analytics to a licensed bank is not itself a financial entity – but it is now part of a regulated supply chain. If the ESAs designate it as a critical ICT third-party provider, it becomes subject to direct supervisory oversight, including the right of the lead overseer to conduct on-site inspections. Even below the CTPP threshold, the fintech must accept audit clauses, data location requirements, and exit strategy obligations in its customer contracts. Failure to accept these terms risks losing major financial institution clients.

What are the most common DORA compliance mistakes?

The mistakes that generate supervisory risk fall into four recurring patterns. Identifying them early – ideally during the gap analysis phase – avoids the irreversible consequence of a KNF enforcement action, which can result in fines, licence conditions, or public censure. For senior managers, DORA creates direct personal accountability: management body members are responsible for approving and overseeing the ICT risk management framework, and supervisors can hold them personally liable for systemic failures.

The first mistake is treating DORA as an IT project rather than a legal and governance obligation. ICT risk management under DORA is a board-level responsibility. The management body must approve the framework, receive regular ICT risk reports, and allocate sufficient budget for resilience testing. Delegating the entire programme to the IT department – without board-level ownership – is itself a compliance gap. The KNF's supervisory questionnaires explicitly ask about management body involvement.

The second mistake is incomplete vendor mapping. Many institutions know their primary ICT vendors but have not mapped second- and third-tier dependencies. A cloud-hosted core banking system may depend on a sub-processor in a non-EEA jurisdiction. That sub-processor relationship must appear in the institution's ICT third-party risk register and be assessed for concentration risk. DORA's concentration risk provisions are particularly relevant for institutions that rely heavily on one of the three major hyperscale cloud providers.

We obtained a successful outcome in a supervisory dialogue for a fintech client in Lower Silesia (spring 2025), demonstrating to the KNF that the client's DORA remediation plan was credible and on track, which prevented the imposition of interim supervisory measures.

The third mistake is ignoring the interaction between DORA and other regulatory frameworks. DORA's incident reporting obligations overlap with – but do not replace – GDPR breach notification requirements under the Office for Personal Data Protection (UODO). An ICT incident that involves personal data triggers both a DORA report to the KNF and a GDPR notification to the UODO within 72 hours. Institutions that have not mapped these parallel obligations risk missing one of the two deadlines. The KSeF invoicing framework, discussed in our overview of what KSeF means for your business in Poland, illustrates how digital compliance obligations across different regulatory regimes can interact operationally.

The fourth mistake is failing to test. Basic resilience testing is mandatory annually. Many institutions completed their gap analysis and documentation work but have not yet run a structured vulnerability assessment or penetration test. Testing is not optional – it is the mechanism by which the institution validates that its controls actually work. Without test results, the ICT risk management framework is a paper exercise, and the KNF will treat it as such.

What should your compliance checklist include at minimum? The following items are the non-negotiable starting points:

  • Board-approved ICT risk management framework (or simplified equivalent)
  • Documented ICT asset inventory and vendor register
  • Incident classification and reporting procedure mapped to KNF notification requirements
  • DORA-compliant clauses in all critical ICT vendor contracts
  • Annual resilience testing schedule with documented results

To receive an expert assessment of your entity's DORA compliance position, contact info@kordeckipartners.com. Our team will review your current framework, identify priority gaps, and provide a structured remediation roadmap within two weeks.

Frequently asked questions

Q: Does DORA apply to small payment institutions with fewer than 10 employees?

A: Yes. DORA applies to all licensed payment institutions regardless of size. However, the proportionality principle allows micro-enterprises to apply a simplified ICT risk management framework. The institution must affirmatively assess and document its eligibility for the simplified regime – it does not apply automatically. Even under the simplified framework, incident reporting and vendor contract obligations remain fully in force.

Q: How long does full DORA implementation take, and what does it cost?

A: For a mid-sized financial institution with 50 to 200 staff, a full implementation programme – covering gap analysis, documentation, vendor contract remediation, and initial resilience testing – typically takes 90 to 180 days. External advisory costs in Poland range from PLN 80,000 to PLN 350,000 depending on the complexity of the ICT environment. Institutions that began implementation late should prioritise incident reporting procedures and vendor contract amendments, as these carry the highest immediate supervisory risk.

Q: Is DORA separate from the AI Act and GDPR obligations in Poland?

A: Yes, DORA is a standalone regulation. It does not replace GDPR Poland obligations or the AI Act Poland requirements that apply to AI systems used in financial services. The three frameworks interact: an AI-driven credit scoring tool used by a bank may be subject to DORA's ICT risk management rules, the AI Act's high-risk system requirements, and GDPR's automated decision-making restrictions simultaneously. Mapping these overlaps is an important step in any financial institution's compliance programme. Our team advises on all three frameworks as part of an integrated digital compliance engagement.

Specific DORA compliance questions often require analysis of your entity's licence type, ICT architecture, and existing vendor contracts before a reliable answer is possible. General guidance covers the framework – your situation requires tailored assessment.

To discuss how DORA applies to your specific entity and receive a structured remediation plan, email info@kordeckipartners.com. We advise payment institutions, investment firms, and fintech ICT suppliers across Poland and 30 jurisdictions.

About KORDECKI & Partners

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to digital regulatory compliance, including DORA, the AI Act, and GDPR. We work with Polish entrepreneurs, foreign investors, and in-house legal teams. To discuss your situation, contact info@kordeckipartners.com.

Author: Jakub Gorski – Jakub specialises in IP, technology law, AI regulation, and DORA.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. KORDECKI & Partners assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@kordeckipartners.com.