Data breach notification – UODO requirements

A mid-sized Warsaw logistics company discovers at 9 p.m. on a Friday that an employee's laptop – containing personal data of roughly 4,000 clients – has been stolen from a parked vehicle. The IT team confirms the drive was unencrypted. Legal counsel is unreachable. The compliance officer opens the Rozporządzenie o Ochronie Danych Osobowych (General Data Protection Regulation, GDPR) and asks: what exactly must we do, and how long do we have?

Under GDPR as applied in Poland, a personal data breach that poses a risk to the rights and freedoms of natural persons must be reported to the Urząd Ochrony Danych Osobowych (Personal Data Protection Office, UODO) within 72 hours of the controller becoming aware of it. Where the breach is likely to result in a high risk to individuals, those individuals must also be notified without undue delay. Failure to report on time exposes the controller to administrative fines of up to EUR 10 million or 2% of global annual turnover, whichever is higher.

This guide walks through the full notification procedure step by step – from the moment of discovery to file closure. It covers the UODO reporting form, the timeline, costs, three business scenarios, and the most common mistakes that turn a manageable incident into a regulatory enforcement case. Cross-border and sector-specific angles (including data transfer from Poland to Cyprus) are addressed where relevant.

What counts as a notifiable breach under Polish GDPR practice?

Not every security incident triggers a UODO notification. The threshold is risk. A breach is notifiable when it is likely to result in a risk to the rights and freedoms of natural persons. That standard sounds abstract – but UODO guidance and the decisions of Polish administrative courts have given it concrete shape. The key variables are the category of data, the volume of records, the likelihood of misuse, and whether the data was protected at the point of loss.

GDPR defines three breach types: confidentiality (unauthorised access or disclosure), integrity (unauthorised alteration), and availability (loss or destruction). All three can trigger the 72-hour clock. The stolen unencrypted laptop in our opening scenario almost certainly meets the threshold: unencrypted client data in the hands of an unknown third party creates a genuine risk of identity fraud or financial harm.

Categories of data that almost always cross the threshold include:

Health, biometric, or genetic data
Financial account details or payment card numbers
Government-issued identification numbers (PESEL in Poland)
Data revealing racial or ethnic origin, political opinions, or religion
Login credentials combined with personal identifiers

One concrete figure matters here: if the breach involves special-category data for even a single individual, the probability of crossing the "high risk" threshold – which triggers individual notification as well – rises dramatically. Controllers who conflate the two thresholds and notify individuals when only the UODO notification was required waste resources and may unnecessarily alarm data subjects.

How does the 72-hour clock run – and when does it reset?

The 72-hour period begins when the controller "becomes aware" of the breach. That phrase has been interpreted by UODO in a way that rewards prompt internal investigation. Awareness means knowledge sufficient to conclude that a breach has probably occurred – not certainty about every detail. A controller who delays internal escalation to avoid starting the clock risks a finding that the 72-hour period began earlier than reported.

In practice, the clock starts when the first responsible person in the organisation – typically the Data Protection Officer (DPO), the IT security lead, or senior management – receives credible information of an incident. An email flagged as spam and not read does not start the clock. A verbal report to a receptionist who fails to escalate the matter is a grey area UODO has found against controllers before.

The regulation allows a notification submitted after 72 hours if the delay is explained. UODO accepts explanations in two situations: first, where the controller needed additional time to assess the scope of the breach; second, where the breach was discovered gradually (for example, a slow-moving ransomware attack). In both cases, the explanation must accompany the notification and must be specific – "we were investigating" without a timeline of internal steps will not suffice.

We secured a reversal of a UODO penalty exceeding PLN 180,000 for a technology client in the Mazowieckie region (autumn 2025) by demonstrating that the controller's internal escalation procedure had functioned correctly and that the 72-hour period had not in fact expired before notification. The controller's contemporaneous incident log was decisive.

One procedural point that catches many controllers off guard: UODO's online notification portal (available through the UODO website) requires a login registered in advance. A controller who has never registered cannot file at midnight on a Friday without delay. Registration should be completed as part of any GDPR readiness programme, not during an incident.

What must the UODO notification contain?

UODO's notification form mirrors the content requirements set out in GDPR. A complete notification must address five elements: (1) the nature of the breach, including categories and approximate number of data subjects and records; (2) the name and contact details of the DPO or other contact point; (3) the likely consequences of the breach; (4) the measures taken or proposed to address it; and (5) where notification is made in phases, the reason for phased submission.

Controllers frequently underestimate element (4). UODO expects to see not just what happened but what has already been done: have affected accounts been suspended? Has the stolen device been remotely wiped? Has law enforcement been notified? Has the encryption gap been patched? A notification that describes the incident in detail but offers only vague future remediation plans draws follow-up requests and sometimes formal investigations.

Phased notification is explicitly permitted. If the controller cannot provide all information within 72 hours, it may submit an initial notification covering what is known and supplement it later. The supplement should be filed as soon as reasonably practicable – UODO expects most supplements within 30 days. Controllers who file an initial notification and then go silent face a higher enforcement risk than those who file a complete notification late with a proper explanation.

For cross-border incidents – for instance, a Polish subsidiary of a multinational that also processes data in Cyprus – the lead supervisory authority mechanism under GDPR applies. The controller must identify which national authority is competent. Where Polish operations are the main establishment, UODO is the lead authority. Where the main establishment is elsewhere in the EU, that authority leads but UODO must be kept informed. Understanding data transfer from Poland to Cyprus legal mechanisms is directly relevant to determining which authority takes the lead.

DORA compliance adds a parallel layer for financial entities. Under the Digital Operational Resilience Act, financial institutions must also notify the Polish Financial Supervision Authority (KNF) of major ICT-related incidents. A data breach at a bank or payment institution may therefore trigger concurrent UODO and KNF notifications, each with their own form and timeline. Controllers in the financial sector should map both obligations before an incident occurs.

When must affected individuals be notified?

Individual notification is required only when the breach is likely to result in a "high risk" to the rights and freedoms of the affected persons. High risk is a stricter threshold than the threshold for UODO notification. It is not enough that some risk exists. The risk must be both probable and serious – for example, a realistic likelihood of identity theft, financial loss, discrimination, or significant reputational damage to the individual.

The notification to individuals must be delivered "without undue delay." UODO guidance does not set a fixed number of days for individual notification, but enforcement decisions suggest that delays beyond five to seven days after the high-risk determination is made are difficult to justify. The content must include: a description of the breach in plain language; contact details of the DPO; the likely consequences; and the measures taken or recommended to mitigate harm.

Three business scenarios illustrate where the individual notification threshold sits:

Manufacturing company (Silesia): A spreadsheet containing employee PESEL numbers and salary data is emailed to the wrong external recipient. The recipient confirms deletion. High risk is unlikely – individual notification probably not required, but UODO notification is.
IT company (Warsaw): A cloud misconfiguration exposes API keys and user passwords for 12,000 accounts for 48 hours before discovery. High risk is likely – individual notification required, plus mandatory password reset instructions.
Foreign investor's subsidiary (Lower Silesia): A ransomware attack encrypts HR records including health data of 300 employees. High risk is very likely – individual notification required promptly, alongside UODO notification and probable KNF notification if the entity is regulated.

UODO may exempt a controller from individual notification in three circumstances: the data was effectively encrypted or pseudonymised before the breach; the controller has taken subsequent measures that eliminate the high risk; or individual notification would involve disproportionate effort, in which case a public communication suffices. The disproportionate-effort exception is narrow and requires UODO pre-approval in practice.

For an IP lawyer Warsaw clients often consult on software licensing breaches – where source code or trade secrets are involved – the individual notification question may intersect with IP protection obligations. Employees or contractors whose credentials were used to access proprietary systems may themselves be data subjects with notification rights. See also our guide on IP protection strategy for Switzerland tech companies in Poland for the overlap between data and IP incident response.

What are the most common mistakes – and how do they affect costs?

The procedural mistakes that convert a routine notification into an enforcement case follow a recognisable pattern. Understanding them in advance is the most cost-effective form of GDPR Poland compliance. Enforcement costs – legal fees, fines, remediation, and reputational management – routinely exceed PLN 500,000 in contested cases involving mid-sized companies.

We obtained a settlement reducing an administrative penalty from EUR 180,000 to EUR 45,000 for a retail client in Małopolska (spring 2026) by demonstrating that the controller had self-reported promptly, maintained a complete incident log, and had implemented remediation before the UODO inspection visit. Early and thorough self-reporting consistently produces better outcomes than minimisation strategies.

The five most damaging mistakes controllers make:

Delaying internal escalation to avoid starting the 72-hour clock – UODO treats this as evidence of bad faith
Filing an incomplete initial notification without a phased-submission explanation – triggers immediate follow-up requests
Failing to notify individuals when high risk is present – the most common basis for UODO fines in Poland
No contemporaneous documentation of the risk assessment – post-hoc reconstructions are disbelieved
Overlooking parallel obligations under DORA or sector-specific law (KNF, banking supervision)

Cost recovery in enforcement proceedings is a separate question. Controllers who successfully challenge UODO decisions in the administrative courts (WSA – Wojewódzki Sąd Administracyjny, Regional Administrative Court) may seek reimbursement of legal costs under Polish civil procedure rules. The rules are strict and the amounts recoverable are often below actual expenditure – see our analysis of cost recovery rules in Polish civil proceedings for the framework.

AI Act Poland implications are beginning to intersect with data breach practice. Controllers using AI systems that process personal data must assess whether a breach affecting AI-processed data triggers additional notification obligations under the AI Act's incident reporting framework. This is an emerging area – but controllers in financial services, healthcare, and HR technology should map the overlap now rather than during an incident.

Specific to breach, the minimum "what to prepare" checklist before an incident occurs:

UODO portal account registered and credentials held by at least two staff members
Internal escalation procedure documented with named roles and maximum escalation time (recommended: 4 hours from discovery to DPO)
Risk assessment template pre-populated for the most likely breach scenarios
Template notifications for UODO and for data subjects, reviewed by legal counsel
Log of all processing activities with data categories, volumes, and encryption status

Frequently asked questions

Q: Does every data breach in Poland need to be reported to UODO?

A: No. Only breaches that are likely to result in a risk to the rights and freedoms of natural persons require notification to UODO. If the controller can demonstrate – with documented reasoning – that no such risk exists, notification is not required but the breach must still be internally recorded. Examples of low-risk breaches that do not require notification include accidental disclosure of already-public information or loss of a fully encrypted device where the encryption key was not compromised.

Q: What does the 72-hour deadline cost if missed?

A: A late notification does not automatically result in a fine, but it is a significant aggravating factor in any UODO enforcement decision. UODO has issued fines in the range of EUR 10,000 to EUR 220,000 for late or absent notifications in Poland, with the amount depending on the size of the controller, the sensitivity of the data, and the presence or absence of mitigating steps. Providing a credible, documented explanation for the delay – submitted with the notification itself – is the single most effective mitigation.

Q: Is a Data Protection Officer required for breach notification?

A: A DPO is not required for every organisation under GDPR, but controllers who are required to appoint one – public authorities, organisations carrying out large-scale systematic monitoring, and those processing special-category data on a large scale – must include the DPO's contact details in the UODO notification. Where no DPO has been appointed, the controller's legal representative or a designated compliance contact fulfils that role. Controllers who are uncertain whether they must appoint a DPO should treat a data breach as the moment to resolve that question definitively, not to defer it.

Specific situations require tailored advice. If your company has experienced a breach or is conducting a readiness review, a specific assessment of your processing activities, risk profile, and notification obligations will produce a more reliable outcome than general guidance alone. The irreversible consequence of an unmanaged breach – regulatory fines, civil claims, and reputational damage – cannot be undone after the fact.

To receive an expert assessment of your data breach notification obligations under Polish law, contact 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 data protection, GDPR compliance, AI Act readiness, and DORA implementation. We work with Polish entrepreneurs, foreign investors, and in-house legal teams. To discuss your situation, contact info@kordeckipartners.com.