> ## 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. # Assembling a GDPR Posture End to End > Connect the GDPR controls — consent capture, residency and retention, DSAR SLA, the Art.30 register, the DPA, and the evidence binder — into one tenant-owned posture you can hand to a buyer or authority. # Assembling a GDPR Posture End to End The Compliance group documents each GDPR control on its own page: consent records, opt-out and suppression, the preference center, DSAR intake, the Art.30 register, the DPA, the evidence binder. This guide is the sequence across all of them — the order a tenant actually assembles a GDPR posture in, and what each step leaves behind as evidence. It extends [Posture B](/compliance/posture-overview#posture-b-eu-gdpr-apac-drip-operator) from the posture map into a full walkthrough. This page describes Orbit's platform controls. It is **not legal advice.** Which obligations apply to you — controller or processor, which lawful basis fits, whether a DPIA is required — depends on your processing. Confirm with qualified counsel. ## The tenant-owned framing Read this first, because it shapes everything below. Orbit's GDPR surface follows the same model as the rest of the compliance map ([posture overview](/compliance/posture-overview)): * **Every control here defaults open or empty.** A new tenant has no consent records, no quiet-hours gate, no activities in the register, no DPA acceptance, and no binder generations. Nothing on this page is mandated, and nothing here gates sending by itself. You assemble the posture; the platform enforces what you set, not a posture it picked for you. * **Orbit is the conduit and the ledger.** It carries your traffic, enforces the gates you configure, and keeps the auditable record. It never decides your lawful basis, never files with a supervisory authority for you, and never signs a DPA on your behalf. * **The binder reflects what you did.** An empty register exports as an empty register. Assemble the posture first; export second. *** ## Section 1 — The GDPR surface map One row per obligation a GDPR operator usually has to answer, mapped to the Orbit control that holds it and the deep page that documents it. | Obligation | Orbit control | Where it lives | Deep page | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Consent with a lawful basis** (Art. 6, Art. 7) | `POST /compliance/consent` with `lawful_basis` recorded per `(contact, channel)` pair | Consent API; fan-out to suppression and send gates | [Consent Management](/compliance/consent-management) | | **Channel-level consent records with proof** (Art. 7(1) burden of proof) | Per-channel states (`opted_in` / `opted_out` / `unknown`), lawful basis, source, and timestamps on every row; bulk export | Consent API + proof-of-record export | [Consent Management](/compliance/consent-management), [Export Consent & Suppression Records](/compliance/consent-suppression-export) | | **Withdrawal and suppression** (Art. 7(3)) | STOP keywords, consent API opt-outs, preference center, CSV bulk import — one suppression list, scoped per channel | Suppression layer every send reads | [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) | | **Recipient self-service** | Preference center with signed per-contact links; send gates read the same ledger | `POST /compliance/preference-center` | [Send Gates](/compliance/send-gates) | | **Data-subject requests with a deadline** (Art. 12–22) | DSAR intake, verification, and fulfilment with an SLA clock per jurisdiction (`gdpr` 30 days) | Operator API + public self-service portal | [DSAR](/compliance/dsar) | | **Records of processing** (Art. 30) and **DPIA** (Art. 35) | The privacy register — per-activity records with DPIA screening and an exportable inventory | `…/compliance/privacy-register/*` | [Privacy Register](/compliance/privacy-register) | | **Processor contract** (Art. 28) | The self-serve DPA — preview, typed e-signature, executed copy, version tracking | `GET/POST /api/v1/compliance/dpa` | [Data Processing Agreement](/compliance/data-processing-agreement) | | **Evidence for a buyer or authority** | The GDPR evidence binder — DSAR history, breach counts, consent and retention posture in one signed export | Settings → Compliance → Binder | [Evidence Binder](/compliance/evidence-binder) | Two adjacent controls round out the map: * **Quiet hours** are not a GDPR article, but an EU recipient under a local marketing regime expects them — configure them with the rest ([Quiet hours configuration](/guides/quiet-hours-configuration)). * **Voice data residency** decides where call recordings and transcripts physically live ([Voice data residency](/compliance/voice-data-residency)) — a residency choice you document in the register, not a gate. *** ## Section 2 — A worked sequence for an EU recipient A concrete run for a tenant sending drip campaigns to EU recipients. Each step names what you do and what evidence it leaves behind. ### 1. Capture consent with a lawful basis before the first send Record consent per channel through `POST /compliance/consent`, with `lawful_basis` set. For marketing to new EU recipients that is usually `consent`; for existing customers receiving service messages it may be `legitimate_interests` — that choice is yours, and Orbit records whichever basis you assert. ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "identifier": "jordan@example.com", "channels": ["email", "sms"], "opt_in": true, "lawful_basis": "consent", "source": "signup_form" }' ``` **Evidence left behind:** a per-channel consent row with basis, source, and timestamp — exportable as the proof-of-record file in [Export Consent & Suppression Records](/compliance/consent-suppression-export). ### 2. Configure the campaign fallback quiet-hours window Set the fallback window every drip or journey inherits when the campaign row has no window of its own — for example 22:00 → 07:00 recipient-local, which matches a common EU marketing quiet period. In the dashboard: **Settings → Campaign limits → Default quiet hours**. Over the API: `PUT /api/v1/campaigns/quiet-hours/settings`. This is the highest-value send-time control for an EU posture: one write covers every campaign that never sets its own hours. Details in [Quiet hours configuration](/guides/quiet-hours-configuration). **Evidence left behind:** held sends surface in reporting with the resolved window, and `GET /api/v1/compliance/quiet-hours/preview` answers "would this send be held, and until when" before you roll out. ### 3. Wire withdrawal paths Consent you captured must be cheap to withdraw — Art. 7(3). Three entry points land on the same suppression list: * STOP keywords on SMS/WhatsApp, * `POST /compliance/consent` with `opt_in: false`, * the preference center — configure it through `POST /compliance/preference-center`, then hand each contact a signed link so withdrawal arrives structured instead of as a support ticket. If you are migrating from another platform, bulk-import the legacy list via `POST /compliance/suppression-list/import` before the first send. See [Opt-Out & Suppression Lists](/compliance/opt-out-suppression). **Evidence left behind:** fail-closed suppression rows — a suppressed address is dropped before dispatch regardless of entry point. ### 4. Decide your DSAR intake path Two paths, and most EU postures run both: * **Operator-filed** — your team files on a customer's behalf with `POST /compliance/dsar` (`applicable_jurisdiction: "gdpr"` sets the 30-day SLA clock). * **Public self-service portal** — publish the portal link under your privacy policy so data subjects file directly; the flow verifies identity with a two-factor email + SMS OTP before anything queues. Decide which emails the portal sends from before linking it publicly — an unset sender leaves the portal unavailable. Full intake and verification detail in [DSAR](/compliance/dsar). **Evidence left behind:** every request carries its status, SLA clock, and fulfilment history — the rows the GDPR binder reads. ### 5. File your processing activities in the register Before the first DSAR arrives, document what you do. Record each activity in the [privacy register](/compliance/privacy-register): purpose, data categories, recipients, cross-border transfers, the retention period, and security measures. Orbit screens each activity against the Art. 35(3) triggers and flags a required DPIA — a flagged activity cannot move to active until the DPIA is recorded. **Evidence left behind:** a human reference per activity (for example `ROPA-2026-0004`) and an exportable inventory you can hand a supervisory authority under Art. 30(4). ### 6. Execute the DPA Preview the template, accept it with the typed e-signature, and archive the executed copy — all through `GET/POST /api/v1/compliance/dpa` or the dashboard. Acceptance is contractual record-keeping under Art. 28: it changes nothing about what Orbit processes and gates nothing. Until you accept, your `dpa_status` stays `not_accepted` — an open item any buyer's procurement review will find. See [Data Processing Agreement](/compliance/data-processing-agreement). **Evidence left behind:** the acceptance record — template version, signer, timestamp — and the rendered executed copy. ### 7. Export the GDPR binder for procurement or an authority When a buyer's security review or an authority asks for the whole posture, generate the **GDPR** framework binder from **Settings → Compliance → Binder** (or `POST /api/v1/compliance/binder/generate`). It assembles data-subject request history, breach counts, and the consent and retention posture into one pack with a 24-hour signed download link — PDF for a human reviewer, ZIP for a GRC import. See [Evidence Binder](/compliance/evidence-binder). Run the binder last. It reads the surfaces steps 1–6 populated, so generating before those steps hands the reviewer an empty pack. *** ## Section 3 — Activation bundles where GDPR-relevant The [plugin marketplace](/compliance/plugin-marketplace) bundles two GDPR-relevant starting points, both activated through `GET /api/v1/compliance/vertical-bundles`: | Bundle | GDPR relevance | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Fintech KYC** | Provisions a draft compliance profile and document set; the KYC documents pair with the register — each gated market entry is an activity you file under Art. 30. | | **E-commerce** | Provisions draft campaigns and an opt-in flow; wire the consent capture from Section 2 step 1 into the opt-in flow before the drafts go live. | Every activation is draft-only and comes with a go-live checklist — no bundle turns on a GDPR posture by itself, and activating one never records consent, files a register activity, or accepts a DPA for you. The bundles shortcut the setup; the sequence above is still yours to run. See [Plugin Marketplace](/compliance/plugin-marketplace). *** ## Section 4 — What Orbit does NOT do Boundary conditions, stated once and plainly: * **Orbit never files with a supervisory authority for you.** Breach notification to an authority (Art. 33) and to data subjects (Art. 34) are your acts. The binder surfaces your breach-count posture as evidence; the filing is yours. * **Orbit never auto-signs or auto-accepts the DPA.** The typed e-signature is a deliberate act by your workspace's owner or admin. * **Orbit never decides your lawful basis, retention period, or whether a DPIA is adequate.** The register screens and flags; the judgements it records are yours. * **Nothing on this page gates sending.** Consent records, the register, the DPA, and the binder are the ledger. The send-time gates that do exist — quiet hours you enabled, suppression entries you recorded — are the ones you turned on, and each defaults open. * **This is not legal advice.** The sequence assembles Orbit's controls; whether the assembled posture satisfies GDPR for your processing is a call for your counsel. *** ## Related references * [Posture overview](/compliance/posture-overview) — the toggle map this sequence extends. * [Consent Management](/compliance/consent-management) — lawful-basis fields and per-channel states. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — withdrawal paths and CSV import. * [DSAR](/compliance/dsar) — intake, verification, SLA clock. * [Privacy Register](/compliance/privacy-register) — Art. 30 records and Art. 35 DPIAs. * [Data Processing Agreement](/compliance/data-processing-agreement) — the Art. 28 contract lifecycle. * [Evidence Binder](/compliance/evidence-binder) — the export that reads everything above. * [Quiet hours configuration](/guides/quiet-hours-configuration) — the send-time window for EU recipients.