Personal-data breach register
For adminsPersonal-data breach register
Section titled “Personal-data breach register”When personal data is lost, exposed, altered or made unavailable, UK GDPR Article 33 requires the controller to notify the ICO within 72 hours of becoming aware of it (unless the breach is unlikely to be a risk to people), and Article 34 requires affected individuals to be told where the risk to them is high. This register is where the Designated Protection Officer (DPO) records each breach, tracks the clock, and produces the ICO submission.
Find it under Governance → Manage → Breach register (served at /agent/governance/breach-register). The legacy URL /admin/breach-register redirects there automatically.
Permission
Section titled “Permission”The breach register is gated on governance::dpo — the same permission as the DSAR and ROPA consoles. A breach record can name suspect insiders and pre-disclosure mitigation detail, so it isn’t visible to everyone who can read the audit log. A trust admin passes the gate automatically.
The 72-hour clock
Section titled “The 72-hour clock”The dashboard lists every open, contained and notified-but-not-closed breach, each with a live countdown to its Article 33 deadline — 72 hours from the time the breach was discovered. Once the deadline passes the clock shows as overdue; Article 33 then requires a documented justification for the delay, and the dashboard surfaces this as a hard banner. Closed breaches drop off the dashboard but are preserved (soft-deleted, plus the audit log) for inspection-day retrieval.
Recording a breach
Section titled “Recording a breach”Opening a breach captures:
- Title and summary — what happened, in the DPO’s words.
- Discovered at / occurred at — discovery starts the 72-hour clock; the occurrence time may be earlier or unknown.
- Severity — low, medium, high or critical. High and critical imply Article 34, so the register flags affected-subject notification as outstanding until you record it.
- Nature — one or more of the ICO’s confidentiality / integrity / availability categories.
- Affected data categories and approximate counts of subjects and records.
- Likely consequences and mitigation measures already taken.
- Cross-border notes — where the breach touches data outside the UK.
Each breach is given a sequential reference automatically.
Lifecycle
Section titled “Lifecycle”A breach moves through four states:
- Open — newly recorded, root cause or scope still being established.
- Contained — no further loss is in progress.
- Notified — the ICO submission has been filed (recorded via mark notified).
- Closed — the post-incident review is filed. The DPO can close a “not notifiable” breach at any point, with the reason captured in the summary.
Containment chronology
Section titled “Containment chronology”Append each containment step — who did what, with detail and a timestamp — to build a defensible chronology. The same record holds the ICO-notified and subjects-notified timestamps once you mark them.
ICO export
Section titled “ICO export”The ICO export produces a PDF of the Article 33 submission template for the breach, including the clock status and the containment chronology. Where the host has no headless browser available it falls back to an HTML page that prints to PDF identically. Every export — and every mark notified — writes a tamper-signed access-log row, so the DPO has a defensible record of what was filed and when.