Skip to main content

​
Breach incident register (GDPR Art. 33/34)

When personal data is breached, GDPR Art. 33(1) gives you at most 72 hours from the moment you become aware of the breach to notify your supervisory authority. Where the breach is likely to result in a high risk to the people affected, Art. 34 also obliges you to notify those data subjects without undue delay. The breach incident register records that lifecycle — detection, assessment, containment, notification, closure — and produces an attestation proving whether the 72-hour window was met.
This page describes Devotel Orbit’s platform controls. It is not legal advice. Whether a given event is a notifiable breach, which authority to notify, and what your notification must contain are judgement calls for your data protection officer (DPO) and counsel.
All endpoints below are rooted at https://api.orbit.devotel.io/api/v1/compliance/breach-incidents.

​
The register records — you notify

The register records the breach lifecycle. It does not send the notifications: your DPO contacts the supervisory authority and the affected data subjects through your normal legal channels, then records in the register when each notification went out. The register’s attestation is the evidence that those notifications happened inside the window — it never touches a carrier, an email channel, or any outbound messaging itself. Reads are available to any authenticated member of your workspace. Writes — opening, updating, and recording notifications — are restricted to owner and admin roles, because the register is a regulatory control. Every write lands in your audit log with the actor and the incident reference.

​
Lifecycle

An incident moves through: detected → under_assessment → contained → notified → closed Two terminal states end the lifecycle:
  • closed — the incident was notified and is fully resolved.
  • no_notification_required — the assessment concluded neither an Art. 33 nor an Art. 34 notification is owed (for example, the data was encrypted and the key is uncompromised). Set notification_required: false and record the rationale in remediation before taking this branch.
An incident that still owes a supervisory-authority notification cannot be closed: the API rejects the close with 409 Conflict until you record the Art. 33 notification or flip notification_required to false.

​
Open an incident

POST /compliance/breach-incidents — requires an owner or admin API key. The incident lands in status detected with a human reference like BR-2026-0001, and discovered_at (default: now) starts the 72-hour clock.
Returns 201 Created with the incident. Get one back with GET /compliance/breach-incidents/{id}.

​
Advance the lifecycle

PATCH /compliance/breach-incidents/{id} updates mutable fields and/or moves the status forward:
Every mutable field from the create body plus status can be patched, for example recategorising severity once the scope is known, or updating the affected counts as the assessment firms up.

​
Record a notification

POST /compliance/breach-incidents/{id}/notifications — stamps the moment a notification went out. This timestamp is what the 72-hour attestation compares against the deadline.
Recording the supervisory_authority notification automatically advances a still-open incident to notified. Record both parties when Art. 34 also applies; the attestation reports each side independently.

​
The 72-hour attestation

GET /compliance/breach-incidents/{id}/attestation returns a self-contained proof for your compliance binder: the discovery instant, the computed deadline, each party’s notification timestamp, the hours elapsed, and a compliant verdict.
compliant is true when notification was not required, or the authority was notified at or before the deadline. Data-subject notification is reported alongside but does not gate the flag — the 72-hour clock belongs to Art. 33. The list endpoint (GET /compliance/breach-incidents) summarises the register with open and overdue counts by severity and status, so an un-notified incident that has blown its deadline is visible at a glance.

​
A worked end-to-end sequence

  1. Open — POST /compliance/breach-incidents with severity: "high". The incident opens as detected; the 72-hour clock starts at discovered_at.
  2. Assess — PATCH with status: "under_assessment", refining affected_data_subjects and data_categories as forensics progress.
  3. Contain — PATCH with status: "contained" and a remediation note describing the containment step.
  4. Notify — POST …/notifications with party: "supervisory_authority" after your DPO files with the authority; the incident moves to notified. Repeat with party: "data_subjects" when Art. 34 applies.
  5. Attest — GET …/attestation and attach the JSON to the binder you hand your auditor or the authority.
  6. Close — PATCH with status: "closed" once the response is complete (blocked until the authority notification is recorded or documented as not required).

​
Storage and limits

Incidents are stored per workspace as a JSONB register, capped at 1000 incidents. Concurrent updates are serialised, so two team members recording notifications at the same time cannot overwrite one another’s timestamps. When you approach the cap, archive closed incidents out to your evidence binder to keep the working register lean.

​
Access control

  • Reads (GET) — any authenticated member of your workspace.
  • Writes (POST, PATCH) — owner and admin roles only.
  • Every open, update, and notification is written to your audit log with the actor and the incident reference.