Cyber incident reporting obligations for Polish

A Warsaw-based fintech company suffers a ransomware attack on a Tuesday evening. By Wednesday morning, the chief executive is asking one question: who do we notify, and how quickly? The answer depends on at least three overlapping regulatory regimes – and getting it wrong forfeits both the protection of early notification and the goodwill of regulators who reward prompt disclosure.

Polish entities subject to cybersecurity law must report significant incidents to the Computer Security Incident Response Team (CSIRT NASK, CSIRT GOV, or a sector-specific CSIRT) within 24 hours of detection, with a full incident report due within 72 hours. The obligation derives from the Act on the National Cybersecurity System (ustawa o krajowym systemie cyberbezpieczeństwa, KSC Act), which transposes the NIS Directive and is currently being updated to align with NIS2. Parallel obligations exist under GDPR Poland rules, the Digital Operational Resilience Act (DORA), and sector-specific regulations issued by the Polish Financial Supervision Authority (KNF).

This service page explains the full framework: which regimes apply, who must report to whom, what the deadlines are, and where companies most often lose ground by acting too slowly or filing incomplete notifications. Each section opens with the direct answer so that in-house counsel can assess their position immediately.

Which legal regimes govern cyber incident reporting in Poland?

Polish cyber incident reporting sits at the intersection of four distinct bodies of law. The KSC Act is the primary instrument. It designates operators of essential services (OES) across energy, transport, banking, healthcare, digital infrastructure, and water supply, and imposes structured notification duties on each. Digital service providers (DSPs) – cloud platforms, online marketplaces, search engines – face parallel obligations. The KSC Act is currently being amended to implement NIS2; the draft amendment before the Polish parliament extends scope to a much wider category of "important entities" and introduces stricter timelines.

GDPR Poland obligations layer on top. Any incident involving personal data triggers a separate notification to the President of the Personal Data Protection Office (Urząd Ochrony Danych Osobowych, UODO) within 72 hours of the controller becoming aware. The UODO notification is independent of the CSIRT report. Companies handling both operational and personal data – which is almost every commercial entity – must therefore run two parallel processes simultaneously.

DORA compliance adds a third stream for financial entities. From January 2025, banks, insurers, investment firms, and payment institutions supervised by the KNF must report major ICT-related incidents through a dedicated template to the KNF, which then forwards reports to the European Banking Authority, ESMA, or EIOPA depending on entity type. The DORA reporting timeline is 4 hours for initial notification of a major incident, with an intermediate report within 72 hours and a final report within one month.

KSC Act OES: 24-hour initial alert, 72-hour incident report, monthly summary
GDPR / UODO: 72-hour personal data breach notification
DORA (KNF-supervised entities): 4-hour initial, 72-hour intermediate, 30-day final
Sector-specific rules: telecommunications, energy, and nuclear sectors carry additional duties
NIS2 implementation (pending): broader scope, stricter timelines, personal liability for management

We helped a payment institution in Mazowieckie region (spring 2026) map all four regimes against a single credential-stuffing incident. The overlap meant five separate reporting tracks within the first 72 hours. Early legal involvement – before the technical team began drafting notifications – reduced the risk of inconsistent filings that could later be used against the client in supervisory proceedings.

What are the specific reporting deadlines and thresholds?

Deadlines vary by regime and by the severity classification of the incident. Under the KSC Act, an OES must send an early warning to its sector CSIRT within 24 hours of detecting a significant incident. "Significant" means an incident with a substantial impact on the continuity of the essential service – a threshold assessed by reference to the number of users affected, the duration, and the geographic spread. The full incident report follows within 72 hours and must include a preliminary root-cause assessment.

The DORA timeline is more demanding for financial entities. The 4-hour initial notification clock starts from the moment the entity classifies the incident as "major" under DORA's own criteria – which include the number of clients affected, the transaction volume disrupted, and the reputational impact. Missing the 4-hour window does not automatically trigger a fine, but the KNF treats late notification as an aggravating factor in any supervisory review. The maximum administrative penalty under DORA for a financial institution can reach EUR 5 million or 2% of total annual worldwide turnover.

