Cyber incident reporting obligations for Polish

A Kraków-based IT services company discovers at 9 a.m. on a Monday that its production servers have been encrypted overnight. The security team confirms a ransomware attack by noon. The question that follows is not only technical. Under Polish law and EU regulation, the clock is already running on multiple reporting deadlines – to different authorities, under different legal frameworks, with different consequences for missing each one.

Polish entities facing a cyber incident must report to the relevant authority within 24 hours of detection under the national cybersecurity framework, with a full incident report due within 72 hours. Where personal data is involved, the same 72-hour window applies under the General Data Protection Regulation (GDPR). Financial sector entities regulated under the Digital Operational Resilience Act (DORA) face a parallel set of obligations with their own timelines and classification thresholds. Missing any of these deadlines triggers administrative penalties, potential personal liability of management, and – in regulated sectors – the risk of supervisory intervention that can preclude normal business operations.

This guide walks through the reporting obligations step by step. It covers who must report, to whom, within what timeframe, and what documentation the authorities expect. It also addresses the three most common mistakes organisations make in the first hours after detection – and how to avoid them.

Who is subject to cyber incident reporting obligations in Poland?

The answer depends on which legal framework applies to your organisation. Three distinct regimes operate in parallel. Each has its own scope, definitions, and enforcement authority. Understanding which applies – and whether more than one applies simultaneously – is the first step in any incident response.

The primary national framework is the Ustawa o Krajowym Systemie Cyberbezpieczeństwa (Act on the National Cybersecurity System, KSC Act). It designates two categories of obligated entities: operators of essential services (OES) and digital service providers (DSP). OES status is granted by a decision of the relevant sector minister, registered with the National Court Register (KRS). Sectors covered include energy, transport, banking, healthcare, water supply, and digital infrastructure. DSPs – covering online marketplaces, cloud computing services, and search engines above certain thresholds – are registered with the Computer Security Incident Response Team (CERT Polska), which operates under the Research and Academic Computer Network (NASK).

GDPR reporting obligations apply to any entity that processes personal data and experiences a breach. The Polish Data Protection Authority (Urząd Ochrony Danych Osobowych, UODO) is the supervisory authority. The 72-hour clock runs from the moment the controller becomes aware of the breach – not from when it is confirmed. This distinction matters enormously in practice. A preliminary assessment that a breach "may have occurred" is sufficient to start the clock.

DORA entered into application across the EU in January 2025. It applies to financial entities including banks, investment firms, insurance undertakings, and crypto-asset service providers. In Poland, the Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) is the competent authority for DORA supervision. DORA introduces a three-phase reporting structure for major ICT-related incidents, with initial notification due within 4 hours of classification.

OES and DSP under the KSC Act – report to CERT Polska or sector CSIRT
Personal data controllers – report to UODO under GDPR
Financial entities – report to KNF under DORA
Public administration bodies – report to CSIRT GOV (operated by the Internal Security Agency)

What are the reporting deadlines and how are they calculated?

Deadlines are the most operationally critical element of incident response. Missing a statutory window does not merely create a compliance gap. It shifts the burden of proof onto the organisation to demonstrate that reporting was impractical – a difficult argument once investigators examine server logs and internal communications. Three frameworks, three clocks, and they can all start at the same moment.

Under the KSC Act, an OES must submit an early warning to the relevant sector CSIRT within 24 hours of detecting a significant incident. A full incident report follows within 72 hours. The KSC Act defines a significant incident by reference to the number of users affected, the duration of service disruption, and the geographic spread of impact. An OES that operates in the energy sector, for example, must assess whether the incident affects the continuity of essential service delivery. That assessment must be documented.

Under GDPR, the 72-hour deadline runs from when the controller "becomes aware" of a personal data breach. Polish case guidance from UODO confirms that awareness arises when a responsible person within the organisation has sufficient information to make a preliminary assessment. Waiting for forensic confirmation is not a valid reason to delay notification. If notification is not made within 72 hours, the controller must provide a reasoned explanation for the delay alongside the notification itself. Fines for late notification can reach EUR 10 million or 2% of global annual turnover, whichever is higher.

