The breach clock starts whether you are ready or not

What §8(6) requires the moment you become aware

Section 8(6) requires a Data Fiduciary, in the event of a personal data breach, to give the Board and each affected data principal intimation in the prescribed form and manner. Rule 7 prescribes it in two stages: an intimation to each affected principal and to the Board without delay, then a detailed report to the Board within seventy-two hours of becoming aware, or longer if the Board allows it. Neither stage waits for the investigation to finish, which is the part that surprises people: you will be telling the regulator about something you do not yet fully understand.

The record therefore separates when the incident happened from when you found out. The clock runs from the detection timestamp, and the original incident time is a separate field, so a breach that began three weeks ago and was noticed this morning is recorded truthfully instead of being backdated into automatic failure.

One clock, and the timestamp that starts it

The deadline the platform counts down is the Rule 7 detailed report to the Board: seventy-two hours from detection. It is a fixed constant, not a per-tenant setting, and it is the single number the interface counts down. Its state is shown as green with more than a day left, amber inside the last day, red once it has passed, and after notification as either met or late — so the record says afterwards whether you made it, not just when you acted.

Creating an incident immediately creates the task to notify the Board, due at the same moment, and for higher-severity incidents a second task to notify affected principals. Recording either notification completes the matching task. This is the bit that matters at two in the morning: the clock and the ownership are created by the act of reporting, so nobody has to remember to set them up.

The without-delay intimations have no number in the Rules, so the platform does not invent a countdown for them: it records when the Board and the affected principals were told, and the seventy-two hours is the clock for the detailed report. Do not read those seventy-two hours as permission to wait — the first intimation is due as soon as you can make it.

Notifying affected principals, one at a time and on purpose

The notice itself can be drafted for you from the incident record and then edited — because a notice written by a model and sent unread is how an incident becomes two incidents. Sending requires an explicit list of recipients. A request to notify everyone in the tenant is refused, with the refusal saying that the obligation is to each affected data principal rather than to a mailing list.

Sends are individual, deduplicated, capped per submission, and the response reports how many succeeded and how many failed. The notified timestamp is only stamped if at least one send actually got through, so the record cannot claim a notification that never left the building. The body has a minimum length, which sounds trivial until you have seen a regulatory notice that said "we had an incident".

Alongside that, drafts can be generated for seven audiences at once — the Board, affected principals, the internal response team, your own board, vendors, joint fiduciaries and employees — each idempotent per audience and each editable. Everything outside Board and principal notification is marked as sent by an operator, because those messages go through your own channels.

Containment, root cause, and what closing actually requires

The lifecycle runs open, contained, notifying, notified, closed. Containment records its own timestamp and notes, and the record carries the immediate measures taken, the systems affected, the detection source and the suspected vector alongside severity, category, affected count and data categories. A linked vendor turns a supplier incident into something you can find again next time that supplier comes up for review.

Closing is gated. An incident cannot be closed without root-cause notes, which is a small rule with a large effect: it stops the register filling with closed incidents that record what happened and never why. Every transition is written to an append-only timeline with the actor who made it and any notes attached.

Be aware of what is not enforced. The lifecycle order is not policed, so notifying principals before the Board will move the status forward in a way that is legal but does not reflect the order you probably intended. And there is no dedicated corrective-action field beyond the root-cause notes and the linked tasks — if you need a tracked remediation plan per incident, build it in tasks rather than assuming a form.

The standing register

Incidents accumulate into a register with counts by status and by clock state. It answers the questions you get asked out of order: how many incidents this year, how many were reportable, how many were notified inside the window, how many involved a vendor, and what the root cause was each time. The reporting export covers the breach module alongside consent and grievance.

That register is also the honest input to your readiness assessment. An organisation with zero recorded incidents either has excellent controls or no detection, and the register is usually the fastest way to tell which.

Where breach response breaks at two in the morning

These are failures of ownership and timestamps, not of tooling.

• Nobody owns the clock. The engineer who found it is containing it, the manager who can authorise a notification is asleep, and the seventy-two hours is running against a detection time nobody has written down yet.
• The detection timestamp is set to when the incident was formally reported rather than when someone first knew. That is the single field most likely to be wrong, and the one a regulator will test against your own logs.
• The affected-principal list is assembled from a query nobody validates, so the notification goes to everyone in a table rather than to the people actually affected — which is its own disclosure.
• Notification is treated as the end. The incident stays open for weeks because closing needs a root cause and nobody has been asked for one.
• A vendor tells you about their breach in a phone call and it never becomes your incident, even though your data principals are the affected ones.
• The first draft of the principal notice is sent unedited, so a template phrase reaches a hundred thousand people.

What the platform cannot decide for you

It does not decide whether an event is a personal data breach. That judgement, and the decision to notify, belongs to your incident response and your counsel. The platform records the decision, who made it and when.

It does not file anything with the Data Protection Board. Recording the notification stores your reference and the timestamp; submitting through the Board's own channel is a human action, and no vendor can perform it for you.

It does not find the affected people. There is no automatic discovery of which data principals an incident touched; you supply the recipient list, and the platform refuses to substitute a broadcast for it.

It notifies by email only. There is no SMS or messaging channel for breach notices, so where your population is reachable only by phone, plan that route separately.