DORA Poland 2026: ICT Risk Management Rules for Payment & E‑money Institutions

DORA compliance Poland is now the defining operational-resilience challenge for payment institutions, e‑money institutions and the wider fintech sector, with 2026 marking the phase in which supervisory expectations crystallise and the Komisja Nadzoru Finansowego (KNF) aligns its inspection practice with the Regulation. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025 and is directly applicable across all EU Member States, so Polish PSPs and EMIs are bound by it without the need for national transposition. What changes in 2026 is not the legal text but the intensity of scrutiny: ICT risk governance, incident reporting, threat‑led penetration testing and third‑party contracts are moving from paper policy to evidenced practice.

This guide translates DORA into a Poland-specific playbook mapped to the Payment Services Act and KNF supervisory reality, with concrete controls, timelines and templates for compliance, technology and legal leads.

Who this is for: heads of compliance, CTOs/CISOs and legal leads at Polish payment institutions and e‑money institutions. What it delivers: a practical DORA compliance playbook covering ICT risk management, incident reporting, TLPT readiness and third‑party controls, mapped to KNF supervisory practice for 2026.

Executive summary: key takeaways for Polish PSPs & EMIs

The essentials of DORA compliance Poland for payment and e‑money institutions, distilled into actionable points:

• In scope by default. Payment institutions and EMIs authorised under the Polish Payment Services Act fall within DORA’s scope as “financial entities” under Regulation (EU) 2022/2554; there is no opt-out.
• Board ownership is non-negotiable. The management body holds ultimate accountability for the ICT risk-management framework, board-level approval, review and documented oversight are expected.
• Five control pillars. Governance, ICT risk identification and asset mapping, protection and prevention, detection, and response and recovery must all be evidenced, not merely described.
• Incident reporting is harmonised and time-bound. Major ICT-related incidents trigger classification, initial notification, intermediate and final reporting to the competent authority, in Poland, the KNF.
• TLPT applies selectively. Threat-led penetration testing is mandatory only for entities identified by authorities as significant enough to warrant it, but every entity must run a proportionate testing programme.
• Third-party risk is a supervisory priority. Contracts with ICT providers, especially cloud, must contain prescribed clauses, and a register of information must be maintained.
• KNF focus for 2026. Expect scrutiny of outsourcing registers, incident-handling evidence, and TLPT readiness during supervisory reviews.
• Act on a roadmap. A 90/180/365-day plan with named owners across compliance, security, legal and procurement is the fastest route to demonstrable DORA compliance Poland.

What DORA is and which Polish entities are in scope

DORA: the legal definition and the supervising authority

DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. As an EU regulation, it is directly applicable in Poland and does not require a national implementing statute to bind Polish financial entities, though some national-level measures may designate competent authorities and procedures. It establishes a single, consolidated framework covering ICT risk management, ICT-related incident reporting, digital operational resilience testing, the management of ICT third-party risk, and information-sharing arrangements. For Polish payment and e‑money institutions, the competent authority exercising supervision is the Komisja Nadzoru Finansowego (KNF), which integrates DORA expectations into its existing prudential and conduct supervision.

Entities in scope, mapping to Polish PSP and EMI categories

DORA defines “financial entities” broadly, and the list expressly captures payment institutions and electronic money institutions. In the Polish context, these are the entities authorised under the Act on Payment Services (ustawa o usługach płatniczych), which implements PSD2 domestically. The practical effect is that an entity holding a Polish payment institution or EMI authorisation must treat DORA as a licence-level obligation: failure to meet the ICT risk-management and reporting standards is a supervisory matter, not merely a technical shortcoming.

Proportionality is built into DORA: certain smaller and less complex entities may apply a simplified ICT risk-management framework, but the substantive objectives, resilience, recoverability and accountability, do not disappear. Polish EMIs and PSPs should document how they have applied proportionality rather than assuming it exempts them from evidence, and should confirm their precise classification given that the scope of simplified arrangements is defined in DORA itself.

Core DORA ICT risk-management requirements distilled for PSPs/EMIs

The heart of DORA compliance Poland is a robust, documented ICT risk-management framework owned at board level. Below the requirements are distilled into four practical workstreams, each with the evidence KNF inspectors are likely to request.

Governance and roles

DORA places ultimate responsibility for ICT risk on the management body. The board must approve, oversee and periodically review the ICT risk-management framework, set the entity’s digital operational resilience strategy, and allocate adequate budget and staffing. Senior management, typically a CISO or equivalent, must own day-to-day implementation. For DORA ICT risk management Poland, the evidence pack should include:

• A board-approved ICT risk-management policy with a dated approval and a defined review cycle.
• Minutes demonstrating board discussion of ICT risk, incidents and testing outcomes.
• Clear role descriptions for the ICT risk function, segregation of duties, and reporting lines to the board.
• Evidence of board and staff training on digital operational resilience.

ICT risk identification and asset mapping

You cannot protect what you have not inventoried. DORA requires entities to identify, classify and document all ICT-supported business functions, information assets and ICT assets, including their interdependencies and the links to ICT third-party service providers. Payment and e‑money institutions should maintain a living asset register with criticality scoring that ties each system to the business function it supports, the data it processes, and the downstream customer impact if it fails. Mapping dependencies on third parties is essential, a failure in a cloud hosting provider or a card-processing partner often represents the single largest concentration of operational risk for an EMI.

Business continuity and recovery planning

DORA requires a comprehensive ICT business continuity policy and associated response and recovery plans. For payment institutions and EMIs, where availability of payment rails directly affects customers and merchants, this means defining recovery time objectives (RTO) and recovery point objectives (RPO) for each critical function, maintaining backup and restoration procedures, and testing them. Plans must address cross-border recovery where processing or data sits outside Poland. Continuity arrangements should be rehearsed through tabletop exercises and documented, with lessons learned fed back into the framework.

Protection, detection and controls testing

Beyond planning, DORA expects continuous protective and detective controls. A recommended control set for Polish PSPs and EMIs includes:

• Access management. Role-based access, least privilege, multi-factor authentication for privileged and remote access, and periodic access recertification.
• Encryption. Encryption of data in transit and at rest, with documented key-management procedures.
• Patch and vulnerability management. Defined timelines for remediating critical vulnerabilities and an inventory-driven patching regime.
• Logging and monitoring. Centralised logging, anomaly detection, and alerting capable of surfacing ICT-related incidents promptly.
• Change management. Controlled deployment processes with rollback plans and segregation between development and production.
• Network segmentation. Isolation of critical payment systems from general corporate networks.
• Data integrity and backup. Immutable backups tested for restorability.

Each control should be mapped to the asset register and to a testing schedule, so that the entity can demonstrate not just that controls exist but that they work. This evidence-first mindset is what distinguishes mature DORA compliance Poland programmes from those that will struggle under supervisory review.

Incident reporting and operational resilience testing, including TLPT

Two of the most operationally demanding areas of DORA for payment institutions Poland are the harmonised incident-reporting regime and the testing obligations. Both require processes that can be triggered quickly and documented thoroughly.

DORA incident reporting: scope, classification and timelines

DORA introduces a single framework for classifying and reporting major ICT-related incidents to the competent authority, the KNF for Polish entities. The process runs in stages: first, the entity must classify incidents against DORA’s criteria (which consider factors such as the number of clients affected, data losses, duration, geographical spread, economic impact and criticality of services affected); then, where an incident is classified as major, the entity must submit an initial notification, followed by an intermediate report as the situation develops and a final report once root-cause analysis is complete. Each report must contain prescribed minimum data: what happened, when, the affected services and clients, the impact, and the mitigations applied.

The specific deadlines and templates for each report are set out in the relevant regulatory technical and implementing standards adopted under DORA, which entities should follow precisely. Entities should build an incident-response playbook that encodes these thresholds and timelines so that the reporting clock is never missed when an incident occurs.

DORA incident reporting Poland does not operate in isolation. Payment institutions should reconcile DORA’s framework with existing operational and security incident-reporting duties they already carry, ensuring a single internal workflow can satisfy multiple reporting addressees without duplication or contradiction.

TLPT: threat-led penetration testing in Poland

DORA establishes two tiers of resilience testing. All financial entities must run a proportionate programme of testing, vulnerability assessments, scenario-based tests, penetration testing and, where relevant, source-code reviews. On top of this, advanced threat-led penetration testing (TLPT) is required for entities identified by competent authorities as significant enough to warrant it, based on risk profile and systemic importance. TLPT is a controlled, intelligence-led red-team exercise that simulates realistic adversary behaviour against live production systems.

For DORA TLPT Poland, the practical implications are:

• Not every Polish EMI or PSP will be mandated to perform TLPT, but entities should assess their likely designation and prepare accordingly.
• TLPT must be conducted by testers meeting defined competence and independence requirements, under a governance framework coordinated with the authority.
• Where critical ICT third parties are within scope, their participation and consent must be arranged in advance.
• Evidence of scoping, threat intelligence, test execution and remediation is expected to be retained for supervisory inspection.