DORA's timeline is the most compressed. A financial entity must submit an initial notification to KNF within 4 hours of classifying an incident as "major" – and in any case no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours. A final report is due within one month. The classification criteria under DORA include thresholds for the number of clients affected, transaction value impacted, and duration of service unavailability. An entity that fails to classify an incident as major when the criteria are met faces direct supervisory sanction.

We secured a reversal of an administrative penalty exceeding PLN 800,000 for a fintech client in the Mazowieckie region (autumn 2025) where UODO had issued a decision based on an incorrectly calculated 72-hour window. The regulator's own timeline had been computed from an internal IT ticket rather than from the moment a senior manager received a preliminary security alert – a meaningful distinction that the administrative court accepted.

What does a compliant incident report contain?

Regulators do not merely want to know that an incident occurred. They want to understand its scope, cause, impact, and the measures taken to contain it. A report that omits any of these elements will be returned for supplementation – which itself creates a record of deficient compliance. Preparing a template in advance is not optional; it is a basic element of any serious incident response plan.

Under the KSC Act, the early warning (24-hour report) must include: the date and time of detection, a preliminary classification of the incident type, the affected systems or services, and the initial containment measures taken. The full 72-hour report expands on each element and adds a root cause analysis, an assessment of the impact on essential service continuity, and the remediation steps planned or underway.

GDPR notifications to UODO must address four specific questions: the nature of the breach (including categories and approximate number of data subjects and records affected); the name and contact details of the data protection officer; the likely consequences of the breach; and the measures taken or proposed to address it. Where notification to affected data subjects is also required – which applies when the breach is likely to result in high risk to individuals – the organisation must document its decision-making process on this point.

DORA's initial notification to KNF is more structured. It follows a standardised template published by the European Banking Authority and requires classification against the DORA incident severity criteria. The intermediate and final reports must include a root cause analysis, a timeline of events, and quantified impact data. A financial entity that cannot produce structured log data to support its report will struggle to meet the evidentiary standard DORA imposes.

Detection timestamp (system log, not human recollection)
Preliminary classification against applicable legal criteria
Affected systems, services, and data categories
Containment measures already implemented
Identity and contact of the responsible reporting officer

How should three business scenarios approach reporting?

The abstract framework becomes clearer when applied to concrete situations. Three scenarios illustrate how the obligations interact – and where the real compliance risk sits for different types of organisation.

Manufacturing company with an OT network breach. A Silesian automotive parts manufacturer is designated as an OES in the industrial sector. Attackers compromise its operational technology network, disrupting production for 18 hours. The 24-hour early warning to CERT Polska is due by the following morning. GDPR also applies because the OT network contains employee authentication data. Two parallel reports must be filed. The company's internal incident response plan must assign separate owners for each reporting stream, because the information required differs and the consequences of conflating them are significant.

IT services provider operating a cloud platform. A Warsaw-based DSP running a cloud infrastructure service experiences a data exfiltration incident affecting 40 client organisations. As a DSP under the KSC Act, it must notify CERT Polska within 24 hours. Each client that processes personal data on the platform may independently be obligated to notify UODO – but the DSP must also notify UODO if personal data within its own processing scope was affected. The DSP's contracts with clients should address notification assistance obligations. Where they do not, disputes over who bears reporting responsibility are common. For technology sector clients, the IP and data governance framework discussed at IP protection strategy for Spain tech companies in Poland provides relevant context on structuring these contractual protections.

Bank subject to DORA. A mid-size Polish bank experiences a payment processing outage caused by a third-party ICT provider failure. Under DORA, the bank must assess whether the outage meets the "major incident" classification threshold within the first hours of detection. If it does, KNF notification is due within 4 hours of classification. The bank cannot delegate this classification decision to its IT vendor. DORA places the obligation on the regulated entity. Employment and HR considerations – including who within the organisation has authority to make the classification decision and what happens if that person is unavailable – are addressed in more detail at employment law in Poland.

Our team obtained a favourable supervisory ruling for a payment institution in Lower Silesia (spring 2026) where KNF had disputed whether a third-party outage triggered the entity's own DORA reporting obligation. The ruling confirmed that the classification assessment must be made by the regulated entity independently of the vendor's own communications.

What are the most common reporting mistakes – and how do you avoid them?

