Trust and security
How customer data is stored, protected and audited
This page states 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.
How customer data is handled
These are properties of how the platform is built, not policies added on top.
Data isolated per organization
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 full history of a protocol, SOP, or report is always available.
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.
Full export on request
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 are separate
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 status
What we support today, what is in progress, and what we do not claim.
21 CFR Part 11
Capable, validated by youElectronic 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 certifiedWe 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 madeThe 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 onlyThe 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 tell customers before adding one.
| Provider | Purpose | Region | Data involved |
|---|---|---|---|
| Vercel | Hosting and delivery of the website and the application | United States (serverless functions); static assets on the global edge network | Request logs, page and application code |
| Convex | Application database, file storage, and backend functions | United States | All organization records, document versions, files, audit log, signatures |
| WorkOS | Authentication, organizations, and membership (AuthKit) | United States | User identity, email, name, organization membership |
| PostHog | Product analytics for the website and the application | United States (US Cloud) | Usage events; person profiles only for identified users |
| Supabase | Storage for website waitlist and request submissions only | Per project; confirmed on request | Name, 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 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.
No secrets in source code
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.