GDPR and personal data breach obligations in Poland

Last updated: 17.07.2026

Legal framework applicable in Poland

The GDPR (General Data Protection Regulation) is a regulation of the European Union and therefore applies directly, without the need for transposition.

National law nonetheless plays an important supporting role. In Poland the relevant instrument is the Act of 10 May 2018 on the Protection of Personal Data, which designates the supervisory authority, governs the procedure for personal data protection proceedings, and contains a number of Poland-specific rules permitted by the GDPR’s opening clauses.

As a central part of European data protection laws, the GDPR sets out the general framework for personal data processing, data privacy, breach notification and the allocation of data protection responsibilities between controllers, processors and public bodies.

The supervisory authority is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, “UODO”), the central administrative body that replaced the former Inspector General for Personal Data Protection on 25 May 2018. The President of UODO is the single point of contact for breach notifications, conducts investigations, and is empowered to impose administrative fines and other corrective measures as a competent public authority.

Data privacy, GDPR compliance and related legal obligations in Poland

Data breach duties do not operate in isolation. They form one layer of an increasingly dense regulatory stack that includes

• the National Cybersecurity System Act (implementing NIS2)
• DORA for the financial sector
• the Electronic Communications Law for telecommunications undertakings
• various sector-specific rules.

The remainder of this article addresses the GDPR obligations first, and then explains how they dovetail with that wider framework including wider GDPR requirements, operational GDPR compliance and practical data protection rules.

What is a personal data breach?

Article 4(12) GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

The European Data Protection Board classifies breaches into three overlapping categories, and a single event may fall into more than one:

1. a confidentiality breach, unauthorised or accidental disclosure of, or access to, personal data;
2. an integrity breach, unauthorised or accidental alteration of personal data; and
3. an availability breach, accidental or unauthorised loss of access to, or destruction of, personal data (for example, encryption by ransomware or deletion without a recoverable backup).

Two distinctions matter in practice:

1. a security incident is not the same as a personal data breach: an attack that is contained before any personal data is affected may be an incident for cybersecurity purposes without engaging Articles 33 and 34 GDPR
2. a personal data breach is not always a “significant incident” under NIS2/KSC. Each regime applies its own threshold to the same underlying event, which is why the classification exercise must be carried out separately for each.

Data security and the preventive baseline

Breach obligations are the reactive counterpart to a positive, continuing duty to secure personal data to protect personal data throughout the full lifecycle of processing.

Under Article 32 GDPR, the controller and processor must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account:

• the state of the art;
• the costs of implementation;
• the nature, scope, context and purposes of processing;
• the risks to the rights and freedoms of natural persons.

The regulation expressly mentions:

• pseudonymisation and encryption;
• measures ensuring ongoing confidentiality, integrity, availability and resilience of systems;
• the ability to restore availability after an incident;
• a process for regularly testing and evaluating those measures.

In practice, these safeguards form the operational foundation of data security, data protection measures, security measures, technical measures and organizational security measures.

This preventive baseline overlaps substantially with the cybersecurity risk-management obligations imposed on essential and important entities under Article 21 NIS2 (as transposed by the KSC Act) and with the ICT risk-management framework required of financial entities under DORA.

In most organisations the same controls, such as access management, network segmentation, logging, backup and recovery, vulnerability management, supplier assurance, will be relied upon to demonstrate compliance with all three regimes at once. The accountability principle in Article 5(2) GDPR means the controller must not only adopt those measures but also be able to evidence that it has done so.

Notifying the supervisory authority (Article 33 GDPR)

Where a personal data breach occurs, the controller must notify it to the President of UODO without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. A notification made after 72 hours must be accompanied by reasons for the delay. The 72-hour ceiling is best treated as a firm operational deadline rather than a target.

This obligation applies primarily to data controllers, while the role of the data processor is to notify the controller without undue delay after becoming aware of a breach. The practical division of tasks should be reflected in the data processing agreement.

When does the 72-hour notification period start?

A controller is regarded as having become “aware” of a breach when it has a reasonable degree of certainty that a security incident has occurred which has led to personal data being compromised.

A short period of investigation to establish whether a breach has in fact occurred is permissible, but it must be prompt; the 72-hour period runs from the moment of awareness, not from the conclusion of a leisurely internal review.

Content of the personal data breach notification

Article 33(3) requires the notification to describe, at a minimum:

• the nature of the breach (including, where possible, the categories and approximate number of data subjects and of personal data records concerned)
• the name and contact details of the data protection officer or other contact point
• the likely consequences of the breach
• the measures taken or proposed to address it and to mitigate its possible adverse effects.

Phased notifications and processor obligations

Where it is not possible to provide all of the information at once, it may be supplied in phases without further undue delay. In Poland the notification is filed electronically through a dedicated e-service on the Biznes.gov.pl platform; the form distinguishes between a complete notification, a preliminary notification (used to meet the 72-hour deadline where the full picture is not yet available) and a supplementary or amending notification.

Where the controller engages a processor, the processor must notify the controller without undue delay after becoming aware of a breach, so that the controller can in turn meet its own deadline; the precise mechanics should be fixed in the data processing agreement. This is especially important for outsourcing, IT, hosting and cloud service providers that may handle personal data on behalf of multiple customers.

Communicating the breach to data subjects

Notification to the authority is distinct from communication to affected individuals. Under Article 34, where a breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must also communicate the breach to those individuals without undue delay, in clear and plain language, describing the nature of the breach and providing the same categories of information (contact point, likely consequences, mitigating measures).

The GDPR provides three exemptions from individual communication where:

1. the controller had applied appropriate technical and organisational protection measures to the affected data, rendering it unintelligible to unauthorised persons (notably strong encryption);
2. the controller has taken subsequent measures ensuring that the high risk is no longer likely to materialise;
3. individual communication would involve disproportionate effort, in which case a public communication or similar measure reaching the data subjects equally effectively may be used.

The President of UODO retains the power to require communication to individuals if it considers the high-risk threshold to be met.

Documentation, accountability and personal data processing records

Article 33(5) GDPR requires the controller to document every personal data breach, including the facts relating to the breach, its effects and the remedial action taken, irrespective of whether the breach was notifiable. This internal breach register enables the supervisory authority to verify compliance and is, in practice, one of the first documents the President of UODO will request when examining how an organisation handled an incident. A reasoned record of the decision not to notify (where that conclusion is reached) is just as important as the record of a notification that was made.

How GDPR breach obligations interact with NIS2/KSC, DORA and sector-specific rules

A single incident may simultaneously be a personal data breach under the GDPR, a significant incident under the National Cybersecurity System Act implementing NIS2, and, for a bank or other financial entity, a major ICT-related incident under DORA. Each regime has its own authority, its own threshold and its own timetable, and the obligations apply independently and in parallel.

The table below summarises the principal reporting channels that an organisation operating in Poland may need to engage at the same time.

The deadlines above are indicative of the framework; the precise classification, content and timing should be assessed for each incident.

The NIS2 coordination rule

NIS2 anticipates this overlap. Article 35 requires the competent cybersecurity authorities, where they become aware in the course of supervision or enforcement that an entity’s infringement may entail a personal data breach notifiable under Article 33 GDPR, to inform the data protection supervisory authority without undue delay.

Critically, the same provision contains a ne bis in idem safeguard: where the data protection authority imposes an administrative fine for the same conduct, the cybersecurity authority must not impose a fine for that infringement under NIS2 (although it may still apply other enforcement measures). This does not, however, relieve the entity of the duty to make each separate notification.

The position of the President of UODO on incident reporting

The Polish supervisory authority has confirmed that the duty to notify a personal data breach under Article 33 GDPR is independent of any obligation to report an incident under the National Cybersecurity System Act. The two notifications are made to different bodies and neither absorbs the other.

The President of UODO additionally encourages controllers whose breaches involve phishing, malicious attachments, extortion or malware to report those events to CERT Polska as well. The practical lesson is that breach-response and incident-response playbooks should be integrated, mapping each potential event to every authority that may need to be notified and to the shortest applicable deadline.

For financial entities, DORA operates as the sector-specific regime for ICT incident reporting; the interaction between DORA, NIS2/KSC and the GDPR is addressed in detail in our dedicated DORA article, to which this section should be read as a companion.

Data centres and providers of digital infrastructure

Data centres deserve separate treatment because they sit precisely at the junction of the data protection and cybersecurity regimes.

Under NIS2, data centre service providers are expressly listed within the “digital infrastructure” sector in Annex I, alongside:

• cloud computing providers;
• content delivery networks;
• internet exchange points;
• DNS and TLD service providers;
• trust service providers.

A commercial data centre operator that meets the size thresholds will therefore generally qualify as an essential or important entity, with the full suite of risk-management and incident-reporting duties. In-house corporate data centres operated by an entity solely for its own purposes are excluded (Recital 35 NIS2), and there is no “group privilege”: a company providing data centre or managed services to other members of its corporate group is in principle in scope just as if it served third parties.

Liability of a data center operator as a data processor

From the GDPR side, a data centre or colocation provider that processes personal data on behalf of its customers acts as a processor.

That status engages:

• mandatory contractual requirements of Article 28 GDPR;
• security obligations under Article 32 GDPR;
• the duty to notify the controller of a breach without undue delay;
• rules on the use of sub-processors;
• assistance obligations owed to the controller.

Where the facility, or any sub-processor, is located outside the European Economic Area, the international data transfers rules in Chapter V GDPR must also be satisfied.

The most common source of dispute after an incident at shared infrastructure is the allocation of responsibility between the customer (controller) and the operator (processor). Who detects the breach, who assesses risk, who notifies, and within what internal timescale. These questions are far easier to resolve in the data processing agreement, before an incident, than in its immediate aftermath.

Sanctions, enforcement and civil liability under the GDPR

Infringements of the GDPR are subject to administrative fines on two tiers, set out in Article 83. The two tiers are summarised below.

An inadequate security posture and a failure to notify fall within the lower tier; where the same incident also reveals unlawful processing or a breach of the basic principles, the higher tier may apply.

The higher tier may also become relevant where an organisation infringes the key principles of processing, including data protection principles, purpose limitation, storage limitation, data accuracy and transparency. It may also apply where processing lacks a valid legal basis, such as explicit consent, informed consent, legal obligation, vital interests, public interest or another lawful ground recognised by the GDPR.

Additional risk arises where an organisation processes special category data, including health data, genetic data, biometric data, data revealing religious or philosophical beliefs, or political opinions, or where processing relates to criminal convictions. Organisations that process special category data should apply stricter safeguards and carefully document the basis and purpose of such processing.

Polish law adds a notable national feature: the Act of 10 May 2018 caps the administrative fines that may be imposed on public-sector bodies, in particular units of the public finance sector, at PLN 100,000 (and PLN 10,000 for certain cultural institutions), in contrast to the much higher ceilings applicable to commercial undertakings.

Enforcement in Poland is active: in 2025 the President of UODO received close to 22,500 breach notifications, and the largest administrative fine imposed to date, PLN 27 million on Poczta Polska, illustrates that significant sanctions are a genuine prospect.

Beyond administrative liability, Article 82 GDPR gives any person who has suffered material or non-material damage as a result of an infringement the right to claim compensation before the civil courts, an avenue of growing importance in the Polish case law, including following data breaches.

How we can help

Dudkowiak & Putyra advises Polish and international clients across the full data protection and cybersecurity lifecycle. In the specific context of personal data breaches, our support typically includes:

1. building and stress-testing a breach-response playbook that meets the 72-hour GDPR deadline and integrates the parallel NIS2/KSC, DORA and sectoral reporting clocks;
2. real-time advice during a live incident — breach classification, risk assessment, and the drafting and filing of notifications to the President of UODO and communications to data subjects;
3. preparing and negotiating Article 28 data processing agreements and allocating breach responsibilities between controllers, processors, cloud and data centre operators;
4. conducting data protection impact assessments, records of processing and Article 32 security reviews, aligned with NIS2 and DORA requirements;
5. representing clients in proceedings before the President of UODO and in related civil claims; and
6. delivering tailored training for management and staff on incident detection, escalation and reporting.

To discuss how these obligations apply to your organisation, please contact our Data Protection team.

Frequently asked questions: GDPR breach obligations