SOC 2 readiness

Every control surface,
listed — not marketed.

The four surfaces that build the audit trail: append-only event logs wired into every signup, encryption at rest with rotation, RBAC join tables, and a transparent data-handling summary you can read end to end.

01 — Append-only audit_logs

Every signup writes an immutable audit row

Both qualification paths — early-access and self-serve — emit an audit row inside the same database transaction. UPDATEs and DELETEs on the ledger fail at the DB layer.

Wired into both signup paths
auditLogs.recordEvent runs on the same transactional client as the parent INSERT so an audit row never exists without its parent write — or vice versa.
  • /api/pilot → db/pilots.js writes audit_logs row with 'insert' + 'pilots'
  • /api/pilot-signups → db/pilotSignups.js writes audit_logs row with 'insert' + 'pilot_signups'
  • Both insert the canonical JSONB payload and a SHA-256 payload_hash the verifier can recompute
Database-enforced append-only
A BEFORE UPDATE OR DELETE trigger raises an exception for any mutation attempt on the ledger — not just an app-layer convention.
  • Trigger name: audit_logs_append_only
  • Function: audit_logs_block_migration() raises 'audit_logs is append-only'
  • Applies statement-level — even bulk DELETEs across the table are blocked
Hash-chained payload
Every row carries payload_hash — a SHA-256 over the canonicalized JSONB snapshot. The same hash is recomputable from a SELECT, so verifier scripts can prove integrity offline.
  • Canonical form: sorted keys, no whitespace (stable across inserts)
  • Helper: db/auditLogs.js hashPayload()
  • Same routine runs for every recordEvent() call — across users and crons
02 — Encryption at rest with rotation

Ciphertext on disk, key version on every row

The audit ledger is encrypted with AES-256-GCM. Every row records the key version that encrypted it, so rotation is a backfill pass — not a re-key.

AES-256-GCM at rest
  • Algorithm: aes-256-gcm — authenticated encryption with a 12-byte IV and 16-byte auth tag
  • Stored as encrypted_payload BYTEA in the format iv ‖ tag ‖ cdata
  • Helper module: lib/audit-crypto.js — encryptPayload() / decryptPayload()
Rotation by key version
  • Every audit_logs row carries key_version SMALLINT (default 1) — the key that encrypted it
  • Rotation: bump AUDIT_ENCRYPTION_KEY_VERSION, re-encrypt the affected rows in a backfill pass
  • DB-side safety-net trigger audit_logs_backfill_encrypted_payload() rejects any insert that skips the encrypted column
  • audit_logs_encrypted_required CHECK (NOT VALID) blocks the unencrypted path at insert time
  • Decryption is symmetric and round-trip verifiable — recompute the payload_hash from the JSONB snapshot to confirm integrity
03 — RBAC with per-action audit rows

Role catalog is mutable. Role assignment is not.

Three tables split the catalog from the assignments. Every assignment writes its own audit row at the DB layer.

roles
Role catalog
Mutable by design — every create writes an audit row
Schema: id, name, description, created_at
Mutability is allowed — changes are logged, not blocked
Every createRole() call emits an audit_logs row inside the same transaction
permissions
Permission catalog
Same mutability + per-action audit row pattern
Schema: id, name, description, created_at
Logged via the same auditLogs.recordEvent() path as roles
Lookup tables for downstream user_roles joins
user_roles
Role assignments
Append-only at the DB layer + per-action audit row
user_roles_append_only BEFORE UPDATE/DELETE trigger raises an exception on any mutation
user_roles_audit_assignment() writes { user_id, role_id, granted_by, granted_at } to audit_logs on every INSERT
This is the key per-action audit trail the SOC 2 evidence pack references
04 — Data-handling summary

What we collect, what we store, what we keep

Short, honest summary — every bullet maps to a code path you can read.

  • No PII retained from sales-call transcripts unless explicitly enabled.
  • Audit-ledger rows are encrypted at rest — plaintext is never persisted (lib/audit-crypto.js).
  • RBAC catalog rows (roles, permissions) are mutable by design — changes are audit-logged, not blocked.
  • Append-only ledger + RBAC join table — DB-layer triggers block UPDATEs and DELETEs (audit_logs_append_only, user_roles_append_only).
05 — Request the controls summary

Send me a SOC 2 readiness summary

Tell us what your procurement team needs in the brief — we will reply within one business day with the matching controls matrix and the supporting policy references.

Request received.

We'll send the SOC 2 readiness summary within one business day.

Want to try Parlo now? →
Ready when you are

Skip the summary — put Parlo on a real call.

Two on-ramps: a qualification-led early-access pilot, or a self-serve sandbox you can spin up in two days.

Request early-access pilot Spin up self-serve pilot