Security & privacy
You are asking people to be candid about how work really happens
That only works if they trust what happens to their answers — and if your security reviewer trusts us. This page sets out the controls we run, the subprocessors underneath them, and the things we do not have yet.
Encryption and key handling
- In transit
- TLS 1.2 or better everywhere, with HTTPS enforced at the edge. No plaintext path exists into the application.
- At rest
- Database and object storage are encrypted at rest with provider-managed keys, on infrastructure that is independently audited.
- Integration tokens
- Slack tokens and API tokens get a second layer of application-level encryption before they are stored, so a database read alone does not yield a usable credential. Cairn holds no credentials for your documentation tools, because it never connects to them.
Multi-tenancy and isolation
- Tenant scoping is structural
- Every customer record hangs off an organization, and scoping is enforced in one central layer rather than by each query remembering to filter. A query that forgets does not return another tenant's data — it returns nothing.
- Staff hold no standing access
- Support staff have no default route into a customer organization. Access comes only from a time-boxed, audited grant, so “no grant” denies structurally rather than by policy.
- Permissions apply to agents too
- MCP and REST queries resolve against the same group and role visibility a person would get. A token cannot read anything its holder could not, so connecting an agent never widens access.
What we do with your people's answers
- Nothing is recorded unconfirmed
- Cairn proposes its reading of what someone said, and that person confirms or corrects it before it enters the knowledge base.
- Contributors own their statements
- Every person has a page listing everything attributed to them, correctable at any time.
- Not a monitoring tool
- Cairn records how work is done, not how hard anyone works. There are no productivity scores and no per-person output metrics — and that is a design constraint, because people do not describe their real workarounds to a system that might grade them.
- PII-free telemetry
- Operational monitoring uses a typed event schema with a field allowlist. Your people's answers are not in our logs or dashboards.
- Models do not train on you
- Language-model providers are used under agreements that prohibit training on customer data. The subprocessor list below is kept current.
Data rights and retention
- Export
- Full data export for a user or an entire organization, on request.
- Erasure
- GDPR erasure anonymises in place rather than deleting rows, so your own process history stays coherent for the people still relying on it.
- Retention
- Configurable retention policies with enforcement jobs, rather than data accumulating indefinitely by default.
- Audit log
- A customer-facing activity trail, viewable and exportable by organization admins — not an internal-only log you have to ask us for.
Subprocessors
Who else touches your data
Cairn runs on third-party infrastructure, and a reviewer needs to know which providers those are and what each one is used for. The full list is published and dated.
Status
What we do not have yet
A security page listing only strengths is marketing. These are the answers you would get in a review anyway, so here they are first.
- Cairn does not hold its own SOC 2 report. The programme is underway; we will publish the report when there is one, and not describe ourselves as certified before then.
- We do not yet hold ISO 27001, and we are not HIPAA-eligible or FedRAMP-authorised.
- SSO and SCIM are built for the Custom plan but are not generally available while we are in cohort onboarding.
Running a security review?
Our Data Processing Addendum and sub-processor list are published. For a questionnaire or anything else, ask — we will send what exists today and tell you plainly what does not yet.