Security

How the platform protects your data

A candid inventory of what’s actually shipped — including the gaps we haven’t closed yet. We’d rather be specific than wave around “enterprise-grade” copy.

Last updated · May 2026

Identity & access

Authentication

Clerk (SOC 2 Type II provider). Google OAuth + email/password, MFA support, password policy, brute-force throttling, and session management all owned by Clerk. We never see a password.

Approval gate

Self-signups land in a pending state and can't reach the platform until a super-admin approves them — a stray Google account can't auto-provision itself in.

Webhook integrity

Clerk and Inngest webhooks are signature-verified (svix / HMAC) before any database write.

Authorization & multi-tenant isolation

Three-tier role model

super_admin (Soundcheck staff), admin (agency operator), user (agency seat-holder). Roles are enforced server-side; client-side checks are UI sugar only.

Scoped queries by default

Every database read for a tenant resource — research, focus groups, personas, dashboards — flows through a single helper that filters by agency and assignment. No raw queries bypass it.

Layout-level gates

Direct URLs to super-admin or admin-only routes are gated at the layout layer, so a stale link or a guess can't reach a page outside the visitor's role.

Cross-agency rejection

Server actions validate that every resource they touch belongs to the operator's own agency before mutating. Cross-agency operations require a super-admin-only path.

Soft delete

Tenant resources carry a deleted-at flag; queries always filter. Accidental deletes are recoverable. Hard delete requires direct DB access.

Data isolation between operators

Every operator’s data is siloed at the schema layer (every tenant table carries an agency_id foreign key). On top of that schema isolation, §7.3 of the Trial Tier Terms makes the following commitments contractually binding:

We will not use one operator’s confidential information or client data to develop products competing with that operator’s individual business.
Aggregated learnings used to improve the Platform are anonymized to a level where no specific operator or end-client is identifiable.
Internal admin access to operator data is limited to personnel whose access is reasonably necessary, all bound by written confidentiality.
Internal admin-access logs are maintained and producible on a good-faith request.

Transport, storage, and secrets

TLS in transit

All traffic over Vercel TLS 1.2+. Database connections use Neon TLS. File uploads go to Vercel Blob via signed HTTPS URLs.

At-rest encryption

Neon Postgres encrypts at rest with AES-256. Vercel Blob encrypts at rest.

Secrets management

All API keys (Clerk, Anthropic, Inngest, Postgres, Blob, share-link signer) live in Vercel environment variables. Nothing is committed to source. The local .env.local file is gitignored.

Anthropic API key isolation

Server-side only. Every Claude call runs in Inngest functions or server actions; the key is never reachable from a browser.

File uploads & parsing

Direct-to-Blob uploads

Files go straight from the operator's browser to Vercel Blob via short-lived signed URLs. The platform never proxies the bytes through its own functions.

Server-side parsing

PDFs, DOCX, XLSX, PPTX, images — all extracted server-side. Raw binaries stay in Blob; only extracted text and relevant metadata flow into Claude prompts.

Mime / size validation

Validated at upload time and again at parse time.

Public sharing (branded dashboards)

Non-guessable URLs

Public share links use a 12-character random slug — 71 bits of entropy, infeasible to enumerate.

Optional password gate

Per-share bcrypt-hashed password. After entry, a 24-hour cookie-bound session.

Disable on demand

Disabling a share returns 404 immediately; the slug stays bound to the project so re-enabling is instant.

No platform chrome on shared views

Public viewers see only the branded dashboard — no operator nav, no edit controls, no feedback chat.

Pricing & billing integrity

Operators can’t retroactively re-tag completed work to dodge invoiced amounts. Billing is a property the platform actively protects:

Snapshot model

Every project, at creation, snapshots its tier, commission %, MSRP, and end-customer discount. Subsequent tier changes never retroactively re-bill.

Tier change audit log

Every transition recorded with actor, timestamp, prior/new tier, and a reason. Visible on the agency detail page.

Quarter close

Once a quarter closes, line items are frozen and uneditable. Reopening requires an explicit super-admin action with a logged reason.

Partnership Agreement record

The long-form Operator Partnership Agreement (signed off-platform via Docusign) is recorded per agency: signed-by name, signed date, optional executed-PDF blob, notes.

Legal record-keeping

Built for litigation-readiness — not because we expect litigation, but because the alternative is reconstructing acceptance trails from logs after the fact:

Per-user T&C acceptance

End User Terms (every user) and Trial Tier Commercial Terms (admins of Trial-tier agencies). Each acceptance captures: ISO-8601 UTC timestamp, IP address, user-agent string, exact version accepted.

Version re-prompt

When we publish a new version, every user whose accepted version no longer matches is re-prompted on their next platform load. Prior acceptance stays on record as historical evidence.

Admissibility framework

Acceptance is recorded electronically pursuant to the Florida Uniform Electronic Transaction Act (Fla. Stat. ch. 668, Part I) and the federal E-SIGN Act (15 U.S.C. § 7001 et seq.).

Litigation export

The super-admin user audit page renders a printable per-user record with full timestamp, IP, user agent, accepted version, and the framework citations. CSV export covers every audit field for hold-and-produce workflows.

AI handling

No model training on prompts

Anthropic's standard API agreement does not use API prompt or response content to train models. Operator and client data sent to Claude stays operator-confidential.

Synthetic personas

Personas referenced in any deliverable are synthetic constructs grounded in research; they do not represent or correspond to any real, identifiable natural person. Platform outputs do not contain personal data of real natural persons within the meaning of applicable data-protection laws (Trial Terms §3.4).

Per-engagement context isolation

Each Claude call is scoped to one operator's project. We don't pool operators' uploads or context across tenants.

Operational observability

Function logs

Every server action and route handler is logged with status and duration via Vercel.

Inngest run logs

Every background pipeline (research, focus group, customer journey) is durable, retriable, and inspectable on the Inngest dashboard with per-step inputs and outputs.

DB audit fields

Every tenant row carries created-at / updated-at / deleted-at, plus a tier-change history table for agencies.

What we don't handle (by design)

No payment data on the platform

Operators are billed off-platform via wire/ACH on a NET-15 invoice cycle (Trial Terms §4.4). No credit cards, no Stripe vault, no PCI scope. That's a feature.

No real-person personal data in deliverables

The methodology generates synthetic personas. Deliverables don't contain personal data of identifiable natural persons under GDPR / CCPA. Materially smaller data-protection surface.

What we haven't done yet

If a client’s security team asks, here’s what we answer straight rather than dodge:

No SOC 2 / ISO 27001 attestationof our own. Clerk, Vercel, Neon, and Anthropic are SOC 2; the platform on top isn’t certified. On the roadmap; not signed-and-attested today.
No third-party penetration test conducted to date.
No bug bounty program.
No platform-wide rate limitingbeyond Vercel’s edge protections. Per-user / per-agency throttles are not implemented.
2FA is supported by Clerk but not enforced for operators by default. Easy to flip on per-agency if a client requires it.
No custom Content Security Policy headers beyond Next.js defaults are currently set. Easy add.
No formal GDPR data-processing agreement template published yet. The platform is built for EU agencies among others, and Trial Terms §3.4 materially reduces the GDPR surface; a published DPA template is a near-term to-do.

Reporting a security issue

If you spot something — a vulnerability, an unintended behaviour, data appearing where it shouldn’t — write to info@soundcheckinsights.com with the subject line Security report. We prioritise these above everything else and will acknowledge within one business day.

For legal questions about these terms, write to valter@soundcheckinsights.com.