Skip to main content

​
Assemble and seal an evidence binder, read gated surface verdicts

Orbit gates nothing by default. The compliance evidence binder is your workspace’s evidence assembly flow, and every gate that stands between a surface and traffic — sender registration, pre-send policy scanning, PHI designations — is a control you selected and can configure. This guide walks both: how to assemble and seal your first binder from the console, and how to read a gate’s verdict so a surface you intended to open stops blocking. For the full endpoint surface, per-framework control tables, and import runbooks, read the binder reference. This page is the walkthrough.
Every control here — binder, sender registration, policy scan mode, PHI designation, consent posture — is tenant-owned. Orbit gives you the controls and defaults them open; you attest, you configure, you ungate. This page is not legal advice — confirm your obligations with counsel.

​
Position the binder as your own evidence flow

The binder exists because your audit, auditor, or buyer-procurement cycle asks for evidence — not because the platform mandates a posture. Four frameworks are available (SOC 2, ISO 27001, GDPR, HIPAA), and you choose the one your questionnaire, certification, or regulator actually asks for. That positioning has practical consequences:
  • Working controls fill the pack. The binder counts from the surfaces you operate day to day — the audit log, consent records, the DSAR queue, the HIPAA settings, sender-ID registration entries. A binder generated against idle surfaces reads thin.
  • Gates are chosen postures, not platform mandates. The gates you meet in Section 3 are postures the workspace opted into (or external authorities require): sender registration submitted per country, a policy-scan mode you set, PHI designations you attested. The “pending until an external approval lands” mental model is in the compliance posture FAQ.
  • Generation is gated to owner or admin roles. Whoever assembles evidence for a buyer or auditor should hold one of those roles; every generation is recorded in your audit log.

​
Walk Settings → Compliance → Binder

​
1. Assemble

Open Settings → Compliance → Binder. You need the owner or admin role.
  • Framework — pick the four-way card that matches the ask: SOC 2 for vendor questionnaires, ISO 27001 for certification attestations, GDPR for data-subject and retention posture, HIPAA for PHI safeguards and BAA posture.
  • Format — PDF opens as an HTML attestation you print-to-PDF from the browser (a single document for humans); ZIP unpacks to one Markdown file per control for GRC import.
A binder is two layers by construction: a static platform narrative per control, plus tenant evidence rows the workspace actually produced — aggregate counts only, never identifiers or secrets. Sealing means the tamper verdict and checksum below, not locking from further editing.

​
2. Seal

Select Generate. A background job walks the control matrix and replays your audit chain. The job moves Pending → Generating → Completed, and sealing happens inside that run:
  • Tamper verdict — the audit chain is replayed before the pack renders. A tamper alert banner on the result means treat the contents as informational until the chain clears.
  • Integrity summary — the completed banner reports how many evidence rows across how many controls the pack assembled.
  • SHA-256 checksum — the job row carries the checksum. Two generations over unchanged data are byte-identical, so the checksum is the seal your auditor verifies.
Expected evidence states on the job row: Pending (queued), Generating (walking controls), Completed (sealed and downloadable), Failed (retry), Tamper alert (generated but flagged). A clean Completed with its checksum is what you hand over. If a generation is already in flight for the same framework, re-clicking returns that job instead of queueing a duplicate — repeated clicks stay safe.

​
3. Hand off

Download links expire 24 hours after generation; the history list keeps the job record after the link lapses, and a fresh link comes from regenerating. Your audit log records the generation with the framework, format, and requesting role.

​
Read a scan verdict and ungate the surface

Compliant evidence and permitted traffic meet at the gates below. When a surface refuses to send, match the verdict to the gate first — then remediate the owning console. Troubleshooting reads the same verdict table the binder’s evidence rows count from. Keep the two in sync: fix the surface, then regenerate the binder so the row the auditor reads reflects the remediated posture.

​
Example: the HIPAA profile gate

A workspace designates an audience as PHI-adjacent. Until a Business Associate Agreement is executed, campaign launches over that audience refuse with HIPAA_BAA_REQUIRED — the gate blocks PHI audience visibility on outbound until the post-BAA posture holds. Together: you attested the designation as PHI-adjacent, so the gate enforces your attestation. The remediation chain:
  1. Gate fires — the campaign wizard warns at audience pick time; the launch precheck refuses with 422. See HIPAA_BAA_REQUIRED troubleshooting.
  2. Remediate the console — execute the BAA under Settings → Compliance → BAA, or lift the designation from the PHI registry if the audience carries no PHI. The full lifecycle: HIPAA onboarding.
  3. Evidence seals — generate the HIPAA binder; the § 164.314 row (BAA posture) and § 164.308 row (HIPAA mode) show the executing workspace’s current values. The binder reads the same HIPAA controls reference the gate enforces.
Where the console lives, and how to reach it from this page: Generation, verdict inspection, and remediation all land in the audit log, so the binder you regenerate after remediation quotes a workspace that moved forward.