How to count the 72 hours for notifying a personal data breach?

Why this question arises at all

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.

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.

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.

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

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.

What has to be established before a decision

When the 72-hour deadline starts

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.

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.

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.

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.

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.

How long the preliminary investigation may last

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.

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.

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.

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.

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.

When the breach is established by the processor

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.

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.

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.

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.

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.

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.

Does the 72-hour deadline run at weekends and on public holidays

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.

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.

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.

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.

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.

The UODO guide lists situations that should not justify a delay. The list is open, because it is introduced with the abbreviation “inter alia”.

• The deadline fell on a weekend or another day off work, and key staff were unavailable.
• The person responsible for the notification was on leave or sick leave, and the controller had not arranged an appropriate substitute.
• Management had no time to approve the notification, although procedures should take account of the need to act without delay.
• The controller was waiting for the completion of an internal investigation into the incident conducted to classify it, or of the assessment of the risk associated with the breach.
• The controller needed additional time to gather all the required information.

For the last item the UODO guide points to a solution. It is an initial notification followed by a supplementary one.

What has to fit within 72 hours

According to the EDPB the controller should assess the likely risk to individuals within this period. Whether notification is required at all depends on that assessment. Article 33(1) waives it where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. According to the EDPB the controller should also determine within the same period the action needed to address the breach.

The risk assessment does not have to wait for the full picture of the event. In Guidelines 01/2021 the EDPB states that the controller should not wait for a detailed forensic examination or for early mitigation steps. A full risk assessment may take place in parallel with the notification.

Article 33(4) GDPR follows the same logic. Where and in so far as it is not possible to provide the information at the same time, it may be provided in phases without undue further delay. Information available at once therefore goes into the first notification. The President of UODO distinguishes three types of notification. They are initial, supplementary and complete notifications. The EDPB recommends informing the authority in the first notification that some information is missing and will be provided later.

Further investigation may show that no breach occurred. The controller may then pass this information to the authority. The EDPB states that there is no penalty for reporting an incident that ultimately turns out not to be a breach.

The 72 hours are not a deadline to be used in full either. The provision puts notification without undue delay first and qualifies the 72-hour limit with the words where feasible. When discussing a ransomware attack in Guidelines 01/2021 the EDPB refers to this deadline and states that exceeding it could be considered ill-advised in any case. Where the level of risk is high, even meeting it may be considered unsatisfactory.

What to do when the 72-hour deadline has passed

Article 33(1) GDPR provides for a notification made after 72 hours. It has to be accompanied by the reasons for the delay. The expiry of the deadline therefore does not remove the obligation to notify but adds a justification to it.

The EDPB allows delayed notification in some cases and gives an example. Within a short time a controller faces a series of similar confidentiality breaches that affect many people in the same way. It becomes aware of the first of them and detects further breaches with different causes before notifying. Instead of notifying each one separately it may prepare a single bundled notification. The guidelines set three conditions for this. The breaches must concern the same type of personal data breached in the same way over a relatively short period. Where different types of data are breached in different ways, each breach is notified separately.

According to the EDPB delayed notifications should not be seen as something that regularly takes place. It adds that a bundled notification may also be made within 72 hours. The President of UODO states in turn that delays should result only from exceptional situations.

How to document the moment of awareness

Article 33(5) GDPR requires all breaches to be documented. The documentation comprises in particular the facts relating to the breach, its effects and the remedial action taken. It has to enable the supervisory authority to verify compliance with Article 33. The President of UODO states that the time of becoming aware of the breach is part of this mandatory documentation.

I recommend recording four timestamps with the time and the name of the person who recorded them.

1. The first signal and its source.
2. The start of the preliminary investigation.
3. Becoming aware of the breach together with the findings that decided it.
4. Sending the notification and each supplement to it.

A record of becoming aware with its reasons makes it possible to show the authority why the deadline was counted from a given hour. The other elements of the entry are described in What should a personal data breach register contain?.

Timeline of a single breach

