Compliance

Route: /team?view=compliance (Team → Compliance; the old /compliance address redirects there)

Compliance needs the soc2 entitlement, which only the Enterprise plan includes. Without it the Team tab is hidden, and opening the address shows which plan includes it.

Scenario 1: A customer asks how you handle security before signing. You want to show the current control status and retention settings in one place, and export the audit log as a CSV (Team → Audit), without a meeting. Mushi Mushi is not SOC 2 certified; it collects evidence toward it.

Scenario 2: A user emails saying they want all their data deleted (GDPR Article 17). You need to log the request, track its status, and respond within 30 days.

The Compliance view in Mushi Mushi handles both in the console. It has five tabs: Overview, Evidence, Retention, DSARs and Residency.

Navigating the page

On the Overview tab, filter chips focus the page:

Chip	Shows
All	Every section: controls, DSARs, retention, residency
Open	Failing or warning controls, plus pending and in-progress DSARs
Failing	Failing controls, plus open DSARs 21 days old or older
At risk	Controls with warnings
Legal hold	Projects on legal hold; retention sweeps are paused

The snapshot strip shows Controls (passing out of total), Open DSARs, Legal holds and the Cluster region.

SOC 2 control evidence

The evidence table shows a snapshot of your control state across SOC 2 trust service criteria. Each row is a control that the soc2-evidence edge function assesses automatically.

Status	Meaning
PASS ✓	Control is satisfied — evidence is clean
WARN ⚠	Control is partially satisfied — needs attention
FAIL ✗	Control is violated — action required before audit

The table shows Control, Label, Project, Status and Generated. The payload button on a row opens the raw JSON evidence that was used to compute the status.

To generate a fresh snapshot: click Refresh evidence. This triggers the soc2-evidence edge function which re-assesses all controls against the current state.

To export for an auditor: click Export PDF. It opens the browser’s print dialog for the page, so you can save it as a PDF.

Data residency

Each project can be pinned to a region: us, eu, jp or self.

Pinning records the region; it does not move data today. Mushi Mushi cloud runs on a single Supabase project, and the regional hostnames are reserved for future routing, so every region currently resolves to the same API. Once pinned, a project cannot be re-pinned from the console (the API answers 409); moving regions means contacting support.

Retention policies

Control how long Mushi Mushi keeps different data categories for each project. A project with no custom policy shows Set a custom policy.

Category	Default	When to change
Reports	365 days	Shorten if you have GDPR delete obligations; lengthen for longer-term trend analysis
Audit log	730 days	Keep at 730 (2 years) for SOC 2 CC7.2; shorten only if legally required
LLM traces	90 days	Shorten for cost (storage); lengthen if you need longer A/B test history
BYOK audit	365 days	Keep at 365 for key rotation audit trails

Place on legal hold / Lift legal hold: suspends automated deletion for a project. Use it when you receive a litigation hold notice.

Changing a value opens a confirmation that says what the nightly sweep will delete; the change saves when you confirm.

Data Subject Access Requests (DSAR)

Use this section to manage requests from users exercising their rights under GDPR, CCPA, or similar regulations.

Filing a DSAR

On the DSARs tab, choose the Request type: Access, Export, Deletion or Rectification.
Enter the Subject email, and the Subject user ID (optional) if you have it.
Add Notes (optional) with any context from the user’s email.
Click File DSAR.

The request appears in the DSAR table with status pending.

DSAR workflow

Status	Action	When
`pending`	Start triage	Soon after receipt
`in_progress`	Complete	When data export/deletion is done
`in_progress`	Reject…	Only with a valid legal basis; you must give a Rejection reason

Age turns amber at 21 days and shows overdue at 30 days for an open request. Open requests 21 days old or older also appear under the Failing chip.

Common tasks

Preparing for a SOC 2 audit

Open the Failing filter and resolve every failing control first.
Switch to At risk and plan remediation for controls with warnings.
Click Refresh evidence to get a fresh snapshot.
Click Export PDF and share with your auditor.

Choose Deletion, enter the subject email, then File DSAR.
Click Start triage.
Delete the user’s data. Filing a DSAR does not delete anything by itself; your backend can call POST /v1/sdk/erase-subject for that end user.
Click Complete once deletion is done.
The DSAR row stays as your compliance record.

Checking a project’s recorded region

Open the Residency tab.
Find the project and its pinned region. Remember that pinning is a record today, not a separate data location (see Data residency).

API


GET   /v1/admin/compliance/stats
GET   /v1/admin/compliance/evidence
POST  /v1/admin/compliance/evidence/refresh
GET   /v1/admin/compliance/retention
PUT   /v1/admin/compliance/retention/:projectId    { reports_retention_days, audit_retention_days, llm_traces_retention_days, byok_audit_retention_days, legal_hold, legal_hold_reason }
GET   /v1/admin/compliance/dsars
POST  /v1/admin/compliance/dsars                   { projectId, request_type, subject_email, subject_id, notes }
PATCH /v1/admin/compliance/dsars/:id               { status, rejection_reason, evidence_url, notes }
GET   /v1/admin/residency
PUT   /v1/admin/residency/:projectId               { region }

Audit log: source data for many SOC 2 controls
Security → Data residency: infrastructure and encryption detail
Security → SOC 2: the control framework Mushi Mushi maps to