Cyber incident reporting obligations for Polish

A Warsaw-based fintech company suffers a ransomware attack on a Friday evening. By Monday morning, its legal team faces three simultaneous reporting deadlines – each governed by a different statute, directed to a different authority, and carrying a different consequence for missing the window. The complexity is not theoretical. It is the daily reality for Polish entities operating under layered cybersecurity and data protection obligations.

Polish entities subject to cybersecurity incidents must report to multiple regulators under parallel legal frameworks. The primary instrument is the ustawa o krajowym systemie cyberbezpieczeństwa (Act on the National Cybersecurity System, KSC Act), which requires operators of essential services and digital service providers to notify the national CERT within 24 hours of detecting a significant incident. Separately, GDPR Poland obligations require notification to the President of the Personal Data Protection Office (UODO) within 72 hours when personal data is affected. Entities covered by DORA compliance rules face an additional layer of financial sector-specific reporting.

This page maps those obligations in practical terms. It covers the regulatory architecture, the key deadlines, the most common pitfalls, cross-border considerations, and a self-assessment checklist. Where the frameworks overlap – which is more often than most compliance teams expect – the interaction between them creates the greatest legal risk.

What is the Polish cybersecurity reporting framework?

The foundation is the KSC Act, which transposed the original EU Network and Information Security (NIS) Directive into Polish law. The National Court Register (KRS) records the legal form of entities, but it is the sectoral designation by the relevant ministry that determines whether an entity qualifies as an operator of essential services. That designation triggers the most demanding obligations. The Polish Financial Supervision Authority (KNF) adds a further layer for financial institutions through its own guidelines and, since January 2025, through DORA.

The KSC Act divides regulated entities into three categories. First, operators of essential services – companies in energy, transport, banking, health, water, and digital infrastructure. Second, digital service providers – online marketplaces, cloud computing services, and search engines. Third, from the NIS2 transposition (still pending full legislative implementation as of early 2026), a broader set of "important" and "essential" entities covering manufacturing, postal services, and public administration. Each category carries distinct thresholds and timelines.

Alongside the KSC Act, three other instruments matter. GDPR Poland rules (enforced by UODO) govern personal data breaches independently of whether the incident is also a cybersecurity event. The DORA compliance regulation applies to financial entities and their critical ICT third-party providers from 17 January 2025. The AI Act Poland provisions, while focused on risk management rather than incident reporting as such, intersect where AI systems cause or amplify a security incident. Understanding which framework applies – and whether multiple frameworks apply simultaneously – is the first analytical step.

One concrete figure anchors the framework: the 24-hour initial notification window under the KSC Act for significant incidents. That clock starts not at the moment of the breach but at the moment the entity detects it. Detection management therefore becomes a legal issue, not merely a technical one.

When do reporting obligations actually trigger?

The trigger question is more precise than it appears. Not every security event is a "significant incident" under the KSC Act. The statute defines significance by reference to impact on service continuity, affected user numbers, and geographic spread. An entity must assess impact against its own baseline – a threshold that the Computer Security Incident Response Team (CERT Polska), operating under the Research and Academic Computer Network (NASK), can assist in calibrating through its published guidance.

For GDPR Poland purposes, the trigger is different: a personal data breach that is "likely to result in a risk to the rights and freedoms of natural persons." That standard is lower than many compliance teams assume. A ransomware attack that encrypts personal data – even without confirmed exfiltration – typically meets it. UODO has taken the position that encryption of personal data constitutes a breach regardless of whether data was actually accessed by the attacker. The 72-hour window then runs from when the data controller becomes "aware" of the breach.

DORA compliance introduces a third trigger: a "major ICT-related incident" affecting a financial entity's critical functions. The definition turns on criteria including duration, service impact, geographic scope, and data loss. DORA sets a 4-hour initial notification deadline to the KNF once an incident is classified as major – followed by an intermediate report within 72 hours and a final report within one month. That three-stage structure is unique among the frameworks and requires dedicated internal workflows.

We secured a favourable outcome for a payment institution in the Mazowieckie region (autumn 2025), where our team successfully argued that an ICT disruption did not meet the DORA "major incident" threshold, avoiding a formal KNF enforcement inquiry and the reputational exposure that would have followed.

KSC Act: 24-hour initial notification to CERT Polska for significant incidents
GDPR / UODO: 72-hour notification for personal data breaches posing risk to individuals
DORA: 4-hour initial notification, 72-hour intermediate, 30-day final report to KNF
Sector-specific: additional timelines may apply in energy, telecoms, or health sectors

The interaction between frameworks is where liability concentrates. An entity that correctly reports under GDPR but fails to notify CERT Polska for the same incident faces enforcement from two separate directions. Personal liability for management board members arises where the failure is attributable to inadequate internal governance – a consequence that precludes the company from absorbing the risk alone.

What are the most common compliance pitfalls?

The first pitfall is scope misidentification. Many Polish entities – particularly mid-sized manufacturers and logistics companies – do not know whether they have been formally designated as operators of essential services. The designation is made by the relevant minister and communicated to the entity directly, but turnover in compliance teams means the original designation letter is sometimes lost or ignored. Operating under an active designation without implementing the required incident response procedures exposes management to fines of up to PLN 1 million under the KSC Act.

The second pitfall is the "wait and see" approach to notification. Legal teams sometimes delay reporting while conducting internal forensic investigations, hoping to present a complete picture to the regulator. Both CERT Polska and UODO have made clear that the initial notification need not be complete – it must be timely. The 24-hour and 72-hour windows are hard deadlines. A partial but timely notification is always preferable to a thorough but late one. Late notification forfeits the procedural benefit of voluntary disclosure and typically results in a more adversarial regulatory posture.

The third pitfall involves third-party and supply-chain incidents. Under the KSC Act, the reporting obligation falls on the operator of essential services, not on its ICT supplier. If a cloud provider suffers a breach that affects the operator's systems, the operator's 24-hour clock starts when it becomes aware – regardless of when the supplier notified it. Contractual clauses requiring suppliers to notify within 12 hours of detection are therefore a practical necessity, not a formality. DORA compliance makes this explicit for financial entities: critical ICT third-party providers must be contractually bound to incident notification timelines.

For entities with trademark-sensitive or IP-heavy operations, a cyber incident that exposes trade secrets or confidential licensing data may also trigger obligations under separate IP protection frameworks. Our guidance on IP protection strategy for US tech companies in Poland addresses how those exposures interact with cybersecurity obligations in practice.

The fourth pitfall is inadequate documentation. Regulators – UODO in particular – assess not only whether a notification was filed but whether the entity's internal assessment was reasonable and documented. An undocumented decision not to notify is treated as a failure to assess. A documented decision not to notify, supported by a written risk assessment, is treated as a substantive compliance choice that the regulator may disagree with but cannot characterise as negligence per se.

How do cross-border operations affect Polish reporting obligations?

Cross-border complexity arises in two distinct directions. First, a Polish entity with operations in other EU member states may face simultaneous reporting obligations in multiple jurisdictions. The NIS2 Directive, which Poland is transposing into national law, introduces a "main establishment" concept that partially centralises reporting – but that mechanism is not yet fully operational under Polish implementing legislation as of early 2026. Until it is, Polish entities must comply with Polish law even where they have already notified a lead supervisory authority in another member state.

Second, foreign entities operating in Poland through subsidiaries or branches are subject to Polish KSC Act obligations if their Polish operations meet the designation criteria. A German investor whose Polish subsidiary qualifies as an operator of essential services cannot rely on group-level incident response procedures based in Frankfurt. Polish law requires a locally designated security officer and locally maintained incident response documentation. The KNF, for financial entities, expects Polish-law-compliant procedures regardless of where the group's global CISO sits.

Data transfer obligations add another dimension. Where a cyber incident involves personal data that was being transferred cross-border – for example, under standard contractual clauses to a French data processor – the breach notification must account for the transfer mechanism and the obligations of both controller and processor. Our analysis of data transfer from Poland to France: legal mechanisms examines how those obligations interact with GDPR Poland enforcement in practice.

We assisted a Silesian manufacturing group (spring 2026) in coordinating simultaneous notifications to CERT Polska, UODO, and the German Federal Office for Information Security (BSI) following a supply-chain compromise affecting both its Polish and German operations. Aligning the three notification timelines without creating contradictory disclosures required careful sequencing – a problem that standard group incident response playbooks rarely anticipate.

Enforcement proceedings that arise from cross-border incidents may also involve arbitration or commercial litigation where asset protection measures are relevant. Our guidance on enforcing arbitral awards in Poland covers the procedural mechanisms that become relevant when cross-border disputes follow a major incident.

The AI Act Poland dimension is emerging but real. AI systems classified as high-risk must be monitored for serious incidents. Where a cybersecurity event compromises an AI system's integrity or causes unexpected behaviour, the AI Act's incident logging and reporting obligations may apply in addition to the KSC Act and GDPR frameworks. IP lawyer Warsaw-based practices are already seeing early-stage inquiries on this intersection.

What practical steps should Polish entities take now?

The starting point is a regulatory mapping exercise. An entity must identify all frameworks that apply to it – KSC Act designation status, GDPR controller or processor status, DORA applicability, and any sector-specific rules. That mapping exercise should be completed before an incident occurs, not during one. Entities that attempt to determine their obligations in the middle of a live incident consistently make worse decisions and miss more deadlines.

Incident response procedures must be documented and tested. CERT Polska's published guidance recommends tabletop exercises at least once per year. For DORA compliance, financial entities are required to test their ICT business continuity plans. The documentation must name the individuals responsible for each notification decision, specify the escalation path, and include pre-drafted notification templates for each regulator. A 24-hour deadline does not accommodate drafting from scratch.

Supplier contracts require specific attention. Every material ICT supplier should be subject to a contractual incident notification obligation with a window shorter than the entity's own regulatory deadline – typically 8 to 12 hours. The contract should also specify what information the supplier must provide, in what format, and to which contact within the entity. DORA compliance requires financial entities to include these provisions in contracts with critical third-party providers; best practice extends them to all significant ICT relationships.

What to prepare – self-assessment checklist:

Regulatory mapping: confirm KSC Act designation status, DORA applicability, and GDPR role (controller/processor)
Internal procedures: documented incident response plan with named owners and pre-drafted notification templates
Supplier contracts: notification clauses with sub-24-hour windows and specified information requirements
Testing: annual tabletop exercise and, for DORA entities, ICT continuity test results on file
Documentation: written risk assessments for all decisions not to notify, retained for at least 5 years

Board-level governance is the final element. Management board members in Polish limited liability companies (spółki z ograniczoną odpowiedzialnością) and joint-stock companies (spółki akcyjne) face personal liability where cybersecurity failures are attributable to inadequate oversight. Fines under the KSC Act reach PLN 1 million for operators. UODO can impose administrative fines up to EUR 10 million or 2% of global annual turnover under GDPR. Those figures are not abstract – they represent an irreversible consequence of governance failure that the board cannot subsequently correct.

Specific situations require tailored assessment. Every entity's exposure depends on its designation, sector, data processing activities, and third-party relationships. Generic checklists identify the issues; they do not resolve them.

To receive an expert assessment of your entity's cyber incident reporting obligations under Polish law, contact info@kordeckipartners.com.

Frequently asked questions

Q: Does a Polish company need to report a cyber incident if no personal data was accessed?

A: Yes – potentially under two separate frameworks. The KSC Act reporting obligation applies to significant incidents affecting service continuity, regardless of whether personal data is involved. A ransomware attack that encrypts systems and disrupts operations may trigger KSC Act notification to CERT Polska even if the company processes no personal data at all. GDPR Poland notification to UODO is a separate question that turns on whether personal data was affected. The two analyses must be conducted independently.

Q: How long does the initial KSC Act notification have to be, and what must it include?

A: The 24-hour initial notification to CERT Polska does not need to be complete. It must identify the entity, describe the incident in general terms, indicate the affected services, and provide a contact point. A more detailed report follows within 72 hours. CERT Polska's notification portal accepts submissions electronically. The critical point is timing: a brief, timely initial notification is legally preferable to a detailed but late one. Entities that wait for forensic results before notifying typically face a more adversarial regulatory response.

Q: Does DORA compliance apply to all Polish companies, or only banks?

A: DORA applies to a broad range of financial entities – not only banks. The regulation covers credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, and others. It also applies to critical ICT third-party providers that serve those entities, even if the provider itself is not a financial entity. A Polish software company that provides core banking infrastructure to a bank may therefore face DORA obligations indirectly. The KNF supervises compliance for Polish-domiciled entities in scope.

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 cybersecurity compliance, incident reporting, DORA, GDPR Poland, and AI Act readiness. We work with Polish entrepreneurs, foreign investors, and in-house legal teams. To discuss your situation, contact info@kordeckipartners.com.