{"id":5629,"date":"2026-09-19T23:29:55","date_gmt":"2026-09-19T21:29:55","guid":{"rendered":"https:\/\/www.lablogic.pl\/?p=5629"},"modified":"2026-09-19T23:42:50","modified_gmt":"2026-09-19T21:42:50","slug":"how-to-count-72-hours-for-breach-notification","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/how-to-count-72-hours-for-breach-notification\/","title":{"rendered":"How to count the 72 hours for notifying a personal data breach?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for DPOs and incident response teams \u2022 published September 19, 2026 \u2022 12 min read<\/p>\n\n\n\n

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

Short answer<\/h2>\n\n\n\n

The 72-hour deadline runs from the moment the controller becomes aware of the breach. It is not counted from the event itself and usually not from the first signal about it. According to the EDPB the controller becomes aware when it has a reasonable degree of certainty about the breach. What counts is certainty that a security incident has led to personal data being compromised. The hours also run on days off work, and the first requirement of the provision is notification without undue delay.<\/p>\n<\/div>\n\n\n\n

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

Article 33(1) GDPR links the deadline to the moment of becoming aware of the breach. The Regulation does not, however, define that notion. The definitions in Article 4 cover the personal data breach itself in point 12. They do not cover the moment of becoming aware of it.<\/p>\n\n\n\n

In a medium-sized or large organisation this moment is rarely a single point. An employee notices an irregularity and passes it to the IT department. The security team verifies it and passes the result to the data protection officer. The officer assesses the effects for the data, and the board signs the notification. Each of these people learns about the event at a different hour. In my assessment the procedure should therefore settle whose knowledge starts the deadline.<\/p>\n\n\n\n

The second source of doubt is a second 72-hour deadline. An essential or important entity reports a significant incident without delay and no later than 72 hours from the moment it was detected. This is laid down in Article 11(1)(4a) of the Polish Act on the National Cybersecurity System (KSC). The Act provides for derogations from this rule. A trust service provider has 24 hours to report under Article 11(1a). Article 8i(1) excludes entities from the banking and financial market infrastructure sectors from the provisions on reporting significant incidents, with the exceptions listed in that provision.<\/p>\n\n\n\n

Detecting an incident and becoming aware of a breach are two different moments, so for a single event the two deadlines may expire at different hours. The addressee of the report and the early warning submitted within 24 hours are described in What does a significant incident report to a CSIRT contain?<\/a>.<\/p>\n\n\n\n

The third source is organisational. Notification procedures usually follow the rhythm of office work, with document circulation and management approval. The deadline under Article 33(1) is meanwhile counted in hours.<\/p>\n\n\n\n

What has to be established before a decision<\/h2>\n\n\n\n

When the 72-hour deadline starts<\/h3>\n\n\n\n

The starting point is becoming aware of the breach, not its occurrence. According to the EDPB the controller becomes aware at the moment it has a reasonable degree of certainty about two circumstances. A security incident has occurred and that incident has led to personal data being compromised.<\/p>\n\n\n\n

The President of UODO describes becoming aware as the moment at which the controller obtains sufficient knowledge of an incident to consider it a personal data breach. The UODO guide links it to awareness of three circumstances. The event is a security incident and it concerns personal data being processed. It may also lead to the effects described in the definition of a breach.<\/p>\n\n\n\n

The two approaches are not identical. The EDPB speaks of an incident that has led to personal data being compromised. The UODO guide speaks of an event that may lead to this. In my assessment it is safer to follow the approach of the guide when documenting the deadline, because it is the President of UODO who will assess whether the notification arrived in time.<\/p>\n\n\n\n

The criterion concerns certainty about the breach itself. Where the fact of the breach is not in doubt but its scale is not yet known, the EDPB considers notification in phases a safe method. The same applies to uncertainty about the type of breach. The EDPB illustrates this with a lost USB key holding unencrypted data. The controller often cannot establish whether anyone gained access to the data. There is, however, a reasonable degree of certainty that an availability breach has occurred. Such a case has to be notified, and the controller becomes aware at the moment it realised the USB key had been lost.<\/p>\n\n\n\n

Becoming aware does not take the form of a separate decision. According to the President of UODO the controller does not have to take any additional steps to establish the breach formally. It should, however, record precisely the time at which this happened.<\/p>\n\n\n\n

How long the preliminary investigation may last<\/h3>\n\n\n\n

Sometimes the controller becomes aware immediately. The EDPB gives the example of a third party that provides the controller with evidence of an unauthorised disclosure of data. In other cases a short preliminary investigation, which the controller may carry out, falls between the first signal and becoming aware. According to the EDPB the controller may not be regarded as aware during that investigation. It expects, however, that the investigation should begin as soon as possible. It is meant to establish with a reasonable degree of certainty whether a breach has taken place.<\/p>\n\n\n\n

The length of this investigation also has a limit. According to the EDPB the preliminary actions should in most cases be completed soon after the initial alert. The initial alert is the moment when the controller or processor suspects a security incident that may involve personal data. It should take longer than this only in exceptional cases.<\/p>\n\n\n\n

Once the breach itself has been established, the EDPB allows a more detailed investigation. The preliminary investigation is therefore not an inquiry carried through to its end. Among the circumstances that do not justify a delay the President of UODO lists waiting for the completion of an internal investigation into the incident conducted to classify it. In my assessment the two positions can be reconciled. A brief check of the facts is acceptable, but waiting for the classification inquiry to end does not justify a delayed notification.<\/p>\n\n\n\n

According to recital 87 GDPR it should be ascertained whether all appropriate technological protection and organisational measures have been implemented to establish immediately whether a breach has taken place and to inform promptly the supervisory authority and the data subject. The EDPB links this to an obligation to maintain the ability to establish breaches in time. It also warns of the consequences of delay. Failing to act in a timely manner when it becomes apparent that a breach did occur could be considered a failure to notify.<\/p>\n\n\n\n

In my assessment the time a signal spends circulating in the organisation without a person responsible for assessing it is therefore not neutral. It is a gap in the ability that the controller has to maintain.<\/p>\n\n\n\n

When the breach is established by the processor<\/h3>\n\n\n\n

Article 33(2) GDPR requires the processor to notify the controller without undue delay after becoming aware of a breach. The EDPB points out that the Regulation does not set an explicit time limit for this notification. It therefore recommends prompt notification and the provision of further information in phases.<\/p>\n\n\n\n

The processor does not need to assess the risk before notifying. According to the EDPB it only has to establish whether a breach has occurred and notify the controller. Assessing the risk is the controller’s task. The guidelines also take the view that in principle the controller becomes aware at the moment it receives this information from the processor.<\/p>\n\n\n\n

The words in principle have a practical meaning. The EDPB notes that the processor may not know all the relevant facts. An example is the controller still holding a copy of personal data destroyed or lost by the processor. The controller may therefore carry out its own investigation, and its result may affect whether notification is required. The President of UODO stresses that the controller remains responsible for verifying the information and for the final analysis and classification of the incident.<\/p>\n\n\n\n

The UODO guide treats a similar situation differently from the EDPB. In one of its examples a fire destroyed the servers holding backups at the processor. The processor established an availability breach and informed the controller. The controller held its own complete copy of those data and according to the guide rightly did not become aware of a breach. In a similar situation the EDPB speaks of the effect of the copy on the obligation to notify, while the guide speaks of no awareness at all.<\/p>\n\n\n\n

Article 28(3)(f) GDPR requires the contract or other legal act to provide for the processor’s assistance in complying with the obligations under Articles 32 to 36. That assistance takes into account the nature of the processing and the information available to the processor. The EDPB states that the contract may include a requirement for early notification of breaches. Where the same incident affects several controllers, the processor notifies each of them. It may also notify the authority on behalf of the controller if the controller has given it an authorisation set out in the contract. According to the EDPB legal responsibility for the notification still remains with the controller. I recommend writing into the contract a deadline counted in hours and a channel through which the notification is to arrive outside working hours.<\/p>\n\n\n\n

For joint controllers Article 26(1) GDPR requires their respective responsibilities to be set out in an arrangement between them, unless they are determined by Union or Member State law to which the controllers are subject. The EDPB recommends that the arrangement should name the controller responsible for notifying breaches.<\/p>\n\n\n\n

Does the 72-hour deadline run at weekends and on public holidays<\/h3>\n\n\n\n

Yes. According to the President of UODO the 72-hour deadline runs regardless of days off work. A breach is notified as soon as possible and no later than 72 hours after becoming aware of it. The UODO guide adds that the GDPR does not provide for the deadline being suspended because of a weekend and the unavailability of key staff.<\/p>\n\n\n\n

On the 72-hour deadline the EDPB refers in a footnote to Regulation No 1182\/71 determining the rules applicable to periods, dates and time limits. Under its Article 3(3) the periods include public holidays, Sundays and Saturdays. The exceptions are cases expressly excepted and periods expressed in working days. Article 3(4) moves the end of a period to the following working day where the last day falls on a public holiday, Sunday or Saturday. It concerns, however, periods expressed otherwise than in hours. Article 3(5) provides, in turn, that any period of two days or more includes at least two working days. The Regulation does not state expressly whether this rule extends a period counted in hours. Neither the guidelines nor the UODO guide discuss it, so in my assessment a procedure should not rely on it.<\/p>\n\n\n\n

The Regulation also indicates from which moment the hours are counted. Where a period expressed in hours is calculated from the moment at which an event occurs, Article 3(1) does not count the hour during which the event occurred. Subject to paragraphs 1 and 4 such a period starts at the beginning of the first hour and ends with the expiry of the last hour of the period, under Article 3(2)(a). When a controller becomes aware of a breach on a Wednesday at 14.20, a period counted under these rules starts at 15.00 and ends on Saturday at 15.00.<\/p>\n\n\n\n

Save as otherwise provided, Article 1 however limits the Regulation to acts of the Council or the Commission passed under the EEC Treaty or the Euratom Treaty. The GDPR was adopted by the European Parliament and the Council on the basis of Article 16 of the Treaty on the Functioning of the European Union. The guidelines do not explain how this reference should be understood. In my assessment it is safer to count the deadline from the minute of becoming aware, because the first requirement is in any case notification without undue delay.<\/p>\n\n\n\n

In exceptional situations, for example when the electronic notification systems fail, the UODO guide allows a temporary notification by email to kancelaria@uodo.gov.pl. Such a notification has to be confirmed at the earliest possible date by one of the standard methods.<\/p>\n\n\n\n

The UODO guide lists situations that should not justify a delay. The list is open, because it is introduced with the abbreviation \u201cinter alia\u201d.<\/p>\n\n\n\n