SOC 2 readiness
Scenario: Your customer’s procurement team asks how bug-report data is controlled. You want to show which controls are checked automatically and where the evidence lives.
Mushi Mushi is not SOC 2 certified and no auditor has reviewed it. The server collects evidence toward SOC 2: a nightly job snapshots a small set of controls, retention windows are enforced by cron, and data-subject requests are tracked. This is a starting point for an audit, not a substitute for one.
All of it is in the admin console under Compliance (tabs: Overview, Evidence, Retention, DSARs, Residency). Refresh evidence takes a new snapshot on demand.
Automated controls
The soc2-evidence edge function runs daily at 04:30 UTC and writes one row per project and control to soc2_evidence, with a pass, warn or fail status and the raw payload.
| Control | What is checked | Frequency |
|---|---|---|
| CC6.1 Logical access | mushi_rls_coverage_snapshot() lists every public table and whether RLS is enabled | Daily |
| CC6.7 Data retention | The project has an explicit row in project_retention_policies (warns when defaults apply) | Daily |
| CC7.2 Operations | audit_logs volume over the last 7 days | Daily |
| CC8.1 DSAR handling | Pending data-subject requests older than 30 days | Daily |
| A1.2 Availability | 7-day uptime ratio from the health probes | Daily |
Other controls rely on the platform rather than on Mushi Mushi code:
| Control | Mechanism |
|---|---|
| Encryption in transit | TLS on every Supabase endpoint |
| Encryption at rest | Supabase disk encryption; model and storage credentials in Supabase Vault |
| Backup / DR | Supabase backups and point-in-time recovery on the hosted project |
Audit dashboard
In the admin console: Compliance.
- Evidence: the latest snapshot per control, with the payload JSON for an auditor.
- Retention: each project’s windows and legal hold, plus the last sweep.
- DSARs: filed requests and their status.
- Residency: the region each project is pinned to.
Generating evidence manually
Click Refresh evidence under Compliance, or call the edge function with the service-role key:
curl -X POST https://<your-project>.supabase.co/functions/v1/soc2-evidence \
-H "Authorization: Bearer <service-role-key>"New rows appear in soc2_evidence when the call returns.
Data retention policies
Retention is set per project in Compliance → Retention and stored in project_retention_policies:
| Column | Default | Notes |
|---|---|---|
reports_retention_days | 365 | Must be greater than 0 |
audit_retention_days | 730 | Must be greater than 0 |
llm_traces_retention_days | 90 | Must be greater than 0 |
byok_audit_retention_days | 365 | Must be greater than 0 |
legal_hold | off | When on, nothing in the project is deleted |
On Mushi Mushi Cloud the daily retention-sweep job also applies your plan’s window (Free 14 days, Builder 90, Studio 180) when the project has no explicit policy. It hard-deletes expired reports and writes one audit_logs row per project with the count.
DSAR (Data Subject Access Request)
File a DSAR in the admin console (Compliance → DSARs) or through the admin API with a signed-in user’s access token:
curl -X POST https://<your-project>.supabase.co/functions/v1/api/v1/admin/compliance/dsars \
-H "Authorization: Bearer <user-access-token>" \
-H "Content-Type: application/json" \
-d '{"projectId": "<project-id>", "request_type": "access", "subject_email": "user@example.com"}'
# Returns the new data_subject_requests row (status: pending).request_type is one of access, export, deletion or rectification. The row is the audit trail, not the export: you fulfil the request, then PATCH /v1/admin/compliance/dsars/:id with status: "completed" (and an optional evidence_url) records who completed it and when.