Skip to main content

​
Per-Topic Compliance FAQ: timelines, ownership, and trigger events

The posture map’s “Start here by topic” table 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) still answers the “which gate fired?” lookups; the 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. 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 and rejections and re-vetting.

​
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. A parallel track for toll-free senders carries its own days-to-weeks review queue on 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 and the code split (tenant TCPA_DIALING_WINDOW_BLOCKED vs federal TCPA_FEDERAL_DIALING_WINDOW_BLOCKED) is on the 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 and the full window resolution semantics on 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.

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

​
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 and the 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 and the BAA state machine on the BAA page.

​
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, 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 and the market list on the 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.

​
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; the entry points on Send Gates → preference center.

​
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, and the scanner’s rule taxonomy is on Spam keywords and content screening. For a carrier-side (not gate-side) flag such as a throughput drop, read Compliance Health Scores 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, and the re-filing flow on 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 and the state machine’s days_until_expiry field carries the countdown.
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.