Does every data breach need to be reported?

Why this question arises at all

The doubt has two sources, both organizational, not legal.

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.

Second, some organizations adopt the principle of “we report everything, just in case.” 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 — 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.

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.

What needs to be determined before making a decision

Whether the incident is a personal data breach

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 — 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.

This determination only answers the question of “whether GDPR is even applicable.” It does not yet prejudge anything about reporting.

When the organization became aware of the breach

Becoming aware is the moment when the controller gained sufficient certainty that an incident involving personal data occurred. A brief verification of a signal falls before this moment, but dragging it out indefinitely does not postpone it. In practice, the decisive factor is whether the organization can indicate the date and time and show what happened between the internal report and that moment.

If a processor detected the breach, it is obliged to notify the controller without undue delay (Article 33(2) GDPR). The provision does not, however, regulate when the controller’s own deadline starts to run; in practice it is assumed to run from the moment the information from the processor is received — which is why the data processing agreement should specify a concrete notification time and the channel through which it should reach the organization.

What risk arises for data subjects, not for the organization

This is the point where perspectives most often diverge. The assessment concerns the consequences for data subjects — 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.

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 24, 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 “nothing happened, no one used this data” is not a premise for assessment.

The analysis is structured by EDPB guidelines containing eighteen example cases — ransomware, data exfiltration, internal risk, lost devices, incorrect correspondence dispatch, social engineering — 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.

Is the risk high — i.e., the second, separate decision

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 — only when the risk is high — and must occur without undue delay, without a rigid hourly deadline.

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 — 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 “the data was encrypted” 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).

Which authority and what parallel obligations apply

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 — 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.

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, and only then combine the reporting paths into a single procedure.

Four typical resolutions

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

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

Most common mistakes

• Counting the deadline from the incident instead of from becoming aware. Leads either to unnecessary haste or — more often — to the belief that the deadline has already passed, and to giving up on reporting.
• Treating 72 hours as a deadline to resolve the matter. The GDPR allows for an initial report and subsequent supplementation of information, but the report must contain at least the nature of the breach together with the categories and approximate number of data subjects and personal data records concerned, the contact details of the data protection officer or another contact point, the likely consequences of the breach, and the measures taken or proposed to address it (Article 33(3) GDPR); reporting after the deadline requires an explanation for the delay. Waiting for complete findings is riskier than an incomplete report.
• Risk assessment from the organization’s perspective. The question is what threatens individuals, not how the incident appears from the outside.
• Overlooking availability breaches. Data loss and lack of access to it are breaches even if no unauthorized person saw the data.
• Lack of documentation of unreported breaches. Article 33(5) GDPR does not require a “register” as such, but documentation of every breach. This means its circumstances, its effects and the remedial action taken, in a form that enables the supervisory authority to verify compliance with that provision. During an inspection, it is this documentation that shows that the decision not to report was a decision, not an oversight.
• Notification to data subjects written in legalistic language. The communication should allow the recipient to understand what happened and what they can do — if it doesn’t, the obligation has been fulfilled formally but not effectively.

Conclusions and next steps

The answer to the title question is resolved in two steps. First comes the qualification of the incident, then the risk assessment for data subjects.

In practice, most problems stem not from the decision itself, but from what precedes it. Therefore, before the next breach, four things need to be decided. These are who in the organization has the right to determine that the controller has become aware of a breach; how the signal from the front line reaches the data protection officer and within what timeframe; according to what criteria the risk to data subjects is assessed, so that two different people reach a similar result; and where the assessment and the justification for the decision are recorded.

An organization that has these four elements makes a reporting decision within a few hours and can later demonstrate it. An organization that does not have them starts building the procedure during the breach — and this, usually, not the incident itself, determines the course of the matter.

Related materials

• How to determine if an organization must appoint a DPO? — a role that conducts risk assessment and maintains contact with the authority in the reporting decision process.
• Where should the board begin preparing for NIS2? — the order of decisions determining whether a parallel obligation to CSIRT runs alongside reporting to the UODO.
• What should a personal data breach register contain? — how to record the outcome of the risk assessment and the reasons for not notifying.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Art. 4(12), Art. 33 and Art. 34, consolidated text — EUR-Lex: eur-lex.europa.eu (access: 2026-08-17)
• Proposal for a Regulation amending, inter alia, Regulation (EU) 2016/679 (Digital Omnibus), COM(2025) 837 — EUR-Lex: eur-lex.europa.eu (access: 2026-08-17)
• Which breaches must be reported to the President of UODO, and which do not require reporting? — Office for Personal Data Protection: uodo.gov.pl (access: 2026-08-17) (in Polish)
• Within what period should a breach be reported to the President of UODO? — Office for Personal Data Protection: uodo.gov.pl (access: 2026-08-17) (in Polish)
• Other obligations and regulations related to breaches — Office for Personal Data Protection: uodo.gov.pl (access: 2026-08-17) (in Polish)
• When, in the event of a breach, should data subjects be notified? Judgment of the Supreme Administrative Court of October 24, 2025, III OSK 1830/22 — Office for Personal Data Protection: uodo.gov.pl (access: 2026-08-17) (in Polish)
• Guidelines 01/2021 on examples regarding personal data breach notification, version 2.0, adopted December 14, 2021 — European Data Protection Board: edpb.europa.eu (access: 2026-08-17)
• Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted March 28, 2023 — European Data Protection Board: edpb.europa.eu (access: 2026-08-17)