Security

Tenant isolation

This is the question multi-tenant buyers actually care about: what stops another client’s workspace from seeing yours? The answer is that the check happens in the database, below the application, so an application bug returns zero rows rather than someone else’s.

Row-level security on every table

Authorization is enforced by the database, not by application code. Every table in the client portal has row-level security enabled, and access is scoped to your workspace membership. A table with no policy denies everyone by default, so a new table is born locked rather than born open.

No master key in the application

The portal runs with a publishable key only. The privileged key that would bypass row-level security is not in the application, not in its hosting environment, and not in its repository. If the app were compromised tomorrow, the attacker would inherit your session's permissions — not the database's.

Sessions verified, not assumed

Server-side authorization always re-validates the session token with the auth service rather than trusting the cookie it was handed.

Workspace-scoped cookies

Each client workspace runs on its own subdomain and its session cookie is host-only. A session issued for one workspace is invisible to every other workspace and to our marketing site.

Client workspaces are not indexed

Every portal response carries X-Robots-Tag: noindex, nofollow. Your workspace does not appear in search results.

The public website cannot read anything

deadpanlabs.com is capture-only. Its entire database capability is three write functions that validate their input and return nothing. There is no read path, no export path, and no delete path from the public site — by design, so a compromise of the marketing site yields no data at all.

Encryption

In transit

HTTPS everywhere, with HSTS set to two years including subdomains and submitted for preload. Insecure requests are upgraded by policy, and our content-security policy permits no plaintext origins.

At rest

Databases, backups, and object storage are encrypted at rest by our infrastructure providers under their own audited programs (see Subprocessors).

Application-layer encryption for messages

Message bodies in the portal are encrypted with AES-256-GCM before they are written to the database. The key lives only in the server environment — never in the database, never in a browser. A database-level compromise or a raw dump yields ciphertext, not conversations.

Access & authentication

Access is granted, never self-served

Registering an identity and having access are two different things, and only the second one is a permission. A person can register with the auth provider and confirm an email address — that identity carries no access to anything. Every table is scoped to workspace membership by row-level security, and membership is granted only by a workspace owner or admin, or by a verified domain match where a workspace has enabled domain federation. A registered stranger sees no workspace, no data, and no evidence that yours exists.

Password handling

Passwords are handled by our managed identity provider and are never stored by us in recoverable form. The provider enforces a ten-character minimum server-side, rejects passwords found in known breach corpora, and requires re-authentication before a password can be changed. A password change notifies the account holder by email. Google Workspace SSO is available per workspace where you would rather account lifecycle and password policy followed your own identity provider.

Single sign-on

Google Workspace SSO is built and can be enabled for a workspace that wants it, so account lifecycle follows your identity provider.

Roles

Owner, admin, and member. Administrative fields on your own records are readable only by the roles that need them — the member surface is column-limited, not filtered in the UI.

Application & platform security

Enforcing content-security policy

An allowlist CSP is enforced (not report-only) on both the marketing site and the portal, with object-src none, frame-ancestors none, and base-uri and form-action locked to self. There is no wildcard origin.

Full security-header baseline

Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, a locked-down Permissions-Policy, and Cross-Origin-Opener-Policy on every response.

Nothing renders from an origin we do not control

Image sources are restricted to a single allowlist that both the CSP header and the branding form are built from, so a logo URL the browser would refuse is rejected at save time instead of failing silently. Links are sanitized before render. No user-supplied HTML is ever rendered.

Bot and spam protection that fails closed

Public forms are protected by Cloudflare Turnstile plus a honeypot, verified server-side. If verification cannot complete, the submission is refused rather than accepted.

Secrets kept out of source control

Every push and pull request runs a secret scan (gitleaks), a high-severity dependency audit, a deterministic install, and a build. A failure blocks the merge.

Dependency updates

Automated dependency and GitHub-Actions updates run weekly on both applications, triaged monthly.

Preview builds are gated

Non-production deployments are authentication-protected and never publicly reachable.

Data handling

Cookieless analytics

Our marketing analytics stores no IP address, no user-agent, and no identifier — enforced by the absence of those columns in the schema, not by a setting someone could flip back.

Retention windows

Sales inquiries are deleted after 24 months, unconfirmed newsletter signups after 30 days, and analytics events after 14 months. The purge runs as a scheduled database job, not a reminder.

Data-subject requests

Access, export, correction, and erasure requests are handled against a written runbook covering every store the data lands in, completed within 30 days.

Data location

Application and database infrastructure is operated in the United States by the providers listed on our Subprocessors page.

The full list of third parties that may process data on our behalf, and exactly what each one touches, is published at /subprocessors. What we collect from you and why is in our Privacy Policy.

What we don’t do yet

The list below costs us nothing to hide and everything to be caught on. So here it is.

We hold no SOC 2 report and no ISO 27001 certificate.

We have not engaged an auditor. We maintain the underlying control set, policies, and Statement of Applicability internally so we can map to a framework on a client's timeline — but we will not claim an attestation we do not have. If your procurement process requires one, tell us and we will scope it with you.

We have not published an uptime figure.

We have not run external monitoring long enough to have measured one honestly. A number we cannot evidence is worth less than saying so.

We do not run 24/7 on-call.

Deadpan Labs is a small team in a single time zone. Our incident-response commitments below reflect that truthfully rather than borrowing an enterprise SLA.

Point-in-time recovery is not enabled.

We run automated daily backups with a seven-day history and a restore-to-new-project path. Sub-day recovery is available from our provider and we will enable it when a client's data volume or contract warrants the cost.

Incident response

One accountable owner

Security and privacy are owned by a named officer, not a rota. There is no ambiguity about who runs an incident.

Written runbook

Detection, containment, credential-rotation order across every administrative console, eradication, recovery, and post-incident review are documented and rehearsed rather than improvised.

Notification

Where a breach affects personal data, we work to a 72-hour regulator-notification trigger and will notify affected clients without undue delay. Contractual notification windows are agreed in your DPA.