Skip to main content

​
Fulfill a DSAR and operate the breach-incident register

Two console surfaces carry your data-subject obligations from intake to evidence: Settings → Compliance → DSAR compiles and delivers a GDPR Article 15 export for a contact (and tracks the erasure queue beside it), and Settings → Compliance → Breach incidents is your GDPR Article 33/34 incident register — open an incident, classify its severity, record the supervisory-authority and data-subject notifications, and pull the 72-hour attestation. For the full endpoint surface, jurisdiction deadlines, and portal flow, read the DSAR reference and the breach incident register reference. This page is the walkthrough.
Every control here is tenant-owned: you file the request, you verify the requester’s identity, you decide whether an event is a notifiable breach, and you deliver the export. Devotel Orbit gives you the consoles and the deadlines to track them — not legal advice. Confirm your obligations with counsel.

​
Walk Settings → Compliance → DSAR

You need the owner or admin role to open this surface and act on requests.
  1. File the request. Open Settings → Compliance → DSAR and select Create DSAR. Pick the request type — Access (Art. 15) is the compile-and-deliver export this guide follows — enter the subject’s identifiers (contact ID, email, or phone, any one of them) and the requester’s email. The dialog warns when an in-flight request already exists for the same identifier, so you don’t queue a duplicate.
  2. Verify the requester’s identity. A request awaiting verification shows Verification pending and no export worker acts on it until you decide. Approve (identity confirmed — the request releases to the export worker) or reject (the request closes; nothing is released or erased). Your decision, with any note, is written to the audit chain so a regulator can reconstruct the review trail.
  3. Watch the SLA clock. Each in-flight row carries a Day X of 30 badge — GDPR’s statutory window is 30 days, and the workspace-level SLA banner appears the moment any request breaches it. Filter Show breached only to triage overdue rows first.
  4. Deliver the export. When the row reaches Completed, its download link is available; the Download decrypted action builds the plaintext export for an operator, and the row notes who the export may be shared with. An in-flight request can be Withdrawn before fulfilment.
  5. Track the erasure queue. The Erasure requests (Art. 17) tab holds the right-to-be-forgotten queue across both intake paths: requests honoured after a 7-day cooling-off window, and filings from the self-service portal or the request dialog. For an executed erasure, the Proof of deletion action downloads the signed deletion certificate, and Propagate fans the erasure out to your connected destinations — irreversible, so it asks you to type PROPAGATE.

​
Operate the breach-incident register

Open Settings → Compliance → Breach incidents. Reads are workspace-wide; opening incidents, advancing status, and recording notifications require owner or admin, and every write lands in your audit log with the actor and the incident reference.

​
1. Open an incident, classify its severity

Select Open incident. Give it a title and a description — what happened, what data was involved, how it was detected — and set the fields that shape everything downstream:
  • 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.
  • 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.
  • Notification required — on by default. Turn it off only with a documented rationale (for example, the data was encrypted or no risk to individuals exists). The console enforces this: an incident that still owes an authority notification cannot be closed until the notification is recorded or notification is documented as not required.
  • Scale fields — affected data subjects, affected records, and data categories (one per line). These are what the supervisory authority asks for, so size them as best you can at open time.
After the incident opens, advance its lifecycle status on the expanded row: Detected → Under assessment → Contained → Notified → Closed (or No notification required for the documented-exemption case).

​
2. Record the authority and data-subject notifications

The register records notifications — your data-protection officer or counsel delivers them through your normal legal channels, then logs the timestamps here. The register’s attestation measures against the timestamps you record; it never sends anything itself. On the incident’s expanded row, select Record notification:
  • Supervisory authority — Art.33 — the notification the 72-hour clock measures against. Record the notified timestamp, the method (authority portal, registered letter, email), and the authority’s case reference.
  • Affected data subjects — Art.34 — required when the breach is likely to be a high risk to the people affected. Record the notified timestamp and how recipients were reached.
The row’s deadline cell tells you where the clock stands: the upcoming deadline while inside the window, Overdue once the window elapses without an authority notification, Notified once recorded, or Not required when the exemption is documented. The summary grid aggregates Overdue (Art.33) across the register so a breached window is never silent.

​
3. Pull the notification attestation for the compliance binder

On the incident’s expanded row, select 72-hour attestation. The dialog renders a compliance statement — whether the recorded authority notification landed inside the window — with the discovery instant, the deadline, and both notification records laid out. Select Export attestation to download it, and file it in your evidence binder as your proof that the authority notification landed inside the Article 33 window — or, when it did not, as the honest record your DPO accounts for.

