Skip to main content

​
Operate the GDPR breach-incident register

Settings → Compliance → Breach incidents is your GDPR Article 33/34 personal-data-breach register. Open an incident, classify its severity, record when you notified your supervisory authority and the affected data subjects, and export the 72-hour attestation that proves whether the Article 33 window was met.
Every control here is tenant-owned: you decide whether an event is a notifiable breach, you notify the authority and the data subjects through your normal legal channels, and you record those timestamps here. The register documents the lifecycle — it never sends a notification itself. This page is operational guidance, not legal advice; confirm your obligations with your DPO and counsel.
For the full endpoint surface and request schemas, read the breach incident register reference. This page is the console walkthrough.

​
1. What counts as a personal-data breach

GDPR Art. 4(12) defines a personal-data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. A failed deploy, a slow query, or a dropped call is a general incident — handle it in your normal status and support tooling. The register is for events where personal data was actually exposed or destroyed:
  • unauthorised disclosure (a contact list exported to the wrong recipient, a phone number written into shared logs),
  • unauthorised access (an attacker or an unmanaged device reached customer data),
  • loss or destruction (personal data deleted or rendered unavailable outside your retention plan).
Not every personal-data breach is notifiable. Art. 33 expects notification “unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons” — the threshold decision, and its rationale, is yours to document. When the assessment concludes no notification is owed, take the No notification required branch (section 5) with the rationale recorded in the incident’s remediation notes.

​
2. Open an incident and classify severity

Open Settings → Compliance → Breach incidents and select Open incident. The form shapes everything downstream:
  • Title + Description — required. What happened, what data was involved, how it was detected. The authority’s first questions, answered while the details are fresh.
  • Severity — Low, Medium, High, or Critical. The register summary counts critical and high severity so your worst exposure is visible at the top of the page. Classification guidance: These are working labels: the four values are fixed, the judgement is yours.
  • Discovered at — the moment you became aware of the breach. This instant starts the Article 33 72-hour notification clock. Leave it empty to start the clock now; set an earlier time when the breach was found before you opened the record.
  • Occurred at — when the breach is believed to have occurred, if known.
  • Scale fields — affected data subjects, affected records, and data categories (one per line). Estimate honestly; you can refine the counts as the assessment firms up.
  • Notification required — on by default. Turn it off only with a documented rationale, recorded in the remediation notes.
  • Remediation — containment steps taken; update it as the response progresses.
Save, and the incident lands in status Detected with a human reference (BR-YYYY-NNNN). The 72-hour clock is running.

​
3. Record the supervisory-authority notification (Art. 33)

The register records notifications — your DPO or counsel files with the authority through your normal legal channels, then logs the timestamp here. The register’s attestation measures against the timestamps you record; it never touches an outbound channel. On the incident’s expanded row, select Record notification:
  • Party — choose Supervisory authority — Art.33.
  • Notified at — defaults to now; record the actual send time so the attestation is truthful.
  • Method — the channel used (authority portal, registered letter, email).
  • Reference — the authority’s case number.
Recording the authority notification automatically advances a still-open incident to Notified. Until then, the row’s deadline cell shows where the clock stands: the upcoming deadline while inside the window, or Overdue once 72 hours elapse without an authority notification — and the summary grid aggregates the overdue count across the register so a breached window is never silent.

​
4. Record data-subject notification (Art. 34) and exemptions

Art. 34 obliges you to inform the affected people without undue delay when the breach is likely to result in a high risk to their rights and freedoms. Record it the same way, with party Affected data subjects — Art.34, noting how recipients were reached (email batch, letter campaign). Two exemptions most often end the Art. 34 analysis early, mirrored from Art. 34(3):
  • Encryption — the data was rendered unintelligible to unauthorised parties (for example, encrypted, with the key uncompromised).
  • Low likelihood of high risk — the assessment concluded a high risk to individuals is unlikely.
Document either exemption in the incident record (the remediation notes and the notification record itself), and the attestation reports each party’s side independently — the 72-hour clock belongs to Art. 33, but a binder that omits the Art. 34 rationale is an audit finding waiting to happen.

​
5. Advance the lifecycle and close

Expand a row and use the Lifecycle status control: Detected → Under assessment → Contained → Notified → Closed
  • Detected — the open state the incident is born into.
  • Under assessment — forensics and scoping underway; keep the affected counts and data categories updated.
  • Contained — the exposure is stopped; record the containment step in remediation.
  • Notified — set automatically when the authority notification is recorded.
  • Closed — the response is complete.
An incident that still owes a supervisory-authority notification cannot be closed: the close is rejected with a conflict until you record the Art. 33 notification or document that notification is not required. The second terminal state, No notification required, is the documented-exemption branch — flip Notification required off and record the rationale before taking it.

​
6. Export the attestation for the compliance binder

On the expanded row, select 72-hour attestation. The dialog renders the compliance statement: discovery instant, computed Art. 33 deadline, each party’s recorded notification timestamp and method, the hours elapsed, and a compliant/not-compliant verdict. Select Export attestation to download it as a JSON file named with the incident reference (breach-attestation-BR-…). File it in your evidence binder as your proof that the authority notification landed inside the Art. 33 window — or, when it did not, as the honest record your DPO accounts for. The register’s own summary (open and overdue counts by severity and status) is the at-a-glance view an auditor or your board asks for first.

​
7. Access control — owner and admin only

Reads are workspace-wide, but writing to a regulatory register is an owner/admin action: opening incidents, advancing status, and recording notifications are restricted to the owner and admin roles, mirroring the platform’s administrative guard on its write surface. Assign member roles accordingly, and keep in mind every write — open, update, notification, export — lands in your audit log with the actor and the incident reference, so the register reads as a reviewed trail, not an anonymous log.

​
Worked example — a leaked phone number in shared logs

A carrier webhook handler briefly logged a customer MSISDN into a shared log bucket. Your on-call engineer spotted it during routine review at 09:12.
  1. Open — 09:25. Title “MSISDN leaked into shared logs by carrier webhook”, severity Medium, discovered at back-dated to 09:12 (the honest clock start), data categories “Phone numbers (MSISDN)”, affected data subjects estimated at 1.
  2. Assess — status moved to Under assessment; you confirm the scope is a single number over a 40-minute window and patch the counts.
  3. Contain — the logging statement is disabled at 10:48; status moves to Contained with the remediation note.
  4. Notify the authority — your DPO files with the DPA at 16:40 the same day (31.5 hours after discovery). Record notification → Supervisory authority — Art.33, method authority portal, reference the DPA case number. The incident moves to Notified.
  5. Assess Art. 34 — one phone number, no associated content: the assessment concludes no high risk. That exemption is recorded in the incident notes rather than as an Art. 34 notification.
  6. Attest — export the attestation (breach-attestation-BR-2026-0007.json) and file it in the binder; it records 31.5h, inside the 72h window, compliant.
  7. Close — after the post-incident review, status moves to Closed.