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. Blocked login, detected and repelled phishing attempt, server failure without data loss — these are incidents handled by the security team, but they do not trigger GDPR obligations. 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’s discovery of the breach, not from the moment the incident occurred. In large organizations, most of this time is usually consumed by the information flow: 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: 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 discovered the breach

Discovery 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. The controller’s deadline runs from the moment they received this information — 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: 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 risk is unlikely. 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: when the data was protected by measures rendering it unintelligible to unauthorized persons, 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.

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: obligations towards CSIRT for entities covered by the National Cybersecurity System Act, sectoral obligations arising from DORA, telecommunications 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 the risk to data subjects is unlikely	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, within 72 hours of discovery	No	Entry in the register, report, correspondence with the authority, remedial actions
Breach with high risk	Yes, within 72 hours of discovery	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 the discovery. 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; 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 a register of unreported breaches. The register covers all breaches. During an inspection, it 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, the qualification of the incident, then the risk assessment for data subjects. The reporting obligation is a rule from which an organization can only deviate based on a documented assessment — not the other way around.

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: who in the organization has the right to determine that a breach has been discovered; 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.

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)