Security · Subprocessors · Data processing

Security overview

Last reviewed 3 June 2026

A plain, honest account of how we protect data. We describe what we actually do, and we are explicit about what is on the roadmap rather than in place today.

Data minimisation by design

The free, public learning experience has no sign-in and stores no personal data. Progress lives in your browser’s local storage, never on our servers. Personal data only exists for account and firm-seat features, and even then we keep it to the minimum: an e-mail address, a firm role, and learning progress.

Access control

Row-level security (RLS). Every database table that holds user data enforces RLS, so a signed-in user can only ever read or write their own rows.
Least-privilege service role. Privileged operations (granting entitlements, reviewing verifications, firm-wide reads) run through a service role that is server-only and never exposed to the browser. Privileged writes are deny-by-default for ordinary users.
Founder-gated admin. The admin console is restricted to a single founder allowlist, enforced both in middleware and in code.

Encryption and transport

All traffic to and from the platform is served over HTTPS (TLS), so data is encrypted in transit. Data at rest is held by our database and hosting providers (see subprocessors), which provide encryption at rest.

No PII on public paths

Public pages, the lessons and the episode player, carry no personal data and require no account. This sharply limits the surface where personal data could be exposed.

Append-only logs

Privileged actions (verification decisions and entitlement changes) are written to an append-only audit log that only the service role can write, and that ordinary users cannot read or alter. Assessment attempts are similarly recorded in an append-only log. This gives a tamper-evident record of who did what, and when.

Input validation

Server actions and routes validate and authorise every request server-side; we never trust client input. Submitted links (for example, musician-verification links) are validated to be genuine http(s) URLs before an admin ever sees them.

Authentication

Accounts use secure email-and-password sign-in (managed by Supabase Auth, with hashed credentials and refreshed sessions). We deliberately keep the stack simple: we do notoffer SAML/OIDC single sign-on, and we’d rather tell you that plainly than imply a roadmap we don’t intend to build.

Certifications

We do notcurrently hold ISO 27001 or SOC 2 certification, and we will not claim otherwise. If your procurement process requires a completed security questionnaire, get in touch and we’ll answer it honestly. The same security baseline below applies on every plan. It is never a paid add-on.

Reporting a vulnerability

Found a security issue? Report it through our contact form (pick the Security topic). We appreciate responsible disclosure and will respond promptly.