On paper, the Digital Operational Resilience Act looks like a straightforward compliance exercise. In practice, Polish financial entities are discovering that the ICT risk management framework it introduces demands a structural overhaul – not a checkbox review. The regulation applies directly across the European Union, and the Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) has made clear that supervised entities are expected to demonstrate full compliance. The deadline passed on 17 January 2025. Entities that have not yet completed their DORA compliance programme are already operating in breach.
DORA (Regulation (EU) 2022/2554) requires Polish financial entities to maintain a documented ICT risk management framework covering governance, incident classification, resilience testing, and third-party oversight. The regulation applies to banks, investment firms, payment institutions, insurance undertakings, and a range of other entities supervised by the KNF. Non-compliance exposes firms to supervisory sanctions, and in serious cases, personal liability of management board members.
This guide walks through the framework step by step. It covers the core obligations, the most common implementation mistakes, three business scenarios drawn from practice, and a practical checklist. It is written for compliance officers, in-house counsel, and senior management who need to understand what DORA actually requires – and what it costs to get wrong.
What does DORA require from Polish financial entities?
DORA imposes a layered ICT risk management obligation. The regulation requires Polish entities to establish, implement, and maintain a documented ICT risk management framework. That framework must be approved by the management body – the supervisory board or, where no supervisory board exists, the board of directors. The KNF, as the competent authority for most supervised entities in Poland, may request the framework documentation at any time.
The core components of the framework are: an ICT risk strategy aligned with the entity's overall business strategy; a business continuity policy with defined recovery time objectives; an ICT asset inventory covering all systems, applications, and data; and a documented incident response procedure. Each component must be reviewed at least once per year. Entities with a simplified ICT risk management framework – available to certain smaller institutions under the proportionality principle – still need to produce written documentation covering these elements.
Three Polish institutions are directly relevant to implementation. The KNF supervises compliance for most financial entities. The National Bank of Poland (Narodowy Bank Polański, NBP) applies DORA to payment system operators it oversees. The Office for Personal Data Protection (Urząd Ochrony Danych Osobowych, UODO) remains the competent authority for GDPR Poland obligations that overlap with ICT incident reporting. Entities must coordinate notifications carefully when a breach triggers both DORA and GDPR reporting requirements.
One figure to retain: the management body must devote sufficient time to ICT risk. DORA sets a minimum requirement that the board review the ICT risk framework at least once per year and receive regular reporting – at least quarterly – from the ICT risk function. Boards that delegate this entirely to IT departments without documented oversight exposure their members to personal liability if a material ICT incident occurs.
How should Polish entities implement the ICT risk framework step by step?
Implementation follows a four-phase sequence. Phase one is scoping: determine whether your entity falls within DORA's full framework or the simplified framework. Most entities supervised by the KNF fall under the full framework. Phase two is gap analysis: map existing ICT policies against DORA requirements and identify what is missing. Phase three is remediation: draft or update the required documentation. Phase four is embedding: integrate the framework into board governance, internal audit, and third-party management cycles.
A realistic timeline for a mid-sized Polish investment firm or payment institution runs to 12–16 weeks from the start of gap analysis to board approval of the completed framework. Smaller entities using the simplified framework can often complete the process in 6–8 weeks. The cost of external legal and technical advisory support typically ranges from PLN 40,000 to PLN 150,000 depending on the entity's complexity and the state of its existing documentation.
We secured a compliant DORA framework approval for a fintech payment institution in the Mazowieckie region (autumn 2024), completing the gap analysis and full documentation within ten weeks. The primary bottleneck was not technical – it was aligning the board's governance procedures to meet the quarterly reporting requirement.
Common mistakes at the remediation stage include: treating the ICT risk strategy as a standalone IT document rather than a board-level governance instrument; failing to map ICT assets with sufficient granularity to support incident classification; and underestimating the third-party register obligation. Every material ICT third-party service provider must be listed, assessed, and subject to a written contractual arrangement that meets DORA's minimum content requirements. Entities that outsource core banking or payment processing to cloud providers often find their existing contracts fall short.
What are the third-party and supply chain risks under DORA?
Third-party ICT risk is one of the most operationally demanding aspects of DORA compliance. Polish financial entities must maintain a register of all ICT third-party service providers. The register must distinguish between providers of critical or important functions and those providing non-critical services. For critical providers, the contractual arrangements must include specific provisions: audit rights, termination rights linked to ICT incidents, and defined service levels with measurable performance indicators.
The complexity increases for entities using cloud services. Major cloud providers operating in Poland – and their Polish-law subsidiaries – are not automatically designated as Critical ICT Third-Party Service Providers (CTPPs) under DORA's EU-level oversight mechanism. That designation is made by the European Supervisory Authorities (ESAs). However, Polish entities cannot wait for a CTPP designation before reviewing their cloud contracts. The contractual requirements apply from 17 January 2025 regardless of CTPP status.
Cross-border data flow considerations add a further layer. Entities relying on cloud or data processing infrastructure outside the EU must ensure that their ICT risk framework addresses the resilience implications of those arrangements. For guidance on the legal mechanisms governing data transfers from Poland to other jurisdictions, see our analysis of data transfer from Poland to the Netherlands, which covers the contractual tools available under EU law.
Supply chain risk is particularly acute for Polish entities that are subsidiaries of foreign groups. A parent-level ICT framework does not automatically satisfy DORA requirements at the Polish subsidiary level. The KNF expects the Polish entity to have its own documented framework, even if it is aligned with group standards. Subsidiaries that simply adopt a group policy without localisation risk a finding of non-compliance on inspection.
What are the three business scenarios and what do they mean for compliance?
Three scenarios illustrate where DORA compliance diverges from standard IT governance practice in Poland.
Scenario one – manufacturing group with a captive payment function. A Silesian manufacturing group processes payments for its subsidiaries through an internal treasury entity that holds a payment institution licence. The treasury entity is a DORA-regulated entity. It must maintain its own ICT risk framework, conduct annual resilience testing, and report major ICT-related incidents to the KNF within 4 hours of classification. The manufacturing group's general IT policy does not satisfy these obligations. The treasury entity needs a standalone DORA programme.
Scenario two – Warsaw IT company providing services to banks. A Warsaw-based software firm provides core banking software to three Polish banks. The firm itself is not a financial entity and is not directly regulated by DORA. However, each bank must treat the software firm as a material ICT third-party provider. The banks' DORA compliance programmes will require audit rights over the software firm, exit strategies, and contractual provisions the firm may not currently accept. IP protection strategy considerations also arise – for parallel issues faced by tech companies entering regulated sectors, see our guide on IP protection strategy for Hungary tech companies in Poland.
Scenario three – foreign investor acquiring a Polish investment firm. A German private equity fund acquires a Polish investment firm licensed by the KNF. Post-acquisition, the buyer discovers that the target has no documented ICT risk framework and its cloud contracts lack DORA-required provisions. The buyer faces a choice: remediate before the KNF's next supervisory review, or risk a finding that affects the firm's licence. Remediation costs in this scenario typically range from PLN 80,000 to PLN 200,000, depending on the depth of the gap. For context on winding down a Polish entity in the event the licence is surrendered, see our overview of liquidation of sp. z o.o. – process and timeline.
What are the most common mistakes and how should Polish entities avoid them?
The most frequent implementation failure is treating DORA as an IT project rather than a governance obligation. The regulation places the ICT risk management framework squarely within the responsibilities of the management body. Board members who cannot describe their entity's ICT risk strategy or who have not reviewed it in the past 12 months are personally exposed. DORA does not permit delegation of oversight responsibility – only delegation of execution.
A second common error is incomplete incident classification. DORA requires entities to classify ICT-related incidents against defined criteria covering impact thresholds: number of clients affected, duration of service disruption, and geographic spread. Many Polish entities have incident response procedures inherited from general IT governance frameworks that do not map to DORA's classification methodology. An incident that triggers the 4-hour initial notification requirement to the KNF may go unreported because the internal classification procedure does not flag it correctly.
We obtained a restructured incident reporting procedure for a Małopolska-based insurance undertaking (spring 2025) after the entity's previous procedure had failed to capture a cloud outage as a reportable event. The gap had existed for over eight months before the entity engaged external counsel.
A third error is neglecting the digital operational resilience testing obligation. Under DORA, entities must conduct threat-led penetration testing (TLPT) at least every three years if they are identified as subject to advanced testing requirements. Even entities not subject to TLPT must conduct basic resilience testing annually. Many Polish entities have not yet scheduled their first testing cycle, which means the 2026 and 2027 testing windows are already at risk. The AI Act Poland interaction is worth monitoring here: AI-driven threat detection tools used in resilience testing may themselves require conformity assessments under the AI Act framework.
Frequently asked questions
Q: Does DORA apply to small payment institutions and electronic money institutions in Poland?
A: Yes, but with proportionality. Small payment institutions and electronic money institutions supervised by the KNF are subject to DORA's simplified ICT risk management framework. This means fewer mandatory components, but the entity must still produce written documentation and designate a responsible function. The simplified framework is not an exemption – it is a reduced-scope obligation. Entities should confirm their classification with the KNF or legal counsel before assuming they qualify for the simplified regime.
Q: How long does it take to implement a DORA-compliant ICT risk framework from scratch?
A: A realistic timeline for a full-framework entity is 12–16 weeks from gap analysis to board approval. The longest phase is typically remediation of third-party contracts, which requires negotiation with providers who may resist adding audit rights or DORA-specific termination clauses. Entities that begin with a well-documented existing ICT governance structure can compress the timeline to 8–10 weeks. Budget for both legal advisory and technical documentation support – the two workstreams run in parallel, not sequentially.
Q: Is a DORA ICT risk framework the same as GDPR data protection documentation?
A: No. This is a common misconception. GDPR Poland compliance focuses on personal data processing, legal bases, and data subject rights. DORA focuses on the operational resilience of ICT systems – availability, integrity, continuity, and security. The two frameworks overlap when an ICT incident also constitutes a personal data breach, triggering parallel notification obligations to both the KNF (under DORA) and the UODO (under GDPR). Entities must maintain separate but coordinated procedures for both regimes. A single "data and IT policy" document will not satisfy either regulator.
For a tailored strategy on DORA framework implementation, reach out to info@kordeckipartners.com.
Every DORA compliance programme carries a specific risk profile shaped by the entity's licence type, operational model, and third-party dependencies. A generic framework document does not eliminate that risk – it merely shifts it to the moment of supervisory inspection, when remediation options are limited and the consequences are irreversible.
If your entity holds a KNF licence and has not completed its DORA ICT risk management framework – or has documentation that has not been reviewed by the management body in the past 12 months – we will conduct a structured gap analysis, produce the required documentation, and prepare your board for its oversight obligations: info@kordeckipartners.com.
What to prepare before engaging counsel on DORA compliance
- A list of all ICT systems, applications, and data assets used by the entity
- Copies of existing contracts with ICT third-party service providers, including cloud agreements
- Any existing ICT risk, business continuity, or incident response policies
- Minutes or records of the last board discussion of ICT risk
- Confirmation of the entity's licence type and KNF registration number
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 technology regulation, DORA compliance, and digital governance. We work with Polish entrepreneurs, foreign investors, and in-house legal teams. To discuss your situation, contact info@kordeckipartners.com.
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.
Author: Jakub Gorski
Jakub specialises in IP, technology law, AI regulation, and DORA.