Compliance is plumbing — boring when it works, catastrophic when it doesn't. v0.6 makes the boring parts visible and self-service.

Self-service data subject requests

Four endpoints (and matching UI at /{org}/settings/privacy):

POST /api/privacy/access — export all data we hold about the requesting user (profile, org membership, request logs metadata, audit-trail entries). Returns a signed download link, JSON format, completes within the GDPR 30-day window.
POST /api/privacy/erase — schedule erasure. Cooling-off period is configurable per-org (default 7 days) so the request can be cancelled at POST /api/privacy/erase/cancel before it processes.
POST /api/privacy/withdraw — withdraw consent for a specific processing purpose (analytics, marketing). The user keeps their account; we stop the specific processing.
POST /api/privacy/consent — record a new consent grant or refresh an existing one.

All four are RLS-scoped — a user can only request their own data; org admins see the queue at the privacy settings page.

What gets recorded

Two new records, both organization-scoped and isolated by row-level security:

Consent ledger — append-only, capturing user, purpose, whether consent was granted, the originating IP and user agent, and when it was recorded. Withdrawal doesn't delete; it appends a new entry marking consent as no longer granted.
Data subject requests — every access / erasure / withdrawal request. Status flows: pending → processing → completed | cancelled | failed. Every transition appends an audit-trail entry so SOC 2 evidence is on rails.

SOC 2 — control framework active. Type II evidence collection ongoing.
ISO 27001 — control framework active.
GDPR — compliant. The four endpoints above are the rights-of-the-data-subject mechanism.
HIPAA — eligible on Enterprise plans. BAA on request.
PCI — delegated to Stripe. We never touch raw card data.

Underlying infrastructure (Google Cloud Run, Supabase, SendGrid) is SOC 2 Type II certified. Read more at /privacy and /security.