Skip to main content

​
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 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):
  • 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. 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).
  • Voice data residency decides where call recordings and transcripts physically live (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. 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.
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.

​
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. 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. 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. 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: 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. 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. 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 bundles two GDPR-relevant starting points, both activated through GET /api/v1/compliance/vertical-bundles: 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.

​
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.