> ## 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. # Per-Topic Compliance FAQ: timelines, ownership, and trigger events > The questions a compliance officer asks about each of the eight lens topics — 10DLC, TCPA quiet hours, GDPR/DSAR, STIR/SHAKEN, HIPAA/BAA, sender-ID country rules, KYC, and opt-out — with platform-paced vs external-paced timelines, tenant-vs-platform ownership, and runbook routes for common trigger events. # Per-Topic Compliance FAQ: timelines, ownership, and trigger events The posture map's ["Start here by topic" table](/compliance/posture-overview) lists eight regulatory lenses: 10DLC registration, TCPA quiet hours, GDPR/DSAR, STIR/SHAKEN, HIPAA/BAA, sender-ID country rules, KYC documents, and opt-out/consent. That table tells a builder *where the control lives*. This FAQ condenses the questions a **compliance officer** asks about each topic instead: who owns the decision, how long the external approval actually takes, and what to do when a specific trigger event lands on your desk. The routing FAQ ([sends, calls, and registration gates](/compliance/faq)) still answers the "which gate fired?" lookups; the [posture FAQ](/compliance/posture-faq) still covers the platform mental model. This page covers per-topic timelines, ownership, and trigger responses — nothing here supersedes the deep page for a topic, which stays authoritative. This page describes Orbit's platform controls. It is **not legal advice.** Which laws apply to your traffic, and what posture is adequate, depends on your jurisdiction, your recipients, and what you send. Confirm with qualified counsel. *** ## Timeline realism: what is platform-paced vs external-paced The single most common compliance-planning error is modeling an externally-gated step as an instant, platform-paced step. Split every topic's path into the two halves below, and budget the external half first. | Topic | Platform-paced (minutes to enable) | External-paced (days to months of lead time) | | -------------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **10DLC** | Register the brand + campaign in the wizard; per-carrier statuses poll automatically | Carrier review — brand + campaign approval typically 1–5 business days, and retesting cycles on rejections | | **Toll-free verification (TFV)** | Submit the verification form in the TF wizard | Carrier-side TFV review — plan days-to-weeks; an unverified toll-free sender degrades before any gate posture helps it | | **TCPA quiet hours** | Enable the per-channel org gate or the campaign fallback window — both take effect immediately | None (federal window + state overlays are active immediately; no approval queue) | | **GDPR/DSAR** | Wire your intake path (operator POST, portal, or both) immediately | The SLA clocks themselves (GDPR 30 days, CCPA/CPRA 45) — external-paced by statute; your internal intake must leave review time inside the deadline | | **STIR/SHAKEN** | Attestation floor and delegate-cert registration are in-tenant | Delegate certificates self-register in minutes; this is the one topic with no external queue | | **HIPAA/BAA** | HIPAA mode enables the moment `GET /api/v1/compliance/baa` returns `executed` | BAA execution depends on your legal review and counter-signature — days to weeks of internal counsel before the gate opens | | **Sender-ID registration** | Register the sender and attach KYC documents up front to avoid a re-submission loop | Per-country ranges: some markets approve in days, some take weeks — plan country-by-country, not as a one-shot batch | | **KYC documents** | Upload documents and assemble a compliance profile in minutes | A country that requires review cycles on the regulator, not the upload; an incomplete packet resets the clock | | **Opt-out/consent** | STOP / Consent API / preference center writes suppress pre-dispatch immediately | Legacy-list backfill depends on *your* data supply; import the legacy CSV before the first campaign, not after | Use this to answer the approval-latency question a compliance officer actually budgets against: "what do we have to wait on, and how long?" Only two topics (TCPA quiet hours, STIR/SHAKEN delegate certs) have no externally-gated step at all. *** ## 10DLC — who approves what, and how long to plan for ## Who approves a 10DLC brand or campaign — the platform or the carrier? **The carriers approve; Orbit submits.** The platform files the brand and campaign packet on your behalf and polls the carrier-side status, but the approve/reject decision lives with the carriers (and The Campaign Registry's vetting layer). A rejection names the cited gap in its payload — identity payload on a brand rejection, use-case/samples on a campaign rejection — and the remedy (fix-and-resubmit versus re-vet) differs per side. See [10DLC registration](/guides/10dlc-registration) and [rejections and re-vetting](/guides/10dlc-rejections-and-revet). *** ## How long does 10DLC approval take, and when do I start sending? Brand + campaign review typically clears in **1–5 business days**, and per-carrier statuses (`mnoStatuses`) clear separately — a carrier that hasn't reported back yet degrades even if another has approved. US long-code traffic without an approved campaign degrades regardless of gate posture, so run the registration first and flip quiet hours, DNC, and suppression in parallel while you wait. The full lifecycle — submit, per-carrier poll, reject, resubmit, re-vet — is on [10DLC registration](/guides/10dlc-registration). A parallel track for toll-free senders carries its own days-to-weeks review queue on [toll-free verification](/guides/toll-free-verification). *** ## TCPA quiet hours — what the platform owns vs what the tenant owns ## Which quiet-hours control is the platform's, and which is mine to flip? The **federal 8 AM–9 PM recipient-local dialing window** is platform-owned: campaign and dialer voice to US (+1) recipients outside it is hard-blocked (`422 TCPA_FEDERAL_DIALING_WINDOW_BLOCKED`), with no tenant toggle and no fail-open on a timezone-unresolved recipient. The stricter state mini-TCPA overlays (Florida's Sunday ban, Mississippi's 7:30 PM close, and the other mini-TCPA states) ride on top, also not a tenant knob. Everything else — the per-channel org gate, the campaign fallback window, and the `consent_overrides_quiet_hours` carve-out — is tenant-owned and ships off. The asymmetry list is on [the posture map](/compliance/posture-overview) and the code split (tenant `TCPA_DIALING_WINDOW_BLOCKED` vs federal `TCPA_FEDERAL_DIALING_WINDOW_BLOCKED`) is on [the TCPA federal voice guard](/concepts/tcpa-federal-voice-guard). *** ## How do I prove a send time is permitted before I schedule it? Run `GET /compliance/quiet-hours/preview` against the recipient — it returns the resolved window and the DST-safe `next_allowed_at` UTC instant a held send unlocks at, with no send attempted. Read it alongside the dashboard compliance-health score before a rollout, and schedule against the absolute timestamp rather than polling. The endpoint contract is on [Quiet-Hours Preview](/compliance/quiet-hours-preview) and the full window resolution semantics on [Send Gates](/compliance/send-gates). *** ## GDPR / DSAR — who approves the SLA clock, and who files the request ## Who approves a DSAR intake, and what deadline applies? There is no external approval queue — the intake is demand-driven and the delay that matters is the **statutory response clock** your intake opens: GDPR 30 days, CCPA/CPRA 45, PDPA 30, PIPEDA 30, DPDP 30. Orbit surfaces the intake (operator-filed via `POST /compliance/dsar`, the public self-service portal, or both) and tracks the SLA per jurisdiction you tag, but mapping a request to its lawful basis and answering in time is your compliance function. The per-regulation deadline table and the intake/verify/fulfill workflow are on the [DSAR page](/compliance/dsar). *** ## How long does a DSAR actually take through Orbit? Intake is instant; fulfilment follows your own process inside the statutory window. The intake itself — a single POST, or a contact's self-service submission behind your preference-center/privacy link — lands in the pipeline immediately and starts the SLA tracker for the jurisdiction you tagged. What the pipeline does not do for you is the identity-verification and fulfilment decision: those stay with your compliance officer. The full workflow and the per-regulation clocks are on the [DSAR page](/compliance/dsar). *** ## STIR/SHAKEN — the one topic with no external queue ## How long does attestation setup take, and who approves a delegate certificate? There is no approval queue here — attestation is **platform-derived, tenant-controlled**. The level an outbound call attests (A/B/C) resolves at call time from number ownership, leases, and any delegate certificates you registered; a delegate certificate self-registers in minutes against your verified external numbers and lifts their attestation C → B. The deliberate ceiling — a delegate cert never reaches A, because a self-registered artifact cannot confer full attestation — is the one asymmetry on this topic. Setup is therefore the fastest of the eight topics; plan it as a same-day task. Details on [Attestation](/compliance/attestation) and the [STIR/SHAKEN posture guide](/compliance/stir-shaken-posture-guide). *** ## HIPAA / BAA — execution before enablement ## Who countersigns the BAA, and how long until HIPAA mode flips on? The BAA countersignature is **yours** — Orbit supplies the e-sign pipeline (template rendering, typed signature capture, immutable execution timestamp, stored PDF), but an executed agreement depends on your legal review and counter-signature, so days-to-weeks of internal counsel is the real timeline. Only once `GET /api/v1/compliance/baa` returns `executed` will the owner flip HIPAA mode on (`PUT /api/v1/settings/hipaa`); until then the mode refuses to enable and PHI-bearing sends are rejected with `422 HIPAA_BAA_REQUIRED` fail-closed. The execute-order (BAA → mode → follow-on controls) is on the [HIPAA posture guide](/compliance/hipaa-posture-guide) and the BAA state machine on the [BAA page](/compliance/baa). *** ## When is the BAA expiry my trigger event? An executed BAA runs a standard one-year term, and the re-execute banner appears when **60 days remain**. Handle it before the term lapses: while executed the PHI gate stays open, but past `expires_at` the status re-derives to `expired` on every read and the PHI send gate closes again until you re-execute (owner-only, the same e-sign flow). Don't treat the banner as advisory — it is the runbook trigger for [re-execute on the BAA page](/compliance/baa), and the state machine counts down in `days_until_expiry`. *** ## Sender-ID country rules — per-country approval queues ## Who approves a sender-ID registration, and what latency range do I budget per country? Approval is granted by the **regulator or carrier in that country**, not the platform — Orbit files the registration packet, and the reviewer in each destination moves the status. Latency is per-country, not global: some markets clear in days, some in weeks, and a re-submission loop on an incomplete KYC packet resets that clock. Because the per-country approval queues don't batch, treat sender-ID as a per-destination planning item rather than one launch step. The per-country `registration` level (`none` / `recommended` / `required`) is on `GET /api/v1/compliance/country-requirements`; the filing workflow is on [Sender-ID Registration](/compliance/sender-id-registration) and the market list on the [Sender-ID country matrix](/guides/sender-id-country-matrix). *** ## KYC documents — the packet behind every gated approval ## Who approves a KYC-backed number or sender, and what do I owe per country? The regulator or carrier in the destination approves; Orbit assembles the packet you upload (documents, compliance profile) and attaches it by id to the gated asset. The numeral fact a compliance officer budgets against: a regulated-country number idles at `pending_compliance` until an **approved** compliance profile satisfies it, and an incomplete packet resets the review clock. Attach the country's KYC documents up front at registration to avoid the re-submission loop. The lifecycle — upload, profile assembly, expiry alerts, rotation — is on [KYC documents](/compliance/documents-kyc). *** ## Opt-out / consent — platform-paced, but scope is tenant-owned ## Is opt-out enforcement immediate, and who owns the scope decision? Enforcement is **platform-paced**: a STOP keyword, a Consent API revocation, a preference-center opt-out, or a CSV import all write the suppression ledger in one transaction, and a suppressed address is dropped pre-dispatch on every channel its scope covers. The **scope** decision is tenant-owned: a phone row defaults to scope `all` (voice and dialer included), an email row to `email`, and a scope mismatch — importing the CSV with the wrong channel — is the one case where an imported opt-out doesn't gate what you expected. Scope semantics are on [Opt-Out & Suppression Lists](/compliance/opt-out-suppression); the entry points on [Send Gates → preference center](/compliance/send-gates). *** ## Trigger events — three real incidents, runbook-routed ## My campaign got flagged — which runbook covers the recourse? Route by the error code family, then to the runbook. A `422 POLICY_VIOLATION` names the matched rule in its `details` payload — that is the pre-send **policy scanner** refusing on a keyword hit, not a registration gate. A `422 COMPLIANCE_PROFILE_REQUIRED` or `…_NOT_APPROVED` is the **profile/KYC gate** firing before dispatch. The full per-code routing table is on [troubleshooting: compliance send-gate error codes](/compliance/troubleshooting-compliance-error-codes), and the scanner's rule taxonomy is on [Spam keywords and content screening](/compliance/spam-keywords). For a *carrier-side* (not gate-side) flag such as a throughput drop, read [Compliance Health Scores](/compliance/compliance-health) first — the ranked `warnings` array points to the sender about to be throttled before the traffic degrades. *** ## A destination country changed its registration rule — do I re-file my profile? Yes — a country-rules feed refresh **never rewrites a filed profile**; it lands in the structural columns of the country table only, so when a destination raises its registration level (say, `recommended` → `required`) the new rule applies to existing traffic immediately and you file against the new rule, not a protected profile you were carrying. The current per-country level reads on `GET /api/v1/compliance/country-requirements`; what a refresh can and cannot change is on [Country rules auto-refresh feeds](/compliance/country-rule-feeds), and the re-filing flow on [Sender-ID Registration](/compliance/sender-id-registration). A `rejected` row is recourse by re-submission, not re-verification: read the reviewer notes, fix the cited gap, and re-file. *** ## My BAA expires in 60 days — what do I do before the PHI gate closes? Execute the re-sign flow now — once `days_until_expiry` reaches 60 the dashboard shows the re-execute banner and the owner-only `execute` flow reopens, so an executed BAA doesn't have to lapse before you re-file it. Past `expires_at` the status reads `expired` and the PHI send gate closes fail-closed again until re-execution; the re-derive is from the stored `baa_executed_at` timestamp on every read, so a missed daily cron doesn't quietly extend coverage. The re-execute runbook is on the [BAA page](/compliance/baa) and the state machine's `days_until_expiry` field carries the countdown. *** ## Not legal advice — the ownership disclaimer for all eight topics None of the above is legal advice. Orbit is the conduit and the ledger: it carries your sends, enforces the gates you set, and keeps the auditable record (consent decisions, suppression entries, scrub results, certifications). It does not decide that a send is compliant, does not file with a regulator for you, and does not send customer notices for you. The duty-ownership split on each topic — which step the platform takes and which the carrier, regulator, or your own counsel owns — follows the canonical responsibility allocation, and the posture you choose is additive from an open default on every tenant-owned control. Confirm your obligations with qualified counsel. *** ## Related references * [Your Tenant Compliance Posture: The Toggle Map](/compliance/posture-overview) — the eight-topic "Start here" table this page turns into questions. * [Compliance FAQ: sends, calls, and registration gates](/compliance/faq) — the routing FAQ this page complements. * [Compliance Posture FAQ](/compliance/posture-faq) — the platform-level mental model: fail-open vs fail-closed, one platform-owned rail, defaults open. * [Sender-ID Registration](/compliance/sender-id-registration) — the filing workflow behind the per-country approval queues. * [KYC documents](/compliance/documents-kyc) — the packet lifecycle behind every gated asset. * [BAA](/compliance/baa) — the execute → expire → re-execute state machine. * [Troubleshooting: compliance send-gate error codes](/compliance/troubleshooting-compliance-error-codes) — the recourse runbook the flagged-campaign trigger routes to. * [Configure Your Tenant's Posture Before the First Send](/compliance/tenant-posture-first-run) — the day-one runbook the trigger events cite. * [DSAR](/compliance/dsar) — the intake and SLA-clock workflow. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — scope semantics and the entry points.