Skip to main content

​
Posture-History Rollups for the Audit Ledger

Orbit documents each of the ~80 compliance controls on its own page — consent, DSAR, BAA, DPA, attestation, HIPAA, quiet hours, traceback, RMD. That depth is by design, but an auditor asks one question: “What was the posture of this workspace over time?” — not per page, per month. This page shows how to roll the audit ledger up over your chosen audit period into a posture-history summary: one rollup per month or quarter, drawn straight from your own audit chain, with the postures that flip over the window, so a SOC 2 evidence binder rows can stay single-valued instead of being a medley of mixed postures.
This page describes Orbit’s platform controls and the rollup convention for reading them. It is not legal advice. Which audit-period structure your SOC 2 reviewer or binder wants depends on your contract and counsel — confirm with them.

​
The audit-shape problem

Your audit ledger records each voice-dialing decision as it happened — a blocked call carries a reason code (outside_federal_window, outside_state_window, state_blocked_day), a suppressed entry, a consent write. Over a month any of three distinct posture bands holds:
  • federal-only — the platform’s one hard guard: the TCPA federal 8 AM–9 PM recipient-local window. The surface defaults open; nothing else gates.
  • federal+state (FTMIN) — you flipped the quiet_hours.voice channel gate on, so the state mini-TCPA overlays (Florida Sunday bans, Oklahoma/Mississippi/Louisiana/Alabama/Arkansas/West Virginia windows) layer on top. See US State Calling Windows.
  • federal+state+tenant (FMAX) — you also run DNC-scrub, RND-safe-harbor, attestation floor, or another tenant-toggleable control on top. The organization was strictest here.
A workspace that sits in one posture for the whole month produces one clean rollup row, but a workspace that shifts mid-window — you flip voice on, you add a DNC scrub — produces a mixed-posture month. The SOC 2 evidence binder (see Evidence Binder) reads whatever shape it finds; a binder generated month-by-month over mixed months is uneven, and a reviewer who cannot tell which gate was active in which week cannot attest your posture. Example of the unevenness: March holds at FTMIN from the 1st until the 15th, then you flip voice on and March sits in FMAX for the second half — the binder’s March row now says something but it is not one posture, and it’s not two postures either: the rollup has to say which, and in what order.

​
The rollup convention — five lines of code

There is no platform-scheduled monthly rollup job to enable. The audit-export flow runs on demand, and the artifact it reads — your audit chain — is tenant-owned; the roll-up is a convention you perform on your own data, on the cadence you choose. The shape is small enough to keep in a notebook:
Read the audit-ledger rows for your window, apply the gate-toggle audit events (settings.quiet_hours.voice, dnc_sync_enabled) as transitions, and emit one rollup entry per contiguous posture segment: the order is deterministic and the boundaries are the timestamps on the gate-toggle events. Any mixed month is split at the toggle boundary into two or three segments. That is the entire convention. The audit chain itself stays what it is: every row is already tamper-evident and replayable (audit-export/verify); the rollup is a reading, not a new data surface, so it inherits the chain’s integrity for free. Generate before a binder generation and the binder’s month-based rows stay single-postured.

​
Lean output for the GDPR guide and BAA

The rollup is minimal on purpose. Each entry carries only:
  • the window — UTC month or quarter,
  • the posture band — one of the three above, in the strictest-first order,
  • the gate toggles that fired — the specific switches you flipped, with the timestamps from the gate-toggle audit events,
  • a back-pointer — e.g. CHANGE_WINDOW_SETTINGS or the audit-event row id the entry summarises.
Two consumer surfaces read the rollup in plain terms:
  • The GDPR posture guide assembles the end-to-end posture over its Section-2 sequence — the rollup is the same exercise over time instead of over controls, and Art. 30 entries pair cleanly with a month-by-month posture ledger.
  • The BAA DPA linkage and desk-side envelopes stay flat-start — the rollup adds the per-window verification “was the gate actually on during that envelope?” answer the BAA review asks.
Nothing in the rollup re-derives posture: it only re-reads the audit events the platform already wrote when you flipped the switches.

​
Configuration — how often to roll up, and where to store it

The cadence is yours. Most SOC 2 reviewers expect monthly, so run the rollup on the first of each month over the previous UTC month. Generate the audit export for that month first, run the rollup over the exported rows, and store the entries alongside the export’s daily_roots and first_hash/last_hash in your own evidence store. When you generate a SOC 2 binder with framework: "soc2" (see Evidence Binder), the binder’s sections reference the same months you rolled, and single-posture rows line up one binder entry to one rollup entry. If you instead run a month where no gate toggled, the rollup is one entry — the window held one posture the whole time, and that is a binder-friendlier month than three mixed-posture months.

​
DSAR + audit-rollup interplay — the rollup withholds PII

The rollup reads audit-event reason codes and gate-toggle events — CHANGE_*, compliance.*, and settings.* audit entries — not contact rows. The audit ledger records who toggled what and when; the rollup aggregates which posture held, and every event counts only an audit id and an actor id (e.g. user_…). A DSAR against a contact therefore does not disturb your rollup — the rollup never carried a contact id to delete. Conversely, if a DSAR erases a caller id, the rollup is unaffected, because the audit chain pseudonymizes its subjects (see Evidence Binder — Reading the pack). Route per-subject evidence requests through the DSAR or audit-export surfaces; the rollup stays aggregate-only by construction.

​
Worked example — a posture shift mid-month

Run on 2026-08-01 over July. Your organization’s July:
  1. July 1–10: federal-only — no tenant gate; only the platform’s federal window applies.
  2. July 11: you enable the quiet_hours.voice channel gate. From this point the state overlays stack on top — federal+state.
  3. July 22: you enable dnc_sync_enabled. The tenant layer stacks — federal+state+tenant.
Three rollup entries for the one month: Generate the binder for July with these three rows and each binder section is single-postured — the auditor reads the same history you lived.