> ## 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. # Fulfill a DSAR and operate the breach-incident register > Walk Settings → Compliance → DSAR to file, verify, and deliver a GDPR Article 15 access request — then open, classify, and notify a personal-data-breach incident in the register, and pull the 72-hour attestation for your compliance binder. # 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](/compliance/dsar) and the [breach incident register reference](/compliance/breach-incident-register). 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 **Withdraw**n 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](/guides/compliance-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. *** ## Cross-links to the compliance fold | Console surface | Path | Where it's documented | | --------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------ | | DSAR queue | Settings → Compliance → DSAR | This guide; the [DSAR reference](/compliance/dsar) | | Breach register | Settings → Compliance → Breach incidents | This guide; the [breach incident register reference](/compliance/breach-incident-register) | | Evidence binder | Settings → Compliance → Binder | [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) | | Audit log | Settings → Audit log | [Audit log guide](/guides/audit-log) | Filings, verification decisions, incident writes, and attestation exports all record to your [audit log](/guides/audit-log) — the register the GDPR binder rows count from. ## Related * [Data Subject Access Requests (DSAR)](/compliance/dsar) — endpoint surface, jurisdiction deadlines, self-service portal * [Breach incident register](/compliance/breach-incident-register) — the full API surface and register semantics * [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) — where the attestation files * [GDPR posture guide](/compliance/gdpr-posture-guide) — how the posture controls fit together * [Privacy register](/compliance/privacy-register) — the inventory your breach data categories draw from * [Audit log](/guides/audit-log) — where every record lands