Two stages, one clock, and it starts when you find out

Two timestamps, and only one of them starts anything

Every incident record carries two times. The incident time is when the thing happened — when the bucket was left open, when the credential leaked. The detection time is when you became aware of it. They are frequently weeks apart and people record them the wrong way round under pressure.

The clock runs from detection. Seventy-two hours from the moment of awareness to the detailed report to the Board — an outer limit rather than a target, because the first intimation to the Board and to affected people is due without delay and should not wait for the report to be ready. The incident time is captured because it matters to the investigation, the affected population and the root cause, but it starts nothing.

That is the right reading of the obligation and it is also the honest one operationally. You cannot report to a regulator about something you do not know about, and a system that started the clock at the incident time would mark every historic discovery as already overdue on creation, which teaches people to record the detection time as the incident time to make the badge go green.

Five warning states, and what amber actually means

The clock produces one of five states, which is more than most dashboards bother with and each of them means something different for what you should do next.

• Met — notified on or before the deadline. Nothing further on the clock.
• Late — notified, but after the deadline. The record keeps the fact rather than hiding it, because a late notification that was made is a materially different position from one that was not.
• Red — not notified and the deadline has passed. This is the one that should be on a screen somebody is looking at.
• Amber — not notified, twenty-four hours or less remaining. This is the only twenty-four in the module and it is a warning threshold, not a second deadline.
• Green — not notified, more than twenty-four hours remaining.

There is no reportability engine, and there should not be

Nothing in the system decides whether an incident is a reportable personal data breach. There is no flag, no scoring model, no automatic verdict. Creating the record is the decision, and the clock starts unconditionally from there.

That is a deliberate refusal rather than a missing feature. Whether a given incident is a reportable breach is a judgement that depends on facts inside your organisation — what data was involved, who could actually reach it, what compensating controls held. A product that returned an automatic answer would be asserting something it is not in a position to conclude, and the organisation would carry the consequence of its being wrong.

What the platform does instead is make the judgement cheap to record and impossible to lose: who decided, when, on what facts, and what happened next.

Notifying principals is a list, not a broadcast

The notification endpoint requires an explicit list of recipients. Sending an empty list does not mean everybody — it is refused, with a message saying that the obligation is per-principal notification rather than a bulk broadcast to every customer in the tenant.

That refusal is the single most opinionated thing in this module. The path of least resistance after a breach is to mail the whole customer table, and it is wrong twice over: it tells people unaffected by an incident that their data may have been exposed, and it destroys your ability to show afterwards who you actually notified and why.

The rest of the controls follow from the same instinct. A subject line and a body are both required, with a minimum body length enforced at the API rather than only in the form, so an integration cannot push a near-empty notice. Addresses are normalised and deduplicated. The list is capped. Sends are counted individually, with successes and failures reported back.

And the failure behaviour is the part worth quoting: if every send fails, the notification timestamp is deliberately not stamped. Recording that principals were notified when nothing was delivered would be a false compliance record, and a false compliance record is worse than an obvious gap because it is the one you will rely on.

Seven audiences, because the Board is not the only reader

A breach produces more than one communication and they cannot be the same text. Notification drafts are generated for seven audiences: the Data Protection Board, affected data principals, the internal incident response team, the board or senior leadership, affected vendors and sub-processors, joint data fiduciaries, and employee awareness.

Each draft is generated once and never regenerated over an existing one, so an edited draft is safe. Each tracks its own state — draft, edited, sent or skipped — and skipped is a first-class option, because "we considered the joint fiduciaries and there were none" is a recorded decision while an empty template is an unanswered question.

Where no model provider is configured, the drafts fall back to a structured summary of the facts on the record. That is deliberately not a failure state: during an incident the thing you need is the facts assembled in one place, and a generated paragraph is a convenience on top of that.

Board notification is a reference, not a checkbox

Marking the Board notified takes the acknowledgement reference from the Board's own portal. That reference is the record, and its timestamp is what the regulator will treat as the notification time.

This is a small design decision with a large audit consequence. A checkbox marked by whoever remembered proves nothing. A stored reference from the receiving system ties your record to theirs, which is the difference between asserting you notified and being able to show it.

Closing requires a root cause, and the API enforces it

The lifecycle runs open, contained, notifying, notified, closed. Containment is stamped with its own timestamp and notes. Closing requires root-cause notes, and empty notes are refused with a four-hundred at the API — not a form validation that a direct caller could route around.

That is the strictest hard gate in the whole platform, and it is there because closing a breach without a root cause is how the same breach happens again. Corrective actions live in the same record alongside the immediate measures, and the task the system opened when the incident was created — the one naming the Board deadline — closes when the notification is made rather than when somebody ticks it off.

Every action appends to a timeline: what happened, who did it, when, with notes. During an incident nobody writes the chronology. Afterwards, everybody needs it.