For GDPR purposes, the 72-hour clock begins when the data controller becomes "aware" of a breach – a term the UODO interprets broadly. Becoming aware does not require certainty; a reasonable belief that personal data has been compromised is sufficient. Failing to notify UODO within 72 hours exposes the controller to fines of up to EUR 10 million or 2% of global annual turnover under GDPR, and personal liability risks for the data protection officer if the delay was caused by internal process failures.

One common misconception: many companies believe the 72-hour GDPR clock starts only after forensic confirmation of a breach. It does not. The UODO's practice is consistent with European Data Protection Board guidance – awareness begins when the controller's staff first identified an anomaly that could constitute a breach. Waiting for a forensic report before filing forfeits the partial protection that an early, good-faith notification provides.

How should Polish entities structure their internal incident response process?

Structure matters as much as speed. An entity that notifies regulators within 4 hours but submits a notification that is internally inconsistent – for example, citing a different attack vector in the CSIRT report than in the UODO notification – creates a documentary record that supervisors can exploit. The internal process must produce a single factual narrative that feeds all external reports.

The recommended structure has three phases. First, a detection-and-classification phase (target: under 2 hours). This involves the security operations team, the data protection officer, and legal counsel working in parallel to assess scope, classify severity under each applicable regime, and identify which notification tracks are triggered. Second, a drafting phase (target: under 4 hours from classification). Legal counsel coordinates notification content to ensure consistency. Third, a submission and monitoring phase: filings are sent, acknowledgements are retained, and the incident log is preserved for at least five years under KSC Act requirements.

The AI Act Poland framework adds a further consideration for entities deploying high-risk AI systems in critical infrastructure. Where a cyber incident affects a high-risk AI system, the incident may also trigger notification obligations under the AI Act's market surveillance provisions. Our article on AI Act high-risk classification, affected sectors and systems sets out which deployments fall within scope.

What to prepare before an incident occurs:

Incident response plan specifying which regime applies to each system
Pre-drafted notification templates for CSIRT, UODO, and KNF
Defined escalation chain with named individuals for each reporting track
Documented classification criteria aligned with KSC Act, DORA, and GDPR thresholds
Retained outside counsel contact available on a 24-hour basis

For entities that also operate a whistleblower channel – which is mandatory for employers with 50 or more employees under Polish whistleblower legislation – a cyber incident affecting that channel triggers additional obligations. Our guide on whistleblower channel design and technical requirements explains the overlap between data security and channel integrity obligations.

To receive an expert assessment of your incident response readiness, contact info@kordeckipartners.com

Your entity's specific configuration – the combination of regulated status, data types processed, and AI systems deployed – determines which reporting tracks are active. Missing even one track creates an irreversible gap in your regulatory record that supervisors retain for future enforcement decisions.

What are the cross-border complications for multinational groups?

Polish subsidiaries of foreign groups face a structural tension. The parent company's global incident response process is designed for the jurisdiction of the group's headquarters – typically Germany, the Netherlands, or the United States. That process almost never maps cleanly onto Polish KSC Act timelines. The result: the Polish entity is legally required to notify CSIRT NASK within 24 hours, but the parent's process requires board approval before any external communication. The two are irreconcilable without advance planning.

For EU-headquartered groups, the NIS2 coordination mechanism offers partial relief. Where a group incident crosses borders, the lead NIS2 authority in the member state of the group's main establishment coordinates with the Polish Computer Emergency Response Team. But this mechanism does not suspend the Polish 24-hour clock. The Polish entity must still file its own early warning on time, even if the group-level coordination process is ongoing.

For US-headquartered groups, the gap is wider. The US Securities and Exchange Commission's cyber disclosure rules and the Polish KSC Act operate on entirely different frameworks. Our cross-practice team – including colleagues who advise on technology law in the United States, detailed at our US IP and tech practice page – regularly helps groups align Polish and US notification obligations into a single coordinated response. The key insight: US counsel and Polish counsel must draft their respective notifications from the same factual core, prepared by the technical team before either legal team begins drafting.

