{"id":3843,"date":"2026-08-17T12:44:45","date_gmt":"2026-08-17T12:44:45","guid":{"rendered":"https:\/\/sawaryn.com\/?p=3843"},"modified":"2026-10-26T12:28:51","modified_gmt":"2026-10-26T12:28:51","slug":"personal-data-breach-poland-first-72-hours","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/personal-data-breach-poland-first-72-hours\/","title":{"rendered":"A Data Breach at Your Company. What to Do in the First Hours to Avoid Making Things Worse"},"content":{"rendered":"

Monday morning. Your employee has sent a spreadsheet containing the data of 2000 customers to the wrong email address. IT says \u201cit\u2019s not our problem”, marketing wants to keep it quiet, and you have 72 hours to make a decision<\/strong> that could cost the company hundreds of thousands of zlotys. What do you do first?<\/p>\n

A personal data breach can happen to any company – from a SaaS startup to a large e-commerce<\/a> organization. According to data from the President of the UODO, 14,842 breach notifications<\/strong> were submitted in 2024, followed by 22,435<\/strong> in 2025. The numbers are rising year on year. The greatest threat is not the incident itself. It is the lack of a response process – chaos, conflicting decisions, a missed notification deadline, and inconsistent documentation.<\/p>\n

In this article, you will find a specific action plan for the first few hours after a data leak<\/a><\/strong> or another personal data breach. You will learn how to classify an event, when to notify the UODO, who is responsible for what, and which mistakes to avoid so that you do not make the situation worse.<\/p>\n

Terms you need to know before an incident<\/h2>\n

Before we move on to the individual steps, let\u2019s clarify the terminology. In the chaos following an incident, there is no time to look up definitions.<\/p>\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nWhat it means<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
Personal data breach<\/strong><\/td>\nAn event leading to the destruction, loss, alteration, unauthorized disclosure of, or access to personal data (Article 4(12) GDPR)<\/td>\nNot every IT incident is a GDPR breach – but every incident requires an assessment<\/td>\n<\/tr>\n
Controller<\/strong><\/td>\nThe entity that determines the purposes and means of processing personal data<\/td>\nThe controller is responsible for notifying the UODO and classifying the event<\/td>\n<\/tr>\n
Processor<\/strong><\/td>\nAn entity that processes data on behalf of the controller (e.g. a cloud, CRM, or marketing automation provider)<\/td>\nThe processor reports the breach to the controller – not directly to the UODO<\/td>\n<\/tr>\n
UODO<\/strong><\/td>\nPersonal Data Protection Office – the Polish supervisory authority<\/td>\nThe authority to which a breach must be notified within 72 hours<\/td>\n<\/tr>\n
Initial notification<\/strong><\/td>\nA notification containing incomplete information that is supplemented in stages<\/td>\nIt allows you to meet the deadline even when the facts remain unclear<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The three dimensions of a data security breach are confidentiality<\/strong>, integrity<\/strong>, and availability<\/strong>. A breach is not just a \u201cleak” – it also includes unauthorized alteration of data (integrity) or loss of access to it (availability). If an external provider\u2019s system stops working and blocks access to customer data for several hours, this may constitute an availability breach under the GDPR.<\/p>\n

How to distinguish a security incident from a personal data breach<\/h2>\n

Not every irregularity involving data is a breach that must be notified to the UODO. But every such event requires assessment and documentation. This distinction has a direct impact on your obligations.<\/p>\n

A personal data breach<\/strong> within the meaning of Article 4(12) GDPR is substantive in nature – it requires an actual security breach leading to one of five consequences: the destruction, loss, alteration, unauthorized disclosure of, or unauthorized access to personal data. An incorrect privacy notice<\/a> on a website constitutes a violation of the GDPR, but it is not a personal data breach in this sense.<\/p>\n\n\n\n\n\n\n\n\n\n
Event<\/th>\nIs it a GDPR breach?<\/th>\nWhat you need to do<\/th>\n<\/tr>\n<\/thead>\n
An employee sends a spreadsheet containing customer data to the wrong email address<\/td>\nYes – unauthorized disclosure (confidentiality)<\/td>\nRisk assessment \u2192 decision on notifying the UODO \u2192 consider notifying the individuals<\/td>\n<\/tr>\n
A cybercriminal takes over an employee\u2019s email account<\/td>\nProbably yes – unauthorized access (confidentiality)<\/td>\nDetermine the scope of the exposed data \u2192 risk assessment \u2192 notification<\/td>\n<\/tr>\n
A cloud provider\u2019s system is unavailable for 6 hours<\/td>\nPossibly – loss of data availability<\/td>\nAssess whether the lack of access affected individuals\u2019 rights (e.g. patients, customers)<\/td>\n<\/tr>\n
An error in the privacy notice on the website<\/td>\nNo – it is a violation of the law, but not a data security breach<\/td>\nCorrect the notice; do not report it as a breach under Article 33<\/td>\n<\/tr>\n
Ransomware encrypts a database – the company has backups<\/td>\nYes – an availability and potentially confidentiality breach<\/td>\nAssess whether data was exfiltrated \u2192 notification depends on the outcome of the analysis<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The obligation to notify the UODO arises when the breach may result in a risk to the rights or freedoms of natural persons<\/strong> – and that risk is more than \u201clow”. The UODO and EDPB interpret this requirement strictly: the absence of any realistic possibility of harm must be demonstrated, not merely assumed. If in doubt, it is safer to notify.<\/p>\n

The first 72 hours after a data breach – step by step<\/h2>\n

The 72-hour deadline for notifying a breach to the President of the UODO (Article 33(1) GDPR) begins when the controller becomes aware of the breach<\/strong> – not when it technically occurred. According to EDPB Guidelines 9\/2022, a controller \u201cbecomes aware of a breach” when it has a \u201creasonable degree of certainty” (reasonable degree of certainty<\/em>) that a security incident leading to a personal data breach has occurred.<\/p>\n

This does not mean you can wait. The first indication of an incident requires you to initiate an investigation. You cannot make \u201cawareness” conditional on the completion of a full security audit. The 72-hour period runs continuously – including weekends and public holidays.<\/p>\n

Hours 0-6: containment and initial assessment<\/h3>\n
    \n
  1. Preserve the evidence.<\/strong> Before fixing anything, document the facts – logs, screenshots, communications. A lack of documentation may be treated as a separate violation of the accountability principle<\/a> (Article 5(2) GDPR).<\/li>\n
  2. Set up a response team.<\/strong> Appoint one coordinator (Incident Response Lead) to bring IT, compliance, communications, and management together in a single decision-making process. Following an incident, IT investigates the technical cause, the business wants to limit reputational damage, and compliance expects a formal analysis – without a coordinator, these activities will conflict.<\/li>\n
  3. Gather the facts.<\/strong> Determine: which data was affected, how many individuals were affected, the nature of the breach (confidentiality, integrity, availability), and who had or may have had access to the data.<\/li>\n
  4. Limit the impact.<\/strong> Block accounts, change passwords, revoke access – but do not erase traces of the incident.<\/li>\n<\/ol>\n

    Hours 6-24: classification and decision<\/h3>\n
      \n
    1. Conduct a risk assessment for the individuals.<\/strong> Take into account: the type of data (special categories of data under Article 9 GDPR almost always create a high risk), the number of individuals, how easily they can be identified, the security measures in place (e.g. encryption), and the possibility of further dissemination.<\/li>\n
    2. Decide whether to notify.<\/strong> If the risk is more than \u201clow” – notify. If in doubt – notify. The GDPR allows initial notifications (Article 33(4)) – you do not need to wait for the incident to be fully investigated.<\/li>\n
    3. Assess whether the individuals need to be notified.<\/strong> The threshold is higher than for notifying the UODO – notification is required where there is a high risk<\/strong> to the rights or freedoms of natural persons<\/a> (Article 34(1) GDPR).<\/li>\n
    4. Document the decision and the reasons behind it.<\/strong> Even if you decide that notification is not required – document why. Article 33(5) GDPR requires the documentation of all<\/strong> breaches, regardless of whether they are notified.<\/li>\n<\/ol>\n

      Hours 24-72: notification and communication<\/h3>\n
        \n
      1. Prepare the notification to the UODO.<\/strong> It must contain: a description of the nature of the breach, including the categories and approximate number of individuals, the contact details of the DPO<\/a> or another contact point, a description of the likely consequences, and a description of the measures taken or proposed.<\/li>\n
      2. Submit the notification electronically.<\/strong> If you do not have all the information – select the \u201cInitial notification” box and supplement it in stages.<\/li>\n
      3. Prepare a communication for the individuals affected by the breach<\/strong> (if required). Use clear, plain language. Do not cause panic, but do not downplay the situation. Include recommendations such as changing passwords, reporting identity documents as compromised, and monitoring bank accounts.<\/li>\n
      4. Inform the management board<\/strong> about the actions taken, the status of the notification, and the next steps.<\/li>\n<\/ol>\n

        Contact us<\/a> if you need support with classifying an event or preparing a notification to the UODO.<\/p>\n

        Who is responsible for what – controller, processor, management board<\/h2>\n

        In the chaos following an incident, one question often arises: \u201cis this our problem or our provider\u2019s?”. The answer is clear: the controller is responsible for notifying the UODO<\/strong> – even when the breach occurred on the processor\u2019s side.<\/p>\n\n\n\n\n\n\n\n\n\n
        Role<\/th>\nObligation<\/th>\nDeadline<\/th>\n<\/tr>\n<\/thead>\n
        Controller<\/strong><\/td>\nNotify the President of the UODO of the breach<\/td>\n72 hours after becoming aware of the breach<\/td>\n<\/tr>\n
        Controller<\/strong><\/td>\nNotify the data subjects (in the event of a high risk)<\/td>\nWithout undue delay<\/td>\n<\/tr>\n
        Controller<\/strong><\/td>\nDocument all breaches (breach register)<\/td>\nOn an ongoing basis<\/td>\n<\/tr>\n
        Processor<\/strong><\/td>\nInform the controller of the breach<\/td>\nWithout undue delay (Article 33(2) GDPR)<\/td>\n<\/tr>\n
        Management board<\/strong><\/td>\nOversee the response process and approve the decision on notification<\/td>\nOngoing throughout the incident<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        When the breach occurs on the processor\u2019s side<\/h3>\n

        The processor (e.g. a cloud, CRM, or marketing automation provider) must inform the controller of the breach without undue delay<\/strong>. The controller\u2019s 72-hour deadline begins when the controller itself<\/strong> obtains sufficient information – not when the processor detects the problem.<\/p>\n

        Review your data processing agreements<\/a>:<\/p>\n

          \n
        1. Does the agreement specify the deadline by which the processor must inform you of a breach?<\/li>\n
        2. What information must the processor provide to you?<\/li>\n
        3. Who is responsible for notifying the UODO – and is this clearly stated?<\/li>\n<\/ol>\n

          If the agreement is silent on these issues – update it before an incident occurs.<\/p>\n

          Personal liability of management board members<\/h3>\n

          In Polish practice, there have been no rulings imposing administrative fines directly on management board members<\/strong> for mistakes in handling breaches. UODO fines are imposed on entities (controllers). Nevertheless, Article 107 of the Polish Personal Data Protection Act provides for the criminal liability of natural persons<\/strong> for obstructing or hindering an inspection. Article 82 GDPR also opens the door to claims for compensation<\/strong> by data subjects.<\/p>\n

          UODO decision DKN.5131.7.2025 concerned a situation in which the president of the management board simultaneously served as the DPO – the authority found this to constitute a conflict of interest and imposed a fine of PLN 11,365 on the company. Although the fine was imposed on the entity, it was the management board\u2019s decisions regarding the organization of data protection that led to the violation.<\/p>\n

          Three exceptions that remove the obligation to notify individuals<\/h2>\n

          Even if a breach poses a high risk, the GDPR provides for three situations in which you do not have to notify the individuals<\/strong> (Article 34(3)):<\/p>\n\n\n\n\n\n\n\n
          Exception<\/th>\nCondition<\/th>\nExample<\/th>\n<\/tr>\n<\/thead>\n
          Encryption<\/strong><\/td>\nThe data was encrypted using measures that render it unintelligible to unauthorized persons<\/td>\nA lost laptop with an encrypted drive – the keys were not compromised<\/td>\n<\/tr>\n
          Elimination of risk<\/strong><\/td>\nThe controller took measures that eliminated the likelihood of a high risk<\/td>\nRecovery of the storage medium, confirmation that the unauthorized person deleted the data<\/td>\n<\/tr>\n
          Disproportionate effort<\/strong><\/td>\nIndividual notification would require disproportionate resources<\/td>\nThe controller issues a public announcement (e.g. on its website)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Note: each of these exceptions requires objective evidence<\/strong>, not mere assumptions. The President of the UODO may require individuals to be notified if the authority finds that the exemption conditions have not been met (Article 34(4) GDPR).<\/p>\n

          How much an inadequate response to a data leak can cost<\/h2>\n

          UODO fines for failing to notify a breach or inform individuals are not abstract. Below are specific decisions from Polish practice<\/a>:<\/p>\n\n\n\n\n\n\n\n\n\n
          Entity<\/th>\nFine<\/th>\nReason<\/th>\n<\/tr>\n<\/thead>\n
          Company (DKN.5131.6.2023)<\/td>\nPLN 282,960<\/td>\nFailure to notify the breach + failure to inform the individual – repeated violation<\/strong> (previous fine of PLN 136,437 in 2021)<\/td>\n<\/tr>\n
          National Prosecutor\u2019s Office (DKN.5131.33.2023)<\/td>\nPLN 85,000<\/td>\nDisclosure of data at a press conference + failure to notify the breach + failure to inform the individual<\/td>\n<\/tr>\n
          P4 telecommunications operator<\/td>\nPLN 250,000<\/td>\nFailure to meet the sector-specific 24-hour notification deadline<\/td>\n<\/tr>\n
          Court enforcement officer<\/td>\n~PLN 21,000<\/td>\nPLN 7,700 for failure to notify (Article 33) + PLN 13,200 for failure to inform the individual (Article 34)<\/td>\n<\/tr>\n
          Regional Court in Krak\u00f3w<\/td>\nPLN 10,000<\/td>\nFailure to notify the breach + failure to inform the individual (public sector, max. PLN 100,000)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          The maximum fine under Article 83(4) GDPR is EUR 10 million or 2% of annual turnover<\/strong> – whichever is higher. For public finance sector entities, Article 102 of the Polish Personal Data Protection Act limits the fine to PLN 100,000.<\/p>\n

          Factors that increase<\/strong> the fine: repeated violations, failure to cooperate with the authority, and intentional conduct. Mitigating<\/strong> factors: voluntarily notifying the breach, promptly taking action to minimize harm, and cooperating with the UODO. Proactive notification and transparent action are not only obligations – they are also a way to limit financial risk.<\/p>\n

          Global IBM data indicates that the average cost of a data breach incident is approximately USD 4.88 million<\/strong> (2024 data), while the average time required to identify and contain a breach is approximately 258 days<\/strong>. Comparable figures for Poland are not publicly available, but the scale of the problem is growing – CERT Polska recorded 600,990 reports<\/strong> in 2024.<\/p>\n

          What not to do in the first few hours after a data leak<\/h2>\n

          The greatest risk following an incident comes from delay, chaos, and inconsistent action – not the incident itself. Here are the most common mistakes:<\/p>\n

            \n
          1. Do not wait for a full investigation before notifying.<\/strong> The GDPR allows initial notifications. Waiting for an IT report may result in missing the 72-hour deadline.<\/li>\n
          2. Do not erase traces of the incident.<\/strong> Fixing the system without preserving evidence will make it more difficult to defend yourself before the UODO and prevent a proper root cause analysis.<\/li>\n
          3. Do not keep the matter quiet internally.<\/strong> A lack of communication with the management board, HR, or the legal department leads to conflicting decisions. Appoint a single coordinator.<\/li>\n
          4. Do not notify the affected individuals without preparation.<\/strong> Chaotic communication may cause panic and media escalation. Prepare the notification, including recommendations for the individuals concerned (changing passwords, reporting identity documents as compromised).<\/li>\n
          5. Do not assume that \u201cit\u2019s not our problem because the breach occurred at the provider”.<\/strong> The controller is responsible for notifying the UODO – regardless of whose side the incident occurred on.<\/li>\n
          6. Do not neglect documentation.<\/strong> Article 33(5) GDPR requires all breaches to be documented. A lack of documentation is a separate violation of the accountability principle.<\/li>\n<\/ol>\n