Skip to main content

​
Your first compliance posture, end to end: from tenant-owned controls to a sealed evidence binder

The compliance class documents each control on its own page — the 10DLC wizard, the TCPA checklist, the opt-out rule editor, the profile assembly, the binder. A new tenant does not need those pages one at a time; they need the chain: which control to set first, which one depends on it, and the moment the whole posture becomes a sealed artifact an auditor can read. This page is that chain. Work it top to bottom the first time you stand up a posture; afterwards, the quarterly review keeps it true.
This is operational guidance, not legal advice. Every control in the chain is tenant-owned: Orbit supplies the surfaces and defaults them open, you configure them and you own the posture. Confirm which obligations apply to your traffic with qualified counsel before you send.

​
1. What “tenant-owned” means, page by page

Compliance on Orbit splits at a clean boundary: the platform curates the regulatory reference data and the surfaces; the tenant decides the posture and files the paperwork. Knowing which side of that boundary each page lives on keeps you from waiting on Orbit to do something only you can do — or from treating an advisory finding as a platform mandate. The tenant side of the chain, in the order this walkthrough runs it: The platform side is deliberately small: Orbit curates the country-rules reference your sender posture is graded against, runs one federal guard for the US voice dialing window (a statutory guard that accepts no tenant toggle, detailed in the TCPA posture guide), and records everything you do in your audit log. Every other knob — your scan mode, your allowlists, your quiet hours, your opt-out rules, your profile submissions — takes its value from you and defaults open. The full toggle map is the compliance posture overview, and the posture FAQ answers “which of these fails open vs. closed.” The readout of this section: nothing in the chain below “turns on compliance” for you. Each step opens a control you then set, and the binder at the end proves your configuration, not a platform default.

​
2. The chain: stand the controls up in dependency order

Each chain link below names the console surface, the API call that verifies it, and the artifact the link contributes to your eventual binder. Run them in order — a later step’s verification reads an earlier step’s state.

​
Step 1 — Register your 10DLC brand and campaign

US A2P SMS starts with carrier registration: brand first, then a campaign whose declared use case matches the traffic you actually send. The console path is the 10DLC wizard (Settings → Compliance → Brand identity); the baseline posture for everyday US SMS — marketing vs. transactional lane split, use-case mismatch rejections — is the 10DLC marketing baseline. Verify the registration is settled before you build anything on top of it:
A clean preflight means the brand and campaign the campaign references both resolve and approve. An unapproved campaign is the first thing an auditor’s “is your traffic registered?” question lands on — treat this as the chain’s foundation, not an optional pre-step. Binder contribution: the brand/campaign approval posture an auditor quotes back at procurement review.

​
Step 2 — Walk the TCPA checklist

With the carrier registration filed, the per-send discipline is next. The TCPA compliance checklist walks the exact questions a US SMS program must answer before launch: prior express consent captured per recipient, disclosure language on the capture point, quiet hours per channel, STOP handled. Run it against your first real campaign, not a hypothetical one — the checklist’s value is that it forces the consent-coverage question while there is still time to fix the capture path. Two adjacent controls feed the same answer set: quiet hours configuration for when you send, and TCPA quiet hours and windows for how the federal window and your tenant windows interact. Binder contribution: consent coverage and quiet-hours posture — the rows a GDPR Art. 6 or SOC 2 reviewer reads first.

​
Step 3 — Set your opt-out rules

Your keyword rules sit on top of the platform-mandated STOP/START carrier set and are additive only — you can widen triggers (a branded REJOIN, a localized ALTO) but never narrow the platform floor. Set them once, account-wide, at Messages → SMS → toolbar: Opt-out Rules, per the opt-out & opt-in rules page. If you send on WhatsApp or RCS, the channel-specific rule surface is opt-out rules for WhatsApp and RCS. Prove a rule fired before you call it done: send a keyword from a test contact and watch its consent state flip, then confirm a pre-send check against that contact holds suppression. The suppression layer the rules write into is Opt-Out & Suppression Lists. Binder contribution: the suppression-enforcement posture — the evidence that an opt-out, once expressed, holds.

​
Step 4 — Set a per-market posture with the country-rules playbook

For every market beyond your first, the country-gate posture playbook is the operating model: flag on (warn scan mode), block only on the gate’s two fail-closed shapes (unregistered sender into a required market; sender type outside the country’s permitted list), verify in preflight, promote to strict after 14 days of evidence. Look a market up before you plan it:
One row per country × channel: registration of none | recommended | required, plus permitted sender_types. Run your launch draft through POST /api/v1/messages/lint — the same gate, applied pre-send, returning the verdict a real send would get. Binder contribution: your per-market gate posture and the preflight verdicts you ran before launch.

​
Step 5 — Assemble your compliance profile