We obtained a favourable supervisory outcome for a German investor's Polish subsidiary in Lower Silesia (autumn 2025) after a supply-chain attack affected both the Polish OES designation and the parent's DORA-regulated financial arm. Coordinating three regulators – CSIRT GOV, the KNF, and the German BSI – within a 72-hour window required pre-existing relationships and a pre-drafted coordination protocol. Entities that attempt this coordination for the first time during an active incident almost always miss at least one deadline.

What pitfalls most commonly result in supervisory sanctions?

Supervisory sanctions in the cyber incident space rarely arise from the incident itself. They arise from the response. The KSC Act empowers the competent authority to impose fines of up to PLN 1 million on OES operators for failure to report incidents within the required timeframe. The UODO can impose GDPR fines independently. The KNF can impose DORA penalties on top of both. In theory, a single incident could generate three separate administrative fines from three separate authorities.

The most common pitfall is classification delay. An entity detects an anomaly, assigns it to the IT team for investigation, and waits for a definitive technical finding before involving legal counsel. By the time legal counsel is engaged, the 4-hour DORA window has passed and the 24-hour KSC window is closing. The entity then files a late notification and compounds the problem by describing the incident differently in each filing – because different team members drafted each notification without coordination.

The second pitfall is under-reporting scope. Entities frequently notify regulators of the minimum incident scope visible at the time of initial notification, then fail to file the required updates when the scope expands. Under both DORA and the KSC Act, the obligation to update notifications is mandatory, not discretionary. Failure to update is treated as a separate violation.

The third pitfall involves IP and trademark exposure. A cyber incident that results in the exfiltration of trade secrets or registered trademark data may also trigger obligations under the Act on Combating Unfair Competition and require notification to affected business partners. An IP lawyer Warsaw-based teams consult should be part of the incident response team from the outset, not brought in after the regulatory filings are complete.

A decision matrix for initial classification:

Personal data affected → UODO notification within 72 hours
OES system disrupted → CSIRT notification within 24 hours
KNF-supervised entity → DORA major incident classification within 4 hours
High-risk AI system affected → AI Act market surveillance notification assessment

Entities that delay legal involvement until after technical containment forfeit the ability to shape the regulatory narrative. That opportunity closes permanently once the first notification is filed – and regulators read every subsequent filing against what was said first.

To discuss how the incident reporting framework applies to your entity's specific regulatory status, email info@kordeckipartners.com

Your first notification sets the factual record. If it is incomplete, inconsistent, or late, the supervisory file will reflect that permanently. Early legal involvement is the one step that cannot be recovered after the fact.

Frequently asked questions

Q: Does a Polish entity that is not an operator of essential services still have cyber incident reporting obligations?

A: Yes. Even entities outside the KSC Act's OES and DSP categories must notify UODO within 72 hours of a personal data breach under GDPR. Entities subject to DORA – including payment institutions and smaller investment firms – have independent reporting obligations to the KNF regardless of their KSC Act status. The NIS2 implementation currently before the Polish parliament will also extend KSC Act obligations to a broader category of "important entities," which includes medium and large companies in manufacturing, postal services, and waste management.

Q: How long does the entire DORA reporting cycle take, and what does it cost to manage?

A: The DORA cycle runs from the initial 4-hour notification through the 72-hour intermediate report to the final report due within one month of the incident. Managing the cycle for a complex incident typically requires between 40 and 80 hours of combined legal and compliance effort, depending on the number of affected systems and the number of jurisdictions involved. Entities that have pre-drafted templates and a trained response team reduce that figure significantly. Entities managing the cycle for the first time during a live incident consistently exceed it.

Q: Is it a misconception that GDPR notification to UODO automatically satisfies the KSC Act reporting obligation?

A: Yes, this is a misconception. The UODO notification and the CSIRT notification are submitted to different authorities, under different legal bases, using different templates, and with different information requirements. A GDPR notification does not satisfy the KSC Act obligation, and vice versa. Submitting only one when both are required constitutes a separate violation under each regime. Entities should treat the two processes as parallel tracks that share a common factual foundation but are legally independent.

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 response, and technology regulation. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating DORA compliance, KSC Act obligations, GDPR Poland requirements, and AI Act Poland implementation. To discuss your situation, contact info@kordeckipartners.com.