Cambrian Life Sciences LogoCambrian Life Sciences
Trust and Security

Your records, handledthe way an auditor expects

This page states plainly how customer data is stored, who can reach it, what we do and do not claim about compliance, and who processes data on our behalf. Where something is still in progress, it says so.

Report a vulnerability

How customer data is handled

These are properties of how the platform is built, not policies layered on top of it.

One organization, one boundary
Every record carries the organization it belongs to. Every read and write first resolves the signed-in user, their organization, and an active membership; domain code never touches a table without that organization id. Ids supplied by a client are re-checked against the same organization before use.
An audit trail on every change
Every change made through the platform is recorded in an append-only audit log with who, what, when, the value before, and the value after. Nothing else writes to that log, and the activity feed you see in the app is the same record.
Append-only document versions
A document is an identity row; its content lives in versions that are never edited in place. New content is always a new version, so the history of a protocol, SOP, or report is complete by construction.
Hash-chained electronic signatures
A signature records the signer from the authenticated session, the meaning of the signature, a SHA-256 hash of the signed content, and a hash that links it to the previous signature in the organization. Signatures are never deleted; revocation is a recorded event with a reason.
Role-based access through WorkOS
Authentication and organization membership run on WorkOS AuthKit. Roles are assigned per organization: owners, admins, members, advisors, and consultants can write; vendors and viewers are read-only, and that rule is enforced server side.
Encrypted in transit and at rest
The application is served by Vercel and its data lives in Convex. Both encrypt connections in transit with TLS and encrypt stored data at rest. Uploaded files are stored in Convex file storage under the same organization scoping as every other record.
Your data leaves with you
Customers can request a full export of their organization data, including document versions, the audit log, and signature records, and we will provide it in an open format. Deletion of an organization is handled on request in the same way.
Sandbox and production kept apart
Sandbox organizations are flagged as such and populated with a fictional demo company so you can explore without real data. Our development and production backends are separate deployments with separate credentials, and local development never points at production.

Compliance posture, stated honestly

What we can support today, what is underway, and what we do not claim.

  • 21 CFR Part 11

    Capable, validated by you

    Electronic signatures and the audit trail are built to the Part 11 controls: unique signer identity, signature meaning, re-authentication at signing, tamper-evident hash chains, and a complete change history. Compliance is a property of your validated use, not of software alone, so we supply a customer validation pack (user requirements, functional specification, traceability matrix, IQ/OQ/PQ test protocols, and an electronic signature SOP template) that you execute in your own quality system.

  • SOC 2 Type 1

    In progress, not certified

    We are working toward a SOC 2 Type 1 report. We do not hold one today and will not describe ourselves as SOC 2 certified until an independent auditor has issued the report. This page will be updated when that happens.

  • HIPAA

    No claims made

    The platform is built for company operations, documents, and quality records, not for protected health information. We make no HIPAA claims, do not sign business associate agreements, and ask customers not to upload identifiable patient data.

  • GxP scope

    Document and quality modules only

    The controls above are scoped to the document and quality modules, which are the GxP-relevant surfaces. Programs, milestones, finance, vendors, supply chain, and the other operating rooms are non-GxP and are not covered by the validation pack.

Subprocessors

The third parties that store or process customer data on our behalf. We will tell customers before adding one.

ProviderPurposeRegionData involved
VercelHosting and delivery of the website and the applicationUnited States (serverless functions); static assets on the global edge networkRequest logs, page and application code
ConvexApplication database, file storage, and backend functionsUnited StatesAll organization records, document versions, files, audit log, signatures
WorkOSAuthentication, organizations, and membership (AuthKit)United StatesUser identity, email, name, organization membership
PostHogProduct analytics for the website and the applicationUnited States (US Cloud)Usage events; person profiles only for identified users
SupabaseStorage for website waitlist and request submissions onlyPer project; confirmed on requestName, email, company, role, and company size from website forms

Google Tag Manager and Hotjar run on this marketing website only and never load inside the application.

Security practices

How the code gets from a pull request to production.

  • Dependency audits in CI

    Every pull request and every push to the main branch runs a quality workflow that installs from the locked dependency set, lints, typechecks, and builds. Dependency advisories are cleared before a release ships.

  • Least-privilege deploy keys

    Production is deployed with a dedicated deploy key scoped to the production backend, held only in the hosting environment. Nobody develops against production credentials.

  • Split development and production

    Development and production are separate backend deployments with separate identity configuration, separate secrets, and separate webhook endpoints. JSON Web Tokens issued for one environment are not trusted by the other.

  • Secrets never in source

    Credentials live in the hosting and backend environment configuration, never in the repository. Configuration files that carry secrets are excluded from version control, and the build does not depend on any analytics or third-party key being present.

  • Generated code is never hand-edited

    Backend schema and API bindings are regenerated by the owning tool after every change, so what runs in production matches what was reviewed.

  • Server-side enforcement

    Tenancy, roles, lifecycle transitions, and signature requirements are checked in backend functions, not in the browser. A client cannot bypass a rule by calling the API directly.

Responsible disclosure

If you believe you have found a security vulnerability in the website or the application, email security@cambrianlifesciences.com. That address is read by the people who can fix the issue. Include the steps to reproduce, the affected URL or function, and any evidence you have. We will acknowledge your report, keep you informed while we work on it, and credit you if you want us to.

Please do not access, modify, or delete data that is not yours, and do not run tests that degrade the service for other users. We will not take legal action against good-faith research that follows these rules.

Need the validation pack for your own review?

The pack covers the document and quality modules: user requirements, functional specification, traceability matrix, IQ/OQ/PQ test protocols, and an electronic signature SOP template you can adapt to your quality system.