​
Drive the erasure lifecycle over the API

Erasure is tenant-owned from the first byte. You decide whether a request is honoured, you pick the intake path, and you set your own cooling-off posture; Devotel Orbit runs the pipeline you file against it — the queue, the cooling-off, the per-resource hard-delete audit chain, and the proof-of-deletion certificate — but the posture (accept/reject, hold, exempt, propagate downstream) is your call. The lifecycle below is the API you drive.

​
1. File the erasure

File the Article-17 request on the contact. The default cooling-off is 7 days, overridable per tenant when your counsel wants a shorter window, and the returned cooling_off_ends_at is the hard-delete boundary you agreed to:
A 202 carries the open request — data.id (erasure_…), status: pending, and the agreed cooling_off_ends_at. The same-row-once rule is structural: a second POST before the first resolves is a 409 with error.code: ERASURE_COOLING_OFF_ACTIVE and a directive to cancel the pending row first:
The immediate-cascade sibling (DELETE /contacts/:id/gdpr/delete) is the no-window emergency path. That one is step-up-gated: mint a re-auth token with POST /contacts/:id/gdpr/delete/challenge, present it in X-Reauth-Challenge within five minutes, and the cascade runs. Filing through the console’s Erasure request dialog (step 1 of the workspace walkthrough) POSTs the same row with you as requester, so the two surfaces stay in the same queue.

​
2. Poll to terminal

Two read surfaces carry the queue. The per-contact history (GET /contacts/:id/gdpr/erasure-requests) returns every request the contact has ever had — a pending row is the one you can cancel, and the resolved trail (executing, cancelled, completed) carries requested_by_user_id, executed_at, and failure_reason for the post-mortem. The workspace queue (GET /compliance/dsar/erasure-requests) is the audit lens — one row per request across every contact, filterable by status (pending, cancelled, executing, executed, failed). Both surfaces land in the same { data, meta } envelope.
An executed row is the endpoint the console’s Proof of deletion action reads. The certificate (GET /compliance/dsar/erasure-requests/:id/certificate) names the per-resource counts the worker cascade completed, the executed_at timeline, and any CDP destinations the Propagate step fanned the erasure out to — file it in the evidence binder (step 3 below) as your hardest artifact. Terminal and in-flight states on the queue, as the writer stamps them and the reader renders them: Poll the workspace queue on the cadence your audit demands — once per window is enough, because the cooling-off itself is the latency budget, and the workspace table is the audit-time view. A legal-hold gate intercepts erasure only when the platform’s own lifecycle would destroy the data independently. Article-18 restriction (the “keep the data, pause the processing” claim) is filed through the DSR verbs correct or limit_sensitive_pi, not as an erasure — an Art-17 row asserts the subject wants the data gone. When both land, the composition is deliberate:
  • Conversations under legal hold. The eDiscovery hold exempts the conversation from the age-based retention sweep only, because the sweep is the thing the hold is defending against. A GDPR erasure hard-deletes every piece of the contact’s own linkgraph — their messages, their call records, their CDP rows — so the erasure does destroy retained rows on purpose. The hold and the erasure are different claims aimed at different destroyers. Counsel decides which claim wins before you file; they cannot both be satisfied silently.
  • The console is unambiguous. The Erasure request dialog (the same POST as step 1) fails loudly within an existing hold posture: because the erasure writes a hard-audit-chain per resource deleted, an operator working under an active litigation hold sees the conflict surface before the delete runs. The DSR intake’s own education copy (DSAR Art-18 block) steers restriction claims away from erasure and into correct/limit_sensitive_pi for exactly this reason.
  • Propagation and the artefact. The per-contact Propagate action — same surface as step 2 — fans the erasure out to your connected CDP destinations only once the internal delete has run, and the proof-of-deletion certificate folds the per-destination trail into its own table, so a regulator sees the downstream rows as part of the same document.

​
4. The Meta callback pair, kept separate

Don’t conflate the two contract pairs. The tenant-driven lifecycle above is the one you operate for GDPR. POST /api/v1/meta/data-deletion and GET /api/v1/meta/data-deletion/status/{code} together form the Meta App-Rollback pair — a public endpoint Meta calls back when a Facebook user revokes your app. The platform returns a confirmation URL and code immediately, writes the audit row asynchronously, and exposes the status lookup the requester’s confirmation page polls. It fires from Meta’s infrastructure, not from your tenant console; its row never enters the DSAR queue you audit at step 2.
Filings, verification decisions, incident writes, and attestation exports all record to your audit log — the register the GDPR binder rows count from.