Carrier-facing identity — legal entity, address, the documents that prove them — lives in a compliance profile you create once and reuse across every gated surface (number purchase, Sender-ID registration, brand verification). The assembly order and the map of which profile opens which surface is Assemble your tenant’s compliance posture; the creation flow itself is the compliance profile wizard (Settings → Compliance → Profiles → New). Drive it from the API:
A US-SMS-compliant tenant’s profile, once filled and submitted, reads like this:
The lifecycle is draft → pending_review → approved — only an approved profile opens its gated surface. List yours before a launch to confirm nothing is still pending_review:
When a surface stays gated, the cause is always one of three — profile still in review, the country’s packet mismatching the carrier’s ask, or a pack’s go-live checklist uncleared. The diagnosis walkthrough is Troubleshoot pending gated surfaces. Binder contribution: the verified-identity posture every regulated surface inherits.

​
Step 6 — Schedule the quarterly review

Posture decays between audits — traffic drift, jurisdiction drift, consent staleness. The quarterly compliance posture review is the recurring half of this chain: read the compliance-health score, re-verify consent/recording/windows/attestation/suppression, exercise the DSAR pipeline end to end, and close with a binder generation. Put the first one on the calendar the day your first campaign launches — a posture no one re-verifies is a posture drifting. Binder contribution: the cadence that keeps the binder’s current generation comparable to the last.

​
Step 7 — Generate your first evidence binder

The binder turns everything above into one sealed artifact. Generate it from Settings → Compliance → Binder (owner or admin role) or the API:
The response is 202 with a job id; poll GET /api/v1/compliance/binder/{jobId} until Completed, then download within 24 hours. The full framework tables — which control assembles which evidence rows — are the binder reference. Pick the framework your auditor actually asked for; TCPA has no binder framework, so assemble a TCPA pack with the TCPA evidence pack instead. Binder contribution: this is the binder — the chain’s destination.
Before the first generation, walk the chain once and verify each link reports the posture you intended. A binder assembled against a half-configured workspace reads thin by construction — it quotes its rows from the surfaces you operate, and idle surfaces produce “No tenant-specific evidence recorded for this control.” Verify each chain link in order: Then generate. Read the result in three passes, the way an auditor will:
  1. Integrity summary first. The header reports how many audit-chain rows were replayed and verified during generation. A tamper-alert banner at the top means hold the binder internally, investigate the chain, and regenerate — never hand a flagged pack to anyone external without the caveat discussed first.
  2. The empty-control scan. Any control reading “No tenant-specific evidence recorded” is a chain link you skipped, not a binder defect. Regenerate after the surface produces evidence — the quarterly-review table above is the checklist that keeps the scan clean.
  3. The seal. The completed job row carries a SHA-256 checksum. Two generations over unchanged data are byte-identical, so the checksum is what you record next to each generation date; an auditor re-hashes the file they received and confirms it is the file you generated.
Walk the auditor through the stakes in their own terms: the SOC 2 pack maps CC1.0–CC9.0 to your workspace’s audit chain; the GDPR pack quotes DSAR completion medians against the statutory 30-day clock; the HIPAA pack reads the BAA and retention posture you configured. The worked hand-offs — a procurement questionnaire slot, an authority response pack — are in the binder reference.

​
4. HIPAA sidebar: the PHI-in-scope flag changes the chain, not the posture model

If your workspace handles PHI, every step above still applies — tenant-owned controls, your posture, your evidence. What changes is the first link in the chain and the gate it feeds:
  • BAA before anything. The Business Associate Agreement gates HIPAA mode, and HIPAA mode gates PHI sends — a PHI-adjacent campaign refuses with 422 HIPAA_BAA_REQUIRED until the agreement is executed. Nothing else in the chain substitutes for it.
  • A PHI-in-scope flag on your audiences. Designating an audience as PHI-adjacent is a tenant attestation; the gate enforces your attestation, not a platform default. Lift the designation only when the audience genuinely carries no PHI.
  • Retention and access scoping follow. HIPAA mode’s value is the configured retention window and the PHI access log the binder later quotes — set them before PHI traffic runs, per the HIPAA onboarding sequence.
The comparable HIPAA onboarding guide walks BAA → HIPAA mode → role restriction → retention → evidence export end to end, in the same chain style as this page; the HIPAA controls reference documents each setting, and the HIPAA checklist tool is the per-step verification companion. For the binder, choose the HIPAA framework — its § 164.308/§ 164.314 rows quote the BAA and retention values you set, so bring them current before you generate.
Every page in this chain carries the same note, and it is operational guidance, not boilerplate: Orbit documents controls; counsel interprets obligations. Use the chain like this:
  • The country-rules reference and the per-market posture pages tell you what the carriers and registries ask for, mechanically. Whether a given obligation applies to your traffic — and how a statute reads against your use case — is a counsel question.
  • Advisory surfaces (the compliance-health score, warn-mode scan findings) are signals you triage, not verdicts the platform enforces. Act on them because your counsel’s reading says to, and because a carrier’s rejection window is shorter than a legal review cycle.
  • The binder proves your configuration and your operating record. It does not certify compliance — it hands an auditor the evidence they grade you against.
Bring counsel into the chain at two fixed points: before the first campaign in a new traffic family (Step 2’s checklist answers), and before you promote a new market to strict (Step 4’s playbook). Both are posture changes you cannot delegate to a tool.