How do I handle SOC 2 when my database is on Supabase or PlanetScale?

Inherited vs. Your Controls

Managed database providers handle infrastructure security (physical servers, network isolation, patching). You handle configuration and access security.

Responsibility	Provider (Supabase/PlanetScale)	You
Physical security	Yes	No
Network infrastructure	Yes	No
Database engine patching	Yes	No
Encryption at rest	Yes (enabled by default)	Verify it's enabled
Access controls	API key/connection management	Who has credentials, how they're stored
Row-level security	Provides the feature	Configure and enforce policies
Backup configuration	Provides the feature	Verify backup schedule and retention
Connection security	SSL/TLS available	Ensure SSL is required, not optional

Evidence for Supabase

Evidence	Where to Find It
Supabase SOC 2 report	Request from Supabase (available for Pro+ plans)
Encryption at rest	Database settings showing encryption enabled
Row-Level Security	RLS policies on sensitive tables
API key management	Dashboard showing API keys (anon vs. service role)
Connection pooling	Supavisor configuration
Access controls	Team member list and roles
Backup settings	Point-in-time recovery configuration

Evidence for PlanetScale

Evidence	Where to Find It
PlanetScale SOC 2 report	Request from PlanetScale
Branch-based schema changes	Deploy requests showing schema change reviews
Access controls	Organization member list and permissions
Connection security	Connection strings using SSL
Audit logging	Query insights and access logs

Common Gaps

• Exposed API keys: Supabase anon keys in client-side code without RLS. Ensure RLS policies protect sensitive data.
• Direct database access: Engineers connecting to production via GUI tools without audit logging. Restrict direct access or log all connections.
• Missing backups: Verify that automated backups are enabled and test a restore at least once.
• Shared credentials: Multiple engineers using the same database credentials. Use individual connection credentials where possible.