Interaction with PSD2 and NIS2 reporting

Polish payment institutions already operate within a web of reporting obligations. PSD2, as implemented in the Payment Services Act, requires notification of major operational and security incidents to the competent authority. The NIS2 Directive imposes cybersecurity and incident-reporting obligations on essential and important entities, with reports flowing to national CSIRT structures. DORA is intended to operate as lex specialis for the financial sector’s ICT-related incident reporting, but entities must still understand where each regime applies, who the addressee is, and how timelines interact. The safest approach is a single incident-management function that determines, at classification, which regimes are triggered and routes reports accordingly, to the KNF, to the relevant CSIRT, or to multiple recipients where overlap exists.

Outsourcing, third-party ICT providers and KNF supervisory focus for 2026

ICT third-party risk is where many payment and e‑money institutions carry their greatest concentration of operational exposure, and it is a declared supervisory priority. DORA outsourcing third-party Poland obligations run from identifying critical providers through to prescribed contract terms and ongoing oversight.

Identifying critical or important ICT third parties

DORA requires entities to assess which ICT services support critical or important functions, because the most rigorous contractual and oversight obligations attach to those relationships. For a Polish EMI or PSP, a practical scoring matrix weighs factors such as the proportion of the customer base affected by a provider outage, the substitutability of the provider, the value and criticality of the service, data sensitivity, and any systemic linkage. Cloud infrastructure providers, core banking or ledger platforms, card-processing partners and KYC/AML technology vendors will frequently score as critical.

Contractual clauses checklist

DORA sets out mandatory contractual provisions for arrangements supporting critical or important functions. Contracts with ICT third parties should, at minimum, address:

• Clear service description and locations. A full description of functions and the locations where data is processed and stored.
• Service levels and monitoring. Quantitative and qualitative performance targets with monitoring and reporting.
• Audit and access rights. Unrestricted rights of access, inspection and audit for the entity and the competent authority.
• Security and data protection. Obligations on confidentiality, availability, integrity and data protection, with incident-notification duties.
• Sub-outsourcing controls. Conditions for sub-contracting critical functions, including approval and notification requirements.
• Cooperation with authorities. Commitments to assist with supervisory requests and, where applicable, resilience testing.
• Exit and termination assistance. Rights of termination, transition support and continuity of service during exit to avoid operational disruption.

These provisions are not optional boilerplate; their absence from a contract supporting a critical function is a clear supervisory finding.

Ongoing vendor risk management

Contracts are the start, not the end. DORA expects continuous oversight: due diligence at onboarding, assessment of concentration risk, monitoring of performance against agreed KPIs, review of security attestations such as ISO 27001 or SOC 2 reports, verification of the provider’s own testing and penetration-testing evidence, and defined escalation triggers. Entities must maintain a register of information documenting all contractual arrangements for the use of ICT services, which is the single document KNF is most likely to request first.

What KNF will look for in 2026

Supervisory engagement in 2026 is expected to concentrate on the maturity and evidence of these controls rather than the mere existence of policies. The likely focus areas include:

• Completeness and accuracy of the register of information on ICT third-party arrangements.
• Presence of mandatory DORA clauses in contracts supporting critical or important functions.
• Demonstrable incident-classification and reporting capability, with records of past incidents and reports.
• Evidence of a testing programme and, where applicable, TLPT scoping and readiness.
• Board-level engagement, shown through minutes and documented oversight.

Entities that can produce these artefacts quickly during an inspection will be far better positioned than those whose compliance exists only as unrehearsed policy. This readiness gap is the central practical theme of DORA compliance Poland in 2026.

Practical roadmap and 90/180/365-day action plan for Polish PSPs/EMIs

A phased plan with named owners converts DORA from an abstract obligation into a managed programme. The following structure suits most Polish payment and e‑money institutions, with owners drawn from the CISO, head of compliance, legal, procurement and the CEO.

Immediate, 0 to 90 days

• Gap analysis. Benchmark current ICT risk-management practice against DORA’s requirements; owner: CISO and head of compliance.
• Governance. Secure board approval of the ICT risk-management framework and resilience strategy; owner: CEO and board.
• Incident playbook. Build and tabletop-test an incident classification and reporting playbook aligned to DORA thresholds; owner: CISO.
• Vendor inventory start. Begin compiling the register of information on ICT third-party arrangements; owner: procurement and legal.