Moment	What it means for the deadline	Basis	Exceptions and limitations	Applies from
Occurrence of the event	the deadline does not run	Article 33(1) GDPR	an event without effect on personal data is not a breach within the meaning of Article 4(12)	25 May 2018
First signal	the deadline usually does not run yet, and the controller may carry out a short preliminary investigation	EDPB Guidelines 9/2022, paragraphs 33, 34 and 36	with clear evidence of a breach the controller becomes aware immediately, and the investigation should in most cases be completed soon	Guidelines version 2.0 from 28 March 2023
Controller becomes aware	the deadline starts to run	Article 33(1) GDPR, EDPB Guidelines 9/2022, paragraph 31	no obligation to notify where a risk to individuals is unlikely	provision from 25 May 2018, Guidelines version 2.0 from 28 March 2023
Information from the processor	in principle the moment the controller becomes aware	Article 33(2) GDPR, EDPB Guidelines 9/2022, paragraph 44, UODO guide, section 5.2	according to the EDPB the controller’s own findings, for example about a copy of the data, may affect whether notification is required, and according to the UODO guide they may rule out awareness of a breach	provision from 25 May 2018, Guidelines version 2.0 from 28 March 2023, UODO guide version of 20 February 2025
Expiry of 72 hours	notification still required, with reasons for the delay	Article 33(1), second sentence, GDPR, EDPB Guidelines 9/2022, paragraphs 62 to 65	delay acceptable in some cases, for example with a bundled notification of a series of similar breaches	provision from 25 May 2018, Guidelines version 2.0 from 28 March 2023

Common mistakes

• Counting the deadline from board approval. The deadline runs from becoming aware of the breach. The UODO guide lists management’s lack of time among the circumstances that do not justify a delay.

• Waiting for the forensic report. According to the EDPB the risk assessment should not wait for a detailed examination. Information can be provided in phases.

• Moving the deadline to the next working day. According to the President of UODO the notification is made regardless of days off work.

• Treating information from the processor as a preliminary rumour. According to the EDPB the controller has in principle become aware of the breach from that moment. According to the EDPB the controller’s own findings, for example about a copy of the data, may affect whether notification is required. According to the UODO guide they may rule out awareness itself.

• Applying the 72 hours to communication to data subjects. Article 34(1) GDPR requires communication to data subjects without undue delay where the breach is likely to result in a high risk. This provision gives no number of hours.

• A single date in the procedure for the GDPR and the KSC Act. The deadline under Article 33(1) GDPR runs from becoming aware of the breach, and the deadline under Article 11(1)(4a) of the KSC Act from detecting the significant incident.

Conclusions and next steps

On the day of the breach the organisation carries out what it has settled beforehand. In my assessment most time is lost between the first signal and becoming aware, because the provision does not measure that stretch in hours.

I recommend five steps that put the counting of the deadline in order. None of them is a requirement written expressly in the legislation.

1. Name a person who receives incident signals around the clock and a deputy.
2. Establish who becomes aware of breaches on behalf of the controller and on the basis of what findings.
3. Record in the procedure that the short preliminary investigation begins immediately after the signal.
4. Prepare a template initial notification and name the person authorised to send it on days off work, also through the emergency channel.
5. Review data processing agreements for the deadline and channel for processors to notify breaches.

Related materials

• Does every data breach need to be reported? — the notification threshold and the assessment of risk to individuals, which decides whether the deadline has to be counted at all.
• What should a personal data breach register contain? — where to record the moment of awareness and its reasons.
• What to do after detecting an incident? — the order of actions in the first day, when several deadlines run at once.
• What does a significant incident report to a CSIRT contain? — the second 72-hour deadline, counted from detection.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), consolidated version — Article 4(12), Article 26(1), Article 28(3)(f), Article 33, Article 34(1) and Article 99(2) — eur-lex.europa.eu (accessed September 19, 2026).
• Regulation (EU) 2016/679 (GDPR), version as published in OJ EU L 119 of 4 May 2016 — recital 87 — eur-lex.europa.eu (accessed September 19, 2026).
• Act of 5 July 2018 on the National Cybersecurity System, consolidated text as at 7 July 2026 — Article 8i(1) and Article 11(1)(4) and (4a) and (1a) (in Polish) — isap.sejm.gov.pl (accessed September 19, 2026).
• Regulation (EEC, Euratom) No 1182/71 of the Council of 3 June 1971 determining the rules applicable to periods, dates and time limits — Article 1 and Article 3(1) to (5) — eur-lex.europa.eu (accessed September 19, 2026).
• Personal Data Protection Office (UODO), Guide on personal data breaches, version of 20 February 2025 — sections 5.2 and 9.2 (in Polish) — uodo.gov.pl (accessed September 19, 2026).
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0 adopted 28 March 2023 — paragraphs 31 to 48, 53 and 56 to 65 — edpb.europa.eu (accessed September 19, 2026).
• European Data Protection Board, Guidelines 01/2021 on Examples regarding Personal Data Breach Notification, version 2.0 adopted 14 December 2021 — paragraphs 8, 9 and 24 — edpb.europa.eu (accessed September 19, 2026).