The Act gives you seventy-two hours to tell the Commission about a breach. Almost every company that misses it did not miss it by three days. They missed it by arguing for two.
Because the seventy-two hours do not start when you are sure. They start when somebody in your organisation becomes aware — and awareness is a much earlier moment than the one most incident processes are built around.
The clock starts before the meeting
Here is the sequence that actually happens. A support engineer notices something odd on a Tuesday morning. She mentions it in a channel. Somebody senior asks whether it is really a breach. A call is arranged for the afternoon. By the time anyone writes down a start time, it is Wednesday.
The regulator's clock, meanwhile, started on Tuesday morning. Not at the call, not at the confirmation, not when legal agreed. At the moment the engineer knew.
The most expensive hours of any breach are the ones spent deciding whether it counts as one.
NDPA §40 · the awareness testThis is why "we notified within 72 hours of confirming the incident" is not a defence. It answers a question nobody asked. The only timestamp that matters is the first one — and if you cannot produce it, the Commission will assume the earliest plausible moment rather than the most convenient.
What awareness actually means
Awareness is not certainty. It is a reasonable degree of confidence that personal data has been compromised. You do not need to know the scope, the cause, or the number of people affected. You need to have grounds to believe something happened.
Which has a practical consequence most teams find uncomfortable: you will often have to notify while still investigating. The Act anticipates this. A first notification that says what you know and commits to a follow-up is entirely normal, and vastly better than a complete one that arrives on day five.
There are two notifications, not one
The first goes to the Commission, within seventy-two hours. The second goes to the people whose data it was — and that one is required only where the breach is likely to result in high risk to them.
Volume alone can trigger it. So can the nature of the data: financial identifiers, health information, anything that lets somebody impersonate the person. The test is about consequence to them, not embarrassment to you, and the distinction gets blurred in the room more often than anywhere else in this process.
A worked example, from a real register
This is an incident from a live workspace, with the identifying details removed. It is unremarkable, which is exactly why it is instructive — no attacker, no sophisticated compromise, just a support engineer using a tool the way it was designed.
INC-2026-0006 · medium severity · reported
A support agent pasted BVNs into a chat tool
12 JulyFound. An engineer reviewing a thread notices bank verification numbers in plain text, in a tool that is not on the processor register. Eighteen customers.
Same dayThe clock starts here. Not when the severity was agreed, not when the tool was audited.
14 JulyReported to the Commission, inside the window, with the scope still being established.
OutcomeEighteen people told directly. The chat tool now sits on the register with a processing agreement, which is the fix that stops the next one.
Two days, not three. And the notification went out while the investigation was still open — because waiting for a complete picture would have cost more than sending an incomplete one.
The incidents that need no notification at all
Not everything is reportable, and treating everything as reportable is its own failure — it trains people to stop escalating. A misconfigured storage bucket with access logs proving nobody reached it is a control failure worth recording and fixing. It is not a notifiable breach.
A phishing email that nobody acted on is the same. What matters is that both were logged, assessed, and closed with a reason. A register showing two closed incidents with no notification required is a stronger document than one showing none at all, because it proves somebody was paying attention.
What to do before it happens
The work that decides whether you make the window happens months earlier. Three things, in order of how often they are missing.
Write down who can start the clock. Not who decides severity — who is empowered to say "this is an incident" and have the timestamp recorded. If that person is a committee, you have already lost a day.
Keep the processor register current. Half of the incidents in this category involve a tool that nobody registered. You cannot assess a breach in a system you did not know was holding data.
Draft the notification now. The Commission's form asks for things you will not want to be assembling under pressure. Filling in the parts that never change is an afternoon's work, done calmly, once.
None of this is difficult. It is simply the kind of work that never wins an argument for priority until the Tuesday morning when somebody notices something odd.