GDPR breach register and the 72-hour deadline: what to record and how to count the hours

This guide points to the rules as published; it is not legal advice. Whether a particular incident has to be notified is a judgement for you and your adviser.

A laptop left on a train, an invoice sent to the wrong customer, a shared folder that was public for a week, a ransom note on the office server. Each is a personal data breach under the GDPR, and each starts a clock: in most cases the supervisory authority has to hear about it within 72 hours. Small businesses tend to discover two things on the day. First, nobody wrote down when the problem was found, so nobody knows when the 72 hours end. Second, the GDPR also wants a record of the breaches that are not notified, and there is none. This guide shows what the Regulation asks for, what to record, and how to count the 72 hours correctly, with a short Python sample.

#What the GDPR asks

• Notify the authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. A later notification has to give the reasons for the delay (Article 33(1)). In Bulgaria the authority is the Commission for Personal Data Protection (КЗЛД).
• A processor, such as your hosting or payroll provider, tells you without undue delay after it becomes aware (Article 33(2)). Your contract with it should say how.
• The notification describes at least the nature of the breach with the approximate categories and number of people and records, a contact point, the likely consequences, and the measures taken or proposed (Article 33(3)). What is not known yet can follow in phases (Article 33(4)).
• Record every breach, notified or not: the facts, the effects and the remedial action, so that the authority can check what you did (Article 33(5)).
• Tell the people affected without undue delay when the breach is likely to result in a high risk to them (Article 34(1)), unless one of the exceptions of Article 34(3) applies, for example data that was encrypted and unreadable to whoever got it.

#When the clock starts

The 72 hours run from the moment the controller becomes aware. The European Data Protection Board's guidelines on breach notification say a controller is aware when it has a reasonable degree of certainty that a security incident has led to personal data being compromised. A short investigation to establish that is allowed, but it should start at once. The guidelines give examples: a lost USB key with unencrypted data is known the moment it is noticed missing, because its availability is lost even if nobody can tell whether it was read; a customer who forwards someone else's data with evidence makes you aware at once.

So the first field of a register is not "date of breach" but "when we became aware", with the time and the time zone, and the second is how you found out.

#What to record

The Regulation leaves the form to you. The guidelines name the elements that should always be there, and they also recommend recording the reasons for each decision, especially the reasons for not notifying. A register that answers the authority's questions has columns like these:

• when you became aware, how, and who found it;
• what happened and when it started, if known;
• the kinds of data and of people affected, and approximately how many;
• the likely consequences for those people;
• the measures taken to stop it and to reduce its effects;
• the risk you assessed, and why: none likely, a risk, or a high risk;
• whether and when the authority was notified, its reference number, and the reasons if it was late;
• whether the people affected were told, when and how, or which exception you relied on;
• the processor involved, if any, and when it told you.

The guidelines also say the breach record can be part of your record of processing activities under Article 30, as long as the breaches can be told apart and extracted on request.

#72 hours are hours, not days

The Regulation counts hours. Weekends and public holidays are inside them, so a breach found on Friday afternoon is due on Monday afternoon. There is a quieter trap: when the clocks change, three calendar days are not 72 hours. Count in UTC and convert back:

import math
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo

SOFIA = ZoneInfo("Europe/Sofia")


def deadline(aware_at: datetime) -> datetime:
    """72 hours after the controller became aware, counted in real hours (through UTC)."""
    return (aware_at.astimezone(timezone.utc) + timedelta(hours=72)).astimezone(SOFIA)


def status(aware_at: datetime, risk: str, notified_at: datetime | None, now: datetime) -> str:
    """risk: "unlikely" (record only), "risk" (notify the authority) or "high" (also tell the people)."""
    if risk == "unlikely":
        return "No notification needed: keep it in the register with the reasons."
    due = deadline(aware_at)
    if notified_at is None:
        if now.timestamp() > due.timestamp():
            return f"OVERDUE since {due:%d.%m %H:%M}: notify now and give the reasons for the delay."
        hours = (due.timestamp() - now.timestamp()) / 3600
        return f"Notify the authority by {due:%d.%m %H:%M} ({hours:.1f} h left)."
    late = (notified_at.timestamp() - due.timestamp()) / 3600
    if late <= 0:
        return "Notified in time."
    return f"Notified {math.ceil(late)} h late: the notification must give the reasons for the delay."

We ran it for a breach found on Friday 23 October 2026 at 16:30 in Sofia. Summer time ends on Sunday 25 October, when the clocks go back from 04:00 to 03:00, so the deadline is Monday 26 October at 15:30. Adding three days on the calendar gives 16:30, which is 73 real hours. On Saturday at 10:00 the sample says "Notify the authority by 26.10 15:30 (54.5 h left)"; a notification on Monday at 18:10 is "Notified 3 h late", with a reminder that the notification has to give the reasons; and a breach assessed as unlikely to cause a risk is "No notification needed: keep it in the register with the reasons". Subtracting timestamps rather than datetimes matters in Python: two datetimes with the same time zone object are compared on the wall clock, not in real time.

A spreadsheet has the same problem, because its dates and times have no time zone. Add three days in a cell and you are an hour late on the last weekend of October and an hour early on the last weekend of March. Either note that in the sheet or keep the deadline column in UTC.

#Assessing the risk

Whether to notify depends on the risk to people, not on the size of the incident. The guidelines suggest looking at the type of breach, the kind and amount of data, how easy it is to identify the people, how severe the consequences can be, special categories of data, vulnerable people, and how many are affected; ENISA publishes a method for rating severity. A sent email with one customer's order details is different from a leaked list of patients. Record the reasoning either way.

#A register that checks the deadline for you

We made Pazilka, a GDPR kit for small businesses in Bulgaria, in Bulgarian and English. Its registers workbook for Excel and LibreOffice holds the record of processing activities, the breaches, data subject requests and retention periods, and checks itself with plain formulas: for each breach it shows the 72-hour deadline, whether it was met and by how many hours it was missed, overdue open breaches, and a high risk without telling the people affected. Eight document templates come with it, among them a breach procedure with a notification form that gathers the content of Article 33(3). The breaches sheet counts the 72 hours in real time through UTC, so its deadline is right also on the weekends when the clocks change. It was tested by letting LibreOffice calculate 22 workbooks and comparing every check with an independent Python model, the legal content was not reviewed by a lawyer, and it is listed as Coming soon.

For the other GDPR clock, the one month for answering access and erasure requests, see our guide to GDPR requests in Laravel.

#Frequently asked questions

Do weekends count towards the 72 hours?

Yes. The GDPR counts hours, not working days, so a breach found on Friday at 16:30 is due on Monday at 16:30, or 15:30 if the clocks went back that weekend.

Do I have to record a breach that I do not notify?

Yes. Article 33(5) asks you to document every personal data breach, with the facts, the effects and the remedial action, and the guidelines recommend recording why you decided not to notify.

What if I do not have all the details within 72 hours?

Notify with what you know and send the rest in phases, without further undue delay. If you notify after 72 hours, give the reasons for the delay.

When do I have to tell the people affected?

When the breach is likely to result in a high risk to them, unless an exception of Article 34(3) applies, such as encryption that made the data unreadable.

#Sources

• Regulation (EU) 2016/679 (GDPR): Articles 33 and 34
• EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0
• Commission for Personal Data Protection (Комисия за защита на личните данни)
• ENISA: Recommendations for a methodology of the assessment of severity of personal data breaches