> ## 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. # Assemble and seal an evidence binder, read gated surface verdicts > Walk Settings → Compliance → Binder to assemble and seal a tenant-owned evidence pack, then read scan verdicts on gated surfaces — sender approvals, pre-send policy scans, PHI designation gates — and ungate the surface you intended to open. # Assemble and seal an evidence binder, read gated surface verdicts Orbit gates nothing by default. The [compliance evidence binder](/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](/compliance/evidence-binder). 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](/guides/audit-log), [consent records](/compliance/consent-management), the [DSAR queue](/compliance/dsar), the [HIPAA settings](/compliance/hipaa), [sender-ID registration entries](/compliance/sender-id-registration). 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](/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](/guides/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. | Verdict | Gate | Owning console to remediate | | --------------------------------------------------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SENDER_ID_NOT_APPROVED` (422) — a country entry is `pending`, `rejected`, or `expired` | Sender-ID registration | **Settings → Compliance → Sender IDs** — re-submit, or wait for `approved`. See [Troubleshoot pending surfaces](/compliance/troubleshooting-pending-gated-surfaces). | | `POLICY_VIOLATION` (blocked) | Pre-send policy scanner in **block** mode | **Settings → Compliance** → policy scan mode. Switch to warn/pass, or rewrite the message. See [Pre-Send Policy Scanner](/compliance/policy-scanner). | | `HIPAA_BAA_REQUIRED` (422) | PHI-adjacent audience designation | **Settings → Compliance → BAA** — execute the agreement, or lift the designation. See the [HIPAA example](#example-the-hipaa-profile-gate) below. | | Tamper alert banner on a binder | Audit-chain integrity seal | Regenerate after the chain clears; persist flags route to [security@devotel.io](mailto:security@devotel.io). | | DNC gate on a dial or send | DNC scrub | **Settings → Compliance → DNC** per your scrub posture. See [DNC preflight scrub](/guides/dnc-preflight-scrub). | 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](/troubleshooting/phi-audience-baa-required). 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](/guides/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](/compliance/hipaa) reference the gate enforces. *** ## Console ⇄ guide cross-links Where the console lives, and how to reach it from this page: | Console surface | Path in the dashboard | What walks there | | ----------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Compliance binder | Settings → Compliance → Binder | This guide; the [binder reference](/compliance/evidence-binder) | | Sender IDs | Settings → Compliance → Sender IDs | [Pending surfaces troubleshoot](/compliance/troubleshooting-pending-gated-surfaces); [Sender-ID registration](/compliance/sender-id-registration) | | Policy scan mode | Settings → Compliance | [Pre-Send Policy Scanner](/compliance/policy-scanner) | | BAA / HIPAA mode | Settings → Compliance → BAA / HIPAA | [HIPAA onboarding](/guides/hipaa-onboarding); [HIPAA controls](/compliance/hipaa) | | Audit log | Settings → Audit log | [Audit log guide](/guides/audit-log) | Generation, verdict inspection, and remediation all land in the [audit log](/guides/audit-log), so the binder you regenerate after remediation quotes a workspace that moved forward. ## Related * [Compliance evidence binder](/compliance/evidence-binder) — the full framework tables, endpoints, and runbooks * [Troubleshoot pending gated surfaces](/compliance/troubleshooting-pending-gated-surfaces) — status-to-cause mapping for send gates * [Pre-Send Policy Scanner](/compliance/policy-scanner) — pass/warn/block verdicts and scan-mode settings * [HIPAA BAA required troubleshooting](/troubleshooting/phi-audience-baa-required) — the PHI gate example run down * [Audit log](/guides/audit-log) — where generation and remediation both record * [Compliance posture FAQ](/compliance/posture-faq) — the tenant-owned-controls mental model