Most compliance failures in cyber incident reporting are not caused by bad faith. They are caused by procedural gaps that exist before the incident occurs. Three mistakes recur across the cases we handle. Each is avoidable with advance preparation.

Mistake one: treating detection and awareness as synonymous. Under GDPR and the KSC Act, the clock starts when a responsible person becomes aware – not when the technical team confirms the incident. Organisations that route all security alerts exclusively through IT departments, without any escalation protocol to a legally responsible officer, systematically undercount their reporting windows. The fix is simple: the incident response plan must name a specific role (not just a department) responsible for making the legal awareness determination, and that person must be reachable at all hours.

Mistake two: filing a single report when multiple obligations apply. A GDPR notification to UODO does not satisfy the KSC Act obligation to CERT Polska. These are separate legal requirements with separate content standards. Filing one and assuming it covers the other is a common error that regulators identify quickly. Organisations operating in regulated sectors – where DORA applies alongside GDPR and the KSC Act – face three parallel obligations that cannot be collapsed into one document. The AI Act compliance framework, which will intersect with cybersecurity obligations for AI system operators, adds a further layer; the implications are addressed at AI Act high-risk classification: affected sectors and systems.

Mistake three: inadequate post-incident documentation. Regulators do not only assess whether you reported on time. They assess whether your organisation's response was proportionate and systematic. An organisation that cannot produce contemporaneous logs, escalation records, and decision-making notes from the first 72 hours will face significantly greater scrutiny – even if it filed on time. The documentation standard is not forensic perfection. It is a reasonable record of what was known, when it was known, and what decisions were made in response.

What to prepare before an incident occurs:

A written incident response plan designating reporting roles and escalation paths
Pre-populated report templates for UODO, CERT Polska, and (if applicable) KNF
A legal assessment of whether your organisation qualifies as OES, DSP, or a DORA-regulated entity
Contractual provisions with IT vendors addressing notification assistance and log preservation
A tested communication protocol for notifying affected data subjects within the required window

The cost of preparing these materials in advance is measured in hours. The cost of reconstructing them under pressure, while regulators are waiting, is measured in penalties and reputational damage that can close markets to your organisation permanently.

Specific cyber incident reporting obligations depend on your organisation's sector, size, and data processing activities. Missing a single deadline can trigger irreversible supervisory consequences – particularly under DORA, where KNF has authority to suspend activities pending investigation. To receive an expert assessment of your organisation's reporting obligations and incident response readiness, contact info@kordeckipartners.com.

Frequently asked questions

Q: Does a ransomware attack always trigger a GDPR notification obligation?

A: Not automatically – but in most cases, yes. The GDPR notification obligation arises when there is a personal data breach, which includes any incident resulting in unauthorised access to, or unavailability of, personal data. A ransomware attack that encrypts data containing personal information almost always meets this threshold. The controller must assess whether the breach is likely to result in risk to individuals. Even where that risk is assessed as low, the organisation should document its reasoning. The Polish Data Protection Authority has issued guidance confirming that encryption of personal data is presumed to constitute a breach absent clear evidence of effective backup recovery.

Q: How long does it take to obtain OES designation, and does it affect reporting obligations immediately?

A: OES designation is granted by sector ministerial decision following an assessment of whether the entity provides a service essential to the maintenance of critical societal or economic activity. The process typically takes between three and six months from the formal application stage. Reporting obligations under the KSC Act attach from the date the designation decision enters into force – not from the date of application. An entity that believes it may qualify as an OES should seek a legal assessment promptly, because operating as an undesignated OES while meeting the substantive criteria creates a compliance gap that regulators can identify retrospectively.

Q: What is the difference between a "significant incident" under the KSC Act and a "major incident" under DORA?

A: The two definitions use different criteria and serve different regulatory purposes. Under the KSC Act, a significant incident is assessed by reference to impact on essential service continuity, number of users affected, and geographic scope. The assessment is qualitative and sector-specific. Under DORA, a major ICT-related incident is assessed against quantitative thresholds published by the European Banking Authority – including the number of clients impacted, the value of transactions affected, and the duration of unavailability. An entity subject to both frameworks (for example, a bank that is also an OES) must apply both sets of criteria independently and may need to file under both regimes for the same underlying event.

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