Security & Trust

SOC 2 Type II Certified Providers

Brandkept is built on infrastructure from providers that have achieved SOC 2 Type II certification — the industry standard for security, availability, and confidentiality controls. Our infrastructure stack:

Data Residency

All Brandkept customer data is stored in the United States. Our primary Supabase instance is hosted in US-East-1 (AWS us-east-1). We do not transfer personal data to servers outside the United States without explicit disclosure.

Brandkept SOC 2 Roadmap

Brandkept itself is a startup and does not yet hold its own SOC 2 certification. We are targeting a SOC 2 Type I assessment at approximately $10,000 MRR, followed by a Type II audit. We disclose this transparently so you can make an informed decision about using our service. Our reliance on SOC 2 Type II certified sub-processors is the current mitigation for this gap.

Row-Level Security (RLS) on Every Table

Every database table containing user or child data has Row-Level Security policies enforced at the database layer. This means Supabase's Postgres engine enforces that a user can only read, write, or delete rows belonging to their own account — even if an application-level bug accidentally passes the wrong user ID. RLS is the last line of defense and cannot be bypassed by application code.

Multi-Factor Authentication (MFA)

Brandkept supports multi-factor authentication and strongly recommends it for all accounts. Because Brandkept stores children's financial data, we recommend MFA as a non-negotiable security practice. MFA can be enabled at Settings → Account → Security.

Audit Logging on Minor Data

Every create, update, and delete action on data involving a child — including income records, brand deals, Coogan calculations, and trust accounts — is recorded in an append-only audit log. The audit log captures the user ID, action type, affected record, timestamp, IP address, and user agent. Audit log entries cannot be modified or deleted through the application interface.

Principle of Least Privilege

Internal systems and team members only have access to the minimum data necessary to perform their function. The application's database connection uses a scoped service role for administrative operations and the public anon key for user-facing requests, with RLS enforcing user isolation. No individual has standing access to read user data for routine operations.

Detection Target: 24 Hours

Our internal target for detecting a security incident is 24 hours from the time an anomaly becomes visible in our monitoring systems. PostHog analytics and Supabase's built-in monitoring provide baseline anomaly detection. We are adding Sentry error monitoring as we scale.

Breach Notification: 30 Days

In the event of a confirmed breach affecting personal data, we will notify affected users within 30 days as required by applicable state breach notification laws. Many states (including California, Texas, and Virginia) have shorter notification windows — we target 30 days as a conservative upper bound and will notify sooner if possible.

Notification will be sent to the email address on your account. It will describe what data was affected, what we are doing in response, and what actions you should take.

Breach Counsel and Forensics

We are identifying breach counsel and a forensic investigation firm as part of our pre-launch security planning. Because we handle children's data, we are treating incident response readiness as a mandatory operational requirement, not a post-funding upgrade.