Short term, 90 to 180 days

• Contract remediation. Prioritise and renegotiate contracts supporting critical or important functions to include mandatory DORA clauses; owner: legal.
• Testing schedule. Establish the proportionate testing programme and scope any potential TLPT; owner: CISO.
• Asset register completion. Finalise the ICT asset inventory with criticality scoring and dependency mapping; owner: CISO.
• KNF engagement. Prepare supervisory materials and open channels for pre-notification where appropriate; owner: head of compliance.

Medium term, 180 to 365 days

• TLPT design and execution. Where mandated or prudent, scope, commission and execute threat-led penetration testing with accredited testers; owner: CISO.
• Third-party reviews. Conduct deep-dive oversight reviews of critical providers and verify attestations; owner: procurement and CISO.
• Training. Roll out role-specific resilience and incident-response training across the organisation; owner: head of compliance.
• Audit evidence. Assemble and maintain a supervisory-ready evidence pack, including board minutes, test results, incident records and contract registers; owner: head of compliance.

Each milestone should carry a measurable outcome and a documented owner, so that progress against DORA compliance Poland can be reported to the board and, if asked, to the KNF.

Comparison table: DORA vs PSD2 vs NIS2

Understanding where DORA sits relative to PSD2 and the NIS2 Directive helps Polish PSPs and EMIs avoid duplicated or conflicting reporting workflows.

Enforcement, penalties and supervisory engagement in Poland

Supervisory tools and likely KNF focus areas

As the competent authority, the KNF can deploy its supervisory toolkit, information requests, onsite inspections, remediation requirements and sanctions, to enforce DORA obligations. Early indications suggest that supervisory attention will concentrate on the areas where evidence is most tangible: the register of ICT third-party arrangements, contract clauses for critical functions, incident-handling records, and testing documentation. Entities should assume that policies without supporting evidence of operation will be treated as gaps. The precise sanctioning powers and any administrative penalties are determined under DORA together with the applicable Polish supervisory legislation.

Practical tips for engaging with the KNF

• Prepare a supervisory pack. Maintain a curated set of documents, framework, board minutes, asset register, vendor register, incident log, test reports, that can be produced quickly.
• Adopt disciplined self-reporting. Report major incidents within the required timelines and keep a clear audit trail of each notification.
• Set documentation retention. Retain evidence of controls, tests and incidents for a period sufficient to satisfy supervisory review.
• Negotiate realistic remediation timetables. Where gaps are identified, present a credible, owner-assigned remediation plan rather than open-ended commitments.

Annexes and templates for DORA compliance Poland

To accelerate implementation, compliance teams should build and maintain a standard set of working documents. The following annexes support a mature DORA compliance Poland programme:

• DORA readiness checklist. A control-by-control self-assessment mapped to governance, risk identification, protection, detection, response and testing.
• Vendor-contract clause snippets. Model clauses for audit rights, sub-outsourcing, data protection, continuity and exit assistance.
• Incident-report form template. A structured template capturing the minimum data fields for initial, intermediate and final reports.
• ICT asset and criticality register. A template linking assets to business functions, dependencies and criticality scores.
• Register of information. A template for recording all ICT third-party contractual arrangements, aligned to the format specified in the DORA implementing standards.

Conclusion

DORA compliance Poland in 2026 is defined less by new legal text than by the demand for demonstrable, evidenced resilience across ICT risk management, incident reporting, testing and third-party oversight. For payment and e‑money institutions, the winning approach is a board-owned framework supported by a living asset register, a rehearsed incident playbook, DORA-aligned contracts and a proportionate testing programme, all assembled into a supervisory-ready evidence pack. Working through a disciplined 90/180/365-day roadmap, with clear owners across compliance, security, legal and procurement, turns DORA from a regulatory risk into an operational strength. Entities that treat DORA compliance Poland as a continuous, evidence-first discipline will not only satisfy KNF scrutiny but also build genuine operational resilience into their payment and e‑money businesses.

Sources

1. Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA), EUR-Lex
2. European Commission, Digital Operational Resilience for the Financial Sector (DORA)
3. European Banking Authority
4. Directive (EU) 2015/2366 (PSD2), EUR-Lex
5. Directive (EU) 2022/2555 (NIS2 Directive), EUR-Lex
6. Komisja Nadzoru Finansowego (KNF), Polish Financial Supervision Authority
7. ISAP, Internet System of Legal Acts (Act on Payment Services / ustawa o usługach płatniczych)