Cyber incident reporting obligations for Polish entities

A Warsaw-based e-commerce company suffers a ransomware attack on a Tuesday evening. By Wednesday morning, management faces three simultaneous clocks: a 24-hour preliminary notification window, a 72-hour GDPR deadline, and a sector-specific reporting obligation under the national cybersecurity framework. Missing any one of them can trigger personal liability for board members and fines reaching into the millions of zlotys. The question is not whether to report – it is how, to whom, and in what sequence.

Polish entities subject to cybersecurity law must report significant incidents to the Computer Security Incident Response Team (CSIRT) at the national level within 24 hours of detection, with a full incident report due within 72 hours. Operators of essential services and digital service providers carry the heaviest obligations under the ustawa o krajowym systemie cyberbezpieczeństwa (Act on the National Cybersecurity System, KSC Act). Parallel obligations under the General Data Protection Regulation (GDPR) and, for financial entities, the Digital Operational Resilience Act (DORA) apply simultaneously and cannot substitute for one another.

This guide walks through the reporting procedure step by step: who qualifies as an obligated entity, which incidents cross the notification threshold, the precise timeline, the costs of non-compliance, common procedural mistakes, and how three different business scenarios play out in practice. Each section includes a concrete figure – a deadline, a threshold, or a financial exposure – so that legal and compliance teams can build an internal response matrix around real parameters.

Who must report – and to which authority?

The KSC Act establishes a tiered system of obligated entities. Operators of essential services (OES) – covering energy, transport, banking, healthcare, water, and digital infrastructure – carry the most demanding obligations. Digital service providers (DSPs), meaning online marketplaces, online search engines, and cloud computing services, form a second tier. A third category covers public entities. Each tier reports to a designated sector-specific CSIRT: CSIRT GOV (operated by the Internal Security Agency, ABW), CSIRT NASK (operated by the Research and Academic Computer Network, NASK), or CSIRT MON (operated by the Ministry of National Defence).

Determining which CSIRT receives your report is not a formality. It depends on sector classification confirmed through the National Court Register (KRS) activity codes and a formal designation decision issued by the competent minister. An energy company reports to CSIRT GOV. A cloud provider reports to CSIRT NASK. Sending a report to the wrong CSIRT – a surprisingly common error – does not suspend the reporting clock. The deadline runs from detection, not from the moment the correct authority is identified.

Financial entities face an additional layer. Under DORA compliance requirements, which became directly applicable across the EU in January 2025, banks, investment firms, and insurance companies supervised by the Polish Financial Supervision Authority (KNF) must also notify the KNF of major ICT-related incidents within the DORA-specific timeline. That timeline differs from the KSC Act window. Running both procedures simultaneously requires a coordinated internal response – not two separate teams working in isolation.

For entities processing personal data, the Personal Data Protection Office (UODO) enters the picture whenever the incident constitutes a personal data breach under GDPR Poland rules. The UODO notification must arrive within 72 hours of becoming aware of the breach. "Becoming aware" is interpreted strictly: internal escalation to a responsible officer starts the clock, not the moment a board member learns of the incident.

What triggers the reporting obligation?

Not every security event is a notifiable incident. The KSC Act threshold for OES is a "significant incident" – one that has an actual adverse effect on the continuity of the essential service. Severity is assessed against sector-specific thresholds set by the competent minister. For DSPs, the threshold is an incident with a substantial impact on the provision of the digital service, measured against parameters including the number of users affected, the geographic spread, and the duration of the disruption. An incident affecting fewer than 1,000 users for under one hour may fall below the DSP threshold; one affecting a payment processing platform for six hours almost certainly does not.

Three categories of event recur most frequently in practice. First, ransomware attacks that encrypt operational systems and halt service delivery. Second, data exfiltration incidents where personal or commercially sensitive data leaves the organisation's control. Third, distributed denial-of-service (DDoS) attacks that breach contractual uptime thresholds. All three typically satisfy both the KSC Act significant-incident test and the GDPR breach test simultaneously – triggering parallel reporting obligations to different authorities on different timelines.

A common misconception is that an incident must be "confirmed" before reporting is required. Polish law does not demand certainty. The KSC Act requires reporting when there are reasonable grounds to believe a significant incident has occurred. Waiting for a forensic report before notifying CSIRT is one of the most frequently cited compliance failures in KNF and UODO enforcement practice. The 24-hour preliminary notification can and should be submitted with incomplete information, updated as facts emerge.

Entities should also consider the AI Act Poland dimension. Systems classified as high-risk AI under the EU AI Act that experience a serious incident – including unexpected behaviour affecting safety – carry their own incident-reporting channel to the market surveillance authority. This obligation sits alongside, not instead of, the KSC Act and GDPR requirements.

What is the step-by-step reporting procedure and timeline?

