> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Operate the GDPR breach-incident register > Walk Settings → Compliance → Breach incidents: open a personal-data breach, classify severity, record the supervisory-authority and data-subject notifications, and export the 72-hour attestation for your compliance binder. # 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](/compliance/breach-incident-register). 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: | Level | A working guide | | - | - | | Low | Minimal scope, trivially containable, little plausible risk. | | Medium | Limited scope or contained quickly with residual risk. | | High | Significant scope, sensitive categories, or unresolved exposure. | | Critical | Widespread or sensitive-data exposure, or active ongoing access. | 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](/guides/compliance-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](/guides/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**. *** ## Related references * [Breach incident register reference](/compliance/breach-incident-register) — the full API surface and register semantics. * [Data Subject Access Requests (DSAR)](/compliance/dsar) — the other half of GDPR operations. * [GDPR Processing Register (ROPA + DPIA)](/compliance/privacy-register) — the Art. 30/35 documentation that sits beside the breach register. * [GDPR posture guide](/compliance/gdpr-posture-guide) — how the posture controls fit together. * [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) — where the attestation files. * [Audit log](/guides/audit-log) — where every register write lands. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.