Security at Sorby
Sorby is a small company. We do not have a SOC 2 report yet, and we will not pretend otherwise. What we do have is a deliberately small attack surface, vendors who carry their own audited compliance, and a security model written down so your team can read it before signing.
Last updated: 2 May 2026.
Where your data lives
We do not run a database, queue, or object store outside this list. We do not ship customer data to any analytics or marketing tool. When that changes, this page changes first and customers are notified at least 30 days in advance.
| Sub-processor | Purpose | Location |
|---|---|---|
| Supabase | Postgres, file storage, pgvector, backups | EU (Frankfurt) |
| Vercel | Hosting, edge delivery, request logs | Global edge; logs in US |
| Clerk | Authentication, identity, MFA | United States |
| Upstash | Rate-limit counters (no PII) | Global edge; primary US |
| Anthropic | LLM inference (Claude API) | United States |
Full list with privacy-policy links and change-notice mechanism: /legal/sub-processors.
Encryption
In transit
All connections between your browser, our application, our database, and every sub-processor use TLS 1.2 or higher; TLS 1.3 is negotiated wherever both ends support it. HSTS is enabled on sorby.io and all subdomains.
At rest
Supabase encrypts Postgres storage and backups with AES-256 (managed by AWS KMS). Vercel encrypts build artifacts and logs at rest. Clerk encrypts identity records at rest. Upstash encrypts Redis at rest with AES-256. Backups inherit the same encryption as primary storage.
Secrets
Application secrets live in Vercel environment variables, scoped per environment, and in a password manager for the founding team. They are never committed to the repository, never logged, and rotated on personnel change or suspected exposure within 24 hours.
Tenant isolation
Sorby is multi-tenant. Every row of customer data is tagged with a workspace_id. Isolation is enforced on two layers.
Application layer (primary today)
Every read and write goes through a server action that first verifies the requesting user has an active membership row for the target workspace. Every database query is scoped by workspace_id in its WHERE clause. Cross-workspace queries do not exist in the codebase.
Database layer (active enforcement)
Postgres Row-Level Security policies are written and applied for every entity table. Every workspace-scoped server action runs inside a transaction that switches to a non-privileged app_server role with SET LOCAL ROLE and sets session variables for app.workspace_id and app.user_clerk_id before any query executes. RLS policies enforce workspace isolation at the database level on every read and write.
There is no shared cache, queue, or search index that crosses workspace boundaries.
Audit log
Every state change inside a workspace — entity created, edited, moved between stages, gate passed, gate rejected, member added or removed, scoring model edited — is recorded in the audit_events table with: the acting user's identifier, the affected entity, the old and new values for changed fields, and a server-side timestamp. Records are append-only; the application exposes no API to delete or rewrite them. Audit history is visible in the workspace UI and exportable as CSV by workspace admins.
Access controls
- Sign-in is provided by Clerk. Email + password and Google OAuth are supported today. SSO via SAML 2.0 is on the roadmap.
- Multi-factor authentication is available to every user (TOTP and passkeys).
- Workspace roles are owner, admin, and member; permissions are checked server-side on every mutation.
- Production database access is limited to the founder, plus a named operations contact on incorporation. Access is audited via Supabase's built-in connection logs.
- We do not use shared accounts. There is no "admin" login that bypasses the audit log.
AI and your data
We use Anthropic's API (Claude Sonnet 4.6 as primary, Haiku 4.5 as fallback) for backlog parsing and assistive features. Anthropic does not train its models on data submitted via the API; this is contractual under their commercial terms of service and applies to every request Sorby sends.
Sorby itself does not train, fine-tune, or build any model on customer data. We do not aggregate customer content across workspaces for any machine-learning purpose. Embeddings used for in-workspace similarity search are scoped to the workspace that produced them and are deleted when the source record is deleted.
Vulnerability disclosure
If you believe you have found a security issue in Sorby, use our contact form.
- Please include enough detail to reproduce the issue and a way to reach you.
- Please give us 90 days to investigate and remediate before public disclosure.
- We will not pursue legal action against good-faith research that respects user privacy, avoids service disruption, and does not exfiltrate data beyond what is needed to demonstrate the issue.
- We do not currently run a paid bounty program. We acknowledge reporters publicly with their permission.
Incident response
If we detect a security incident — confirmed or suspected unauthorised access, data exposure, malicious code, or a sub-processor breach affecting Sorby — we follow this sequence:
- Contain within hours: rotate compromised credentials, revoke sessions, isolate affected systems.
- Assess scope: which workspaces, records, sub-processors are involved.
- Notifyaffected customers without undue delay, and in any event within 72 hours of becoming aware where the incident qualifies as a personal-data breach under GDPR Article 33. Notification goes to every workspace admin's registered email.
- Remediate the root cause and any defence-in-depth gaps the incident exposed.
- Post-mortem published to the affected customer within 30 days.
Backups, retention, and deletion
- Backups. Supabase performs daily automated backups with 7-day retention on the Free tier and Point-in-Time Recovery on the Pro tier. We will be on the Pro tier before any paid customer goes live. Backups are encrypted at rest and stored in the same EU region as primary data.
- While you are a customer. Workspace data is retained for the life of your subscription plus a 30-day grace window after cancellation, during which an admin can re-activate the workspace or export everything via CSV.
- After termination. After the 30-day grace window we delete the workspace and all of its content from primary storage within 7 days. Encrypted backups containing the data age out and are overwritten within 30 days. After 60 days from termination, no copy of your workspace data exists in any system we control.
- Account-level data.When a user deletes their individual account, identity records are deleted from Clerk; any workspace-level audit-log references to that user are retained as required for the integrity of the workspace's history but are anonymised on request from the workspace owner.
Compliance posture
We are honest about where we are. If your procurement process needs SOC 2 today, we are not the right vendor today. Tell us and we will follow up when we have it.
| Item | Status |
|---|---|
| GDPR | We honour data-subject rights and offer a DPA. See /legal/dpa. |
| SOC 2 Type 1 | Not yet. Targeted Q2 2027. |
| SOC 2 Type 2 | Targeted Q4 2027. |
| ISO 27001 | Not in scope before SOC 2 Type 2. |
| HIPAA | Not in scope. Sorby is not a HIPAA-covered tool; do not enter PHI. |
| PCI DSS | Not applicable. We do not process cardholder data; billing will run through a PCI-compliant processor (Stripe) when billing goes live. |
| EU data residency | EU-default for primary storage today; cross-border transfers covered by Standard Contractual Clauses. |
| SSO (SAML 2.0) | On the roadmap; required before SOC 2 readiness. |
International data transfers
Some sub-processors (Clerk, Anthropic, Upstash, Vercel) are based in or operate from the United States. Where personal data of EU/EEA or UK residents is transferred outside the EEA or UK, the transfer is covered by the European Commission's Standard Contractual Clauses (2021/914) and, for UK transfers, the UK International Data Transfer Addendum. The relevant clauses are included by reference in our DPA — see /legal/dpa.
Lawful basis for our own processing
When you use Sorby through your employer's workspace, your employer is the data controller and Sorby is the processor — the lawful basis for processing data inside the workspace is set by your employer, not by us.
For Sorby's own processing of account-level data — sign-up, billing, authentication, security logging — our lawful basis under GDPR Article 6 is performance of a contract (Art 6(1)(b)) for everything required to provide the service, and legitimate interest (Art 6(1)(f)) for security telemetry, abuse prevention, and rate-limit enforcement, balanced against your reasonable expectation that a SaaS product protects itself and its users.
Your rights and how to exercise them
If you are a data subject under GDPR or the UK GDPR, you have the right to: access the personal data we hold about you, correct inaccurate data, request deletion ("right to erasure"), request a portable export, restrict or object to processing, withdraw consent where consent is the lawful basis, and lodge a complaint with your supervisory authority.
To exercise any of these, use our contact form. We respond within 30 days. If you are using Sorby through your employer's workspace, we will route the request to your employer (the data controller) and assist them in fulfilling it.
Your legal team has questions
We respond within 2 business days to security questionnaires, DPA requests, and vendor assessments.