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

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

> Walk a new tenant from zero posture to an audit-ready evidence binder — 10DLC registration, TCPA checklist, opt-out rules, country-rules playbook, compliance-profile assembly, quarterly review, and the first binder generation, in one ordered chain.

# 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](/guides/compliance-posture-quarterly-review) keeps it true.

<Note>
  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.
</Note>

***

## 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:

| Chain link | What you own there | Deep page |
| - | - | - |
| 10DLC registration | The brand and campaign you file with US carriers — the use case you declare, the sample messages, the opt-in flow carriers vet | [10DLC registration](/guides/10dlc-registration) |
| TCPA checklist | The per-send discipline: consent coverage, quiet hours, disclosure language on your capture points | [TCPA compliance checklist](/guides/tcpa-compliance-checklist-tool) |
| Opt-out rules | The keyword list and auto-replies that unsubscribe and re-subscribe your contacts, scoped account-wide | [Opt-out & opt-in rules](/guides/opt-out-rules) |
| Country rules playbook | The flag → verify → promote-to-strict posture you set per market | [Country-gate posture playbook](/guides/country-rules-posture-playbook) |
| Profile assembly | The reusable identity packets (legal entity, documents) and the order you activate them in | [Assemble your tenant's compliance posture](/guides/compliance-profiles-assemble) |
| Quarterly review | The recurring four-check cadence that catches posture drift | [Quarterly posture review](/guides/compliance-posture-quarterly-review) |
| Evidence binder | The one-click pack you generate, seal, and hand to an auditor | [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) |

The platform side is deliberately small: Orbit curates the [country-rules reference](/compliance/country-requirements) 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](/compliance/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](/compliance/posture-overview), and the [posture FAQ](/compliance/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](/guides/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](/guides/10dlc-marketing-baseline).

Verify the registration is settled before you build anything on top of it:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/10dlc/preflight \
  -H "X-API-Key: $ORBIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"brand_id": "num_…", "campaign_id": "num_…"}'
```

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](/guides/tcpa-compliance-checklist-tool) 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](/guides/quiet-hours-configuration) for when you send, and [TCPA quiet hours and windows](/guides/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](/guides/opt-out-rules) page. If you send on WhatsApp or RCS, the channel-specific rule surface is [opt-out rules for WhatsApp and RCS](/guides/opt-out-rules-whatsapp-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](/compliance/opt-out-suppression).

**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](/guides/country-rules-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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms" \
  -H "X-API-Key: $ORBIT_KEY"
```

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](/guides/compliance-profiles-assemble); the creation flow itself is the [compliance profile wizard](/guides/compliance-profile-wizard) (**Settings → Compliance → Profiles → New**).

Drive it from the API:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles \
  -H "X-API-Key: $ORBIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Retail — US SMS",
    "use_case": "sms_10dlc_brand_us",
    "country_code": "US"
  }'
```

A US-SMS-compliant tenant's profile, once filled and submitted, reads like this:

```json theme={null}
{
  "data": {
    "id": "num_8fb2d1b7c00c4ec9a1d3f5e7b9c1d3",
    "name": "Acme Retail — US SMS",
    "use_case": "sms_10dlc_brand_us",
    "country_code": "US",
    "status": "approved",
    "end_user_type": "business"
  }
}
```

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`:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles?status=pending_review" \
  -H "X-API-Key: $ORBIT_KEY"
```

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](/compliance/troubleshooting-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](/guides/compliance-posture-quarterly-review) is the recurring half of this chain: read the [compliance-health score](/compliance/compliance-health), 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:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/binder/generate \
  -H "X-API-Key: $ORBIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"framework": "soc2", "format": "pdf"}'
```

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](/compliance/evidence-binder). Pick the framework your auditor actually asked for; TCPA has no binder framework, so assemble a TCPA pack with the [TCPA evidence pack](/compliance/tcpa-evidence-binder) instead.

**Binder contribution:** this is the binder — the chain's destination.

***

## 3. The first-evidence-binder walkthrough: verify each link, then seal it

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:

| Link | Green check (proceed) | Red check (remediate first) |
| - | - | - |
| 10DLC | Preflight resolves brand + campaign to approved | Campaign `pending` or use-case mismatch — fix in the [wizard](/guides/10dlc-wizard) first |
| TCPA | Checklist answers complete for the campaigns you run | Consent coverage unknown or quiet hours unset — rerun the [checklist](/guides/tcpa-compliance-checklist-tool) |
| Opt-out | A test keyword flips consent and a pre-send check holds suppression | Rule never seeded, or suppression does not hold — re-set per [opt-out rules](/guides/opt-out-rules) |
| Country rules | Target markets looked up; launches preflighted through `/messages/lint` | A live market never looked up, or a `block` verdict left unremediated |
| Profiles | Every gated surface traces to an `approved` profile | A surface gated on `pending_review` — diagnose via [pending surfaces](/compliance/troubleshooting-pending-gated-surfaces) |
| Quarterly review | First review scheduled; cadence owner named | No scheduled review — book one before you claim the posture is "done" |

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](/compliance/evidence-binder#worked-example--soc-2-vendor-questionnaire).

***

## 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](/guides/hipaa-onboarding) sequence.

The comparable [HIPAA onboarding guide](/guides/hipaa-onboarding) walks BAA → HIPAA mode → role restriction → retention → evidence export end to end, in the same chain style as this page; the [HIPAA controls](/compliance/hipaa) reference documents each setting, and the [HIPAA checklist tool](/guides/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.

***

## 5. Before you send: the legal-not-advice preamble, in practice

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](/compliance/country-requirements) 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](/compliance/compliance-health), `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.

***

## Related

* [Assemble your tenant's compliance posture](/guides/compliance-profiles-assemble) — the profile/country-rules/vertical-pack assembly this chain plugs into
* [Quarterly posture review](/guides/compliance-posture-quarterly-review) — the recurring cadence that starts the day the chain closes
* [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) — the generation walkthrough with gated-surface verdicts
* [Compliance evidence binder reference](/compliance/evidence-binder) — framework tables, endpoints, GRC import runbooks
* [Your tenant compliance posture overview](/compliance/posture-overview) — the toggle map of every tenant-owned control
* [Compliance posture FAQ](/compliance/posture-faq) — which surfaces fail open vs. closed
* [HIPAA onboarding](/guides/hipaa-onboarding) — the PHI-scoped counterpart chain