Hour zero begins at detection – meaning the moment an internal system, employee, or third-party alert first flags the event to a responsible person within the organisation. From that point, the following sequence applies under Polish cybersecurity law.

• Within 24 hours: Submit a preliminary notification to the designated CSIRT. The notification must include the nature of the incident, affected systems, and estimated impact. It need not be complete.
• Within 72 hours: Submit a full incident report to CSIRT, and – if personal data is involved – a GDPR breach notification to UODO. For DORA-regulated entities, the initial notification to KNF also falls within this window.
• Within 30 days: Submit a final incident report to CSIRT, including root-cause analysis, remediation measures taken, and residual risk assessment.
• Ongoing: Maintain an incident log for at least five years, available for inspection by the competent authority.

The CSIRT portal accepts notifications electronically. OES entities must have a registered point of contact maintained in the CSIRT system at all times – failure to keep this registration current is itself a separate administrative violation, carrying fines of up to PLN 150,000. The point-of-contact registration must be renewed annually.

We secured a reversal of an administrative penalty exceeding PLN 300,000 for a manufacturing client in the Mazowieckie region (autumn 2025). The original penalty had been imposed for late CSIRT notification. The reversal turned on demonstrating that the client's internal escalation procedure had been triggered within 24 hours, even though the formal CSIRT submission arrived at hour 26 – a marginal delay attributable to a system outage at the CSIRT portal itself.

The parallel GDPR notification to UODO follows a separate electronic form. Where the breach is unlikely to result in a risk to individuals' rights and freedoms, notification may not be required – but that assessment must be documented contemporaneously. Undocumented "no-notification" decisions are treated as failures to assess, not as valid exemptions.

What are the costs and consequences of non-compliance?

The financial exposure under Polish cybersecurity law is substantial and, critically, personal. Administrative fines for OES under the KSC Act reach PLN 1,000,000 per violation. For DSPs, the ceiling is PLN 200,000. These are per-violation figures – a single incident generating three separate reporting failures (missed 24-hour window, missed 72-hour report, inadequate final report) can produce three separate fines. GDPR fines imposed by UODO are capped at EUR 10,000,000 or 2% of global annual turnover for procedural breaches, and EUR 20,000,000 or 4% for substantive ones. Whichever is higher applies.

Board members face personal liability where they can be shown to have known of the incident and failed to ensure timely reporting. Polish corporate legislation allows the supervisory board or shareholders to pursue recourse claims against management. In practice, enforcement actions increasingly name individual directors alongside the corporate entity – a pattern visible in UODO decisions from 2024 and 2025. This risk is irreversible once enforcement proceedings are opened: a settlement offer does not erase the record.

Our team obtained interim protective measures for a German investor's subsidiary in Lower Silesia (spring 2026) after a competitor attempted to exploit a publicly disclosed incident to challenge the client's operating licence. The incident had been reported correctly and on time. That compliance record became the decisive argument before the licensing authority, demonstrating that timely reporting is not merely a legal obligation – it is a business asset.

Reputational exposure compounds the financial risk. Under the KSC Act, competent authorities may publish information about significant incidents and the entities affected. There is no opt-out. Entities that self-report promptly and demonstrate a credible remediation plan consistently receive more favourable treatment in enforcement decisions than those whose non-compliance is discovered through third-party reports or media coverage. Speed of reporting and quality of the remediation narrative are the two variables most within a company's control.

How do three business scenarios play out in practice?

Understanding the abstract framework matters less than knowing how it applies to your specific situation. Three scenarios illustrate the most common compliance challenges.

Scenario 1 – Manufacturing OES. A steel manufacturer designated as an operator of essential services in the energy sector suffers a cyberattack on its industrial control systems. The attack does not immediately halt production, but it compromises the integrity of monitoring data. The 24-hour clock starts at the moment the IT security team flags the anomaly – not when management confirms the attack vector. The manufacturer must notify CSIRT GOV within 24 hours, submit a full report within 72 hours, and assess whether operational technology (OT) data qualifies as personal data triggering a parallel UODO notification. It almost never does – but the assessment must be documented. The 30-day final report must include a root-cause analysis covering OT-specific vulnerabilities. Failure to address OT separately from IT in the report is a recurring deficiency cited by ABW inspectors.

Scenario 2 – IT services company. A Warsaw-based software-as-a-service provider serving clients across the EU experiences a data breach affecting 15,000 user accounts. The provider qualifies as a DSP under the KSC Act and as a data controller under GDPR. Two parallel tracks open simultaneously: a DSP incident report to CSIRT NASK (24-hour preliminary, 72-hour full report) and a personal data breach notification to UODO (72-hour window). The provider must also assess whether any of its clients – who may themselves be OES entities – must be notified as data processors under GDPR. Processor-to-controller notification obligations do not suspend the controller's own UODO deadline. For guidance on protecting the underlying IP assets involved, see our analysis of trade secret protection strategies under Polish law.

Scenario 3 – Foreign investor's Polish subsidiary. A German group's Polish subsidiary operates a payment platform supervised by KNF. A DDoS attack causes two hours of service unavailability. Three reporting tracks open: KSC Act notification to CSIRT NASK (DSP tier), DORA major-incident notification to KNF, and a GDPR assessment (likely no notification required if no personal data was compromised, but the assessment must be documented). The German parent company's own incident response team may apply different timelines based on German NIS2 implementation. Polish law governs the Polish subsidiary's obligations regardless of group policy. For context on how foreign investors structure their Polish operations, the guide on IP protection strategy for Ukraine tech companies in Poland addresses parallel multi-jurisdictional compliance challenges in the Polish market.

A useful cross-reference for any entity involved in physical infrastructure projects: the spatial planning and zoning rules in Poland guide addresses regulatory procedures that intersect with data centre and critical infrastructure siting decisions – a relevant consideration when assessing where incident-response infrastructure is physically located.

What should your incident response checklist include?

An effective incident response plan reduces the time between detection and first CSIRT notification. The following items represent the minimum preparatory framework for any obligated entity.

• CSIRT designation confirmed: Know in advance whether your sector maps to CSIRT GOV, CSIRT NASK, or CSIRT MON. Confirm annually, especially after changes to business activity.
• Point-of-contact registration current: Verify that the CSIRT portal registration is active and that the named contact is reachable 24/7. Registration lapses are fined separately.
• Incident severity matrix documented: Define in writing which internal events cross the "significant incident" threshold for your sector. The matrix should be approved by the board.
• Parallel notification workflow mapped: Assign separate owners for CSIRT notification, UODO notification, and – where applicable – KNF DORA notification. No single person should own all three.
• Evidence preservation protocol active: Logs, system snapshots, and communication records must be preserved from the moment of detection. Overwritten logs are the most common reason enforcement penalties are not reduced on appeal.

The checklist should be tested through a tabletop exercise at least once per year. Polish cybersecurity law does not mandate exercises, but regulators consistently treat documented exercise history as a mitigating factor in enforcement decisions. A one-day tabletop exercise costs far less than the minimum PLN 200,000 DSP fine.

Entities with trademark or IP assets should also consider the intersection of cyber incidents with IP lawyer Warsaw engagements: a breach that exposes source code or trade secrets may simultaneously trigger obligations under the Act on Combating Unfair Competition and require protective measures beyond the cybersecurity reporting framework.

Frequently asked questions

Q: Does a ransomware attack always require notification to UODO, even if no personal data was accessed?

A: Not automatically. The GDPR notification obligation to UODO arises only if the incident constitutes a personal data breach – meaning personal data was accessed, disclosed, lost, or destroyed without authorisation. A ransomware attack that encrypts data but where there is no evidence of exfiltration may not trigger the UODO notification, provided a documented risk assessment concludes that the breach is unlikely to result in a risk to individuals. That assessment must be completed and recorded within 72 hours of becoming aware of the breach. An undocumented "no-notification" decision is treated as a failure to assess, not a valid exemption. The KSC Act notification to CSIRT, however, is assessed independently and may still be required even where UODO notification is not.

Q: How much does it cost to comply with incident reporting obligations, and what are the main cost drivers?

A: The direct costs of compliance are modest relative to the fines for non-compliance. Maintaining CSIRT portal registration, preparing the incident response plan, and running an annual tabletop exercise typically cost between PLN 20,000 and PLN 80,000 per year for a mid-sized entity, depending on complexity. The significant cost drivers are forensic investigation (typically PLN 50,000 to PLN 300,000 per incident), legal advice on parallel notification obligations, and remediation of the underlying vulnerability. By contrast, the minimum administrative fine for a missed KSC Act notification is PLN 15,000 for a DSP; for an OES the practical starting point in enforcement decisions has been PLN 100,000 or more. Investing in preparedness consistently produces a better return than managing enforcement proceedings after the fact.

Q: Can a Polish entity rely on its EU parent company's incident notification to satisfy Polish reporting obligations?

A: No. Polish cybersecurity law imposes obligations on the Polish entity as a legal person registered in Poland. A notification submitted by the EU parent to a foreign CSIRT or data protection authority does not fulfil the Polish entity's separate obligations to CSIRT NASK, CSIRT GOV, UODO, or KNF. The Polish subsidiary must submit its own notifications through the Polish reporting channels, within the Polish statutory deadlines. Group incident response policies that centralise notification at parent level – without a parallel Polish track – are a common source of compliance failures identified during KNF and UODO inspections. Each Polish entity in a group should have its own designated incident response coordinator with authority to submit notifications independently.

For a tailored strategy on cyber incident reporting compliance, reach out to info@kordeckipartners.com.

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, IP protection, and technology regulation. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating multi-layered reporting obligations under the KSC Act, GDPR, DORA, and the AI Act. 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.