{"id":3912,"date":"2026-06-25T09:40:00","date_gmt":"2026-06-25T07:40:00","guid":{"rendered":"https:\/\/www.lablogic.pl\/does-every-data-breach-need-to-be-reported\/"},"modified":"2026-10-03T00:36:45","modified_gmt":"2026-10-02T22:36:45","slug":"does-every-data-breach-need-to-be-reported","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/does-every-data-breach-need-to-be-reported\/","title":{"rendered":"Does every data breach need to be reported?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for DPOs and process owners \u2022 published June 25, 2026 \u2022 updated October 3, 2026 \u2022 8 min read<\/p>\n\n\n\n

\n
\n
\n\n\n\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Brief Answer<\/h2>\n\n\n\n

Not every one. Reporting to the President of UODO is the rule \u2014 an organization can only deviate from it if its assessment indicates that the breach is unlikely to result in a risk to the rights or freedoms of natural persons. The report must be made without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach \u2014 not after its occurrence. The standard is \u201cwithout undue delay\u201d; 72 hours is a limit, not a period to be used up. Notifying the data subjects is a separate decision and only arises in cases of high risk. However, every breach, even those not reported by the organization, must be documented. <\/p>\n<\/div>\n\n\n\n

Why this question arises at all<\/h2>\n\n\n\n

The doubt has two sources, both organizational, not legal.<\/p>\n\n\n\n

First, not every security incident is a personal data breach. A blocked login or a detected and repelled phishing attempt is not a breach where it did not compromise the confidentiality, integrity or availability of personal data. A server outage, by contrast, has to be assessed for any loss of availability of personal data, including a temporary one. A breach is an incident that led to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. Until an organization resolves this qualification, discussion about reporting is premature. <\/p>\n\n\n\n

Second, some organizations adopt the principle of \u201cwe report everything, just in case.\u201d This appears to be a cautious approach, but in practice, it weakens the controller’s position. A report is a statement about the outcome of a risk assessment \u2014 if an organization reports without this assessment, it shows the authority that it did not conduct one. The same mechanism works in reverse. A lack of reporting without documented analysis is equally difficult to defend. <\/p>\n\n\n\n

Added to this is the mechanics of the deadline. Seventy-two hours are counted from the controller becoming aware of the breach, not from the moment the incident occurred. In large organizations, most of this time is usually consumed by the information flow. It runs from the employee, through the supervisor and IT department, to the data protection officer. The decision is made at the end of this path, and only then is it clear how much time realistically remains. <\/p>\n\n\n\n

\n

It is also worth noting that the reporting threshold itself is subject to legislative work. The European Commission’s proposal from the Digital Omnibus package envisages raising the reporting threshold to high risk, extending the deadline to 96 hours, and establishing a common point for receiving reports. This is a project at the stage of work in the European Parliament and the Council \u2014 until the changes are adopted and enter into force, the existing rules apply, and current breaches should be assessed according to them. <\/p>\n<\/div>\n\n\n\n

What needs to be determined before making a decision<\/h2>\n\n\n\n

Whether the incident is a personal data breach<\/h3>\n\n\n\n

Qualification covers three dimensions. These are confidentiality (data reached an unauthorized person), integrity (data was altered unlawfully or accidentally), and availability (data was lost or access to it is impossible). Loss of availability is sometimes overlooked, although it is a breach just like a leak \u2014 an organization that restored data from a backup after a ransomware attack still deals with a breach if it could not perform processing for some time. <\/p>\n\n\n\n

This determination only answers the question of \u201cwhether GDPR is even applicable.\u201d It does not yet prejudge anything about reporting. <\/p>\n\n\n\n

When the organization became aware of the breach<\/h3>\n\n\n\n

The 72-hour deadline runs from becoming aware of the breach, that is from the moment the controller has a reasonable degree of certainty that an incident has led to personal data being compromised. How to count this deadline at weekends, during the preliminary investigation and when information comes from a processor is described in How to count the 72 hours for notifying a personal data breach?<\/a>.<\/p>\n\n\n\n

What risk arises for data subjects, not for the organization<\/h3>\n\n\n\n

This is the point where perspectives most often diverge. The assessment concerns the consequences for data subjects \u2014 identity theft, financial fraud, disclosure of highly sensitive information, discrimination, financial loss, damage to reputation. The controller’s reputational risk is not part of this analysis. <\/p>\n\n\n\n

The assessment combines two dimensions. These are the likelihood of the consequence occurring and the severity of its impact on the rights or freedoms of the individual. In its judgment of October 1, 2025 (III OSK 1830\/22), the Supreme Administrative Court indicated that determining that the probability is not low, combined with a high severity of potential impact, determines the possibility of high risk, and the obligation to notify does not require that the individual’s rights have already been actually violated. The Court also confirmed that the disclosure of a PESEL number along with a name and surname creates a high risk. For practical purposes, this means one thing. The argument \u201cnothing happened, no one used this data\u201d is not a premise for assessment. <\/p>\n\n\n\n

The analysis is structured by EDPB guidelines containing eighteen example cases \u2014 ransomware, data exfiltration, internal risk, lost devices, incorrect correspondence dispatch, social engineering \u2014 along with an indication of when the obligation to report and notify arises in each of them. The guidelines are not a source of law but define supervisory practice and are a good reference point for building one’s own assessment criteria. <\/p>\n\n\n\n

Is the risk high \u2014 i.e., the second, separate decision<\/h3>\n\n\n\n

Reporting to the authority and notifying data subjects are two different obligations with different thresholds. Reporting to the UODO is only waived when the breach is unlikely to result in a risk to the rights or freedoms of natural persons. Notifying data subjects arises in the opposite scenario \u2014 only when the risk is high \u2014 and must occur without undue delay, without a rigid hourly deadline. <\/p>\n\n\n\n

The GDPR provides for three situations where notifying data subjects is not required despite high risk. These are when the controller had implemented protection measures rendering the data unintelligible to unauthorized persons beforehand and applied them to the data affected by the breach, when the controller implemented measures after the breach to eliminate the likelihood of high risk, and when individual notification would require disproportionate effort \u2014 in which case a public communication is appropriate. Invoking the first of these exceptions requires demonstrating that the security measure was effective at the time of the breach; a declaration that \u201cthe data was encrypted\u201d without specifying the scope and method of key management does not close the case. The decision to rely on an exception is not the controller’s alone. The supervisory authority may require the data subjects to be notified or may decide that a condition waiving notification has been met (Article 34(4) GDPR). <\/p>\n\n\n\n

Which authority and what parallel obligations apply<\/h3>\n\n\n\n

For cross-border processing, it is necessary to determine whether the President of UODO is the lead authority or if the authority of another country is competent. A controller without an organizational unit in the Union, but subject to the GDPR, does not benefit from the comprehensive cooperation mechanism \u2014 according to EDPB Guidelines 9\/2022, they must report the breach to the supervisory authorities of all countries where affected individuals reside. The appointment of an EU representative does not change this. <\/p>\n\n\n\n

Regardless of the GDPR, the same incident may trigger other regimes. These are obligations towards CSIRT for entities covered by the National Cybersecurity System Act, sectoral obligations arising from DORA, the Polish Electronic Communications Law, or the eIDAS regulation. The deadlines and thresholds in these are different and do not replace each other. Organizations that are just setting up this area usually start by determining the scope of obligations within the framework of preparation for NIS2 and KSC<\/a>, and only then combine the reporting paths into a single procedure. <\/p>\n\n\n\n

Four typical resolutions<\/h2>\n\n\n\n
Situation<\/th>Report to UODO<\/th>Notify data subjects<\/th>What remains in the documentation<\/th><\/tr><\/thead>
Security incident with no impact on personal data<\/td>No<\/td>No<\/td>Register of security incidents; justification of qualification if the signal concerned data<\/td><\/tr>
Breach where a risk to data subjects is unlikely to arise<\/td>No<\/td>No<\/td>Entry in the breach register along with risk assessment and basis for the decision not to report<\/td><\/tr>
Breach with risk that is not high<\/td>Yes \u2014 without undue delay, no later than 72 hours from becoming aware<\/td>No<\/td>Entry in the register, report, correspondence with the authority, remedial actions<\/td><\/tr>
Breach with high risk<\/td>Yes \u2014 without undue delay, no later than 72 hours from becoming aware<\/td>Yes, without undue delay \u2014 unless one of the exceptions applies<\/td>Entry in the register, report, content and method of notification or justification for the exception<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The table organizes typical scenarios but does not replace an assessment. The same type of incident \u2014 for example, sending correspondence to the wrong recipient \u2014 falls into different rows depending on what data the attachment contained and who received it. <\/p>\n\n\n\n

Most common mistakes<\/h2>\n\n\n\n