Subprocessors and vendor reports
Sign-off: approved by [Kyle] on [date], second reader [Dan] on [date]; recorded in approvals.md. Review yearly.
Who handles customer data on our behalf (VN-3), where (VN-4), and the evidence we collect from each every year (VN-1, VN-2, ORG-18). Drafted 27 Oct 2026 from the code. This list goes into the DPA (VN-5) and onto the trust page (NP-7). A customer is told before a new subprocessor is added; the notice period is set by counsel in the DPA.
Subprocessors
| Subprocessor | Service | Customer data it handles | Location | Status |
|---|---|---|---|---|
| Supabase, Inc. (runs on Amazon Web Services) | Database, sign-in, file storage | All of it: people, incidents, inspections, training, documents and photos | East US, us-east-1 (read 28 Oct); must be a US region |
In use |
| Vercel, Inc. | Hosting, server functions, build | Passes through in requests; logs may hold names, addresses and identifiers | Function region iad1, Washington, D.C., US (read 28 Oct) |
In use |
| AWS (Amazon Bedrock) | Spotter's model in client builds | The VP's typed question; no database rows | Region set by SPOTTER_AWS_REGION; must be US |
Client builds where Spotter is switched on |
| Anthropic, PBC | Spotter's model in OUR demo only | The typed question; demo data is synthetic | US | Demo only, never a client build |
Not subprocessors, but vendors in scope for vendor review: GitHub (code, CI; no customer data in the repository: the sample data is synthetic), Google Workspace (company email; customer data should not be emailed, see the incident plan), the compliance platform and the password vault once chosen.
AI tooling that touches CODE (Claude Code, used to write SCOPE) is disclosed to the auditor as a
development tool. It has no access to customer production data, and must keep none: production
credentials are never pasted into a chat (CLAUDE.md already says SUPABASE_DB_URL stays in
.env.local, never in chat).
Vendor reports to collect each year (VN-1, ORG-18)
| Vendor | Report | Where to get it | Who |
|---|---|---|---|
| Supabase | SOC 2 Type II (period 1 March to 28 February) | Dashboard, Organization > Legal Documents. Team and Enterprise plans only (Supabase's own SOC 2 guide, checked 28 Oct); Free and Pro cannot download it | Kyle (Dan may fetch it) |
| Vercel | SOC 2 Type II (Security, Confidentiality, Availability) | Team Settings > Compliance documents, or the trust center (security.vercel.com) > Reports > Get access. Pro and Enterprise; the Lucent Axis team is Pro | Kyle (Dan may fetch it) |
| GitHub | SOC 1 and SOC 2 Type II | Organization Settings > Compliance (org owners only). GitHub's docs describe it for Enterprise Cloud; whether a Team org sees it is unconfirmed: Kyle checks the page | Kyle |
| Google Workspace | SOC 2 Type II | Admin console > Compliance reports manager | Kyle (the Workspace admin may fetch it) |
| AWS | SOC 2 Type II | AWS Artifact, in the Lucent Axis AWS account | Kyle (Dan may fetch it) |
| Anthropic | SOC 2 Type I and II | trust.anthropic.com, request form (demo use only; client builds use AWS Bedrock, covered by AWS Artifact) | Kyle (Dan may fetch it) |
Supabase's report is the one the free route cannot reach. The auditor relies on it for the carve-out (TS-8), and Pro does not include it. Options, cheapest first: ask Supabase's sales or support whether a Pro customer can receive it under NDA; or move the organisation to the Team plan for the month the report is needed each year, download it, and move back; or stay on Team if its other features (SSO for our team, longer log retention, the log drains for LM-1) are wanted anyway. Decide with the plan choice in OW-3.
Record for each: the report period, the auditor's opinion (unqualified or not), any exceptions,
and the date we reviewed it. The record is kept in docs/compliance/evidence/<year>/ and the
control calendar log (the compliance platform, if one is chosen). Kyle collects and reviews the
reports (VN-1, ORG-18); Dan may fetch them.
Controls the vendors expect us to run (VN-2, CUECs)
Each vendor's report lists "complementary user entity controls": things the vendor assumes its customer does. The list below is what we expect to find; replace it with the real wording from each report when it arrives.
| Vendor | Control they expect of us | Our control | Item |
|---|---|---|---|
| Supabase | Customers manage their own users' access and MFA | MFA and quarterly review of the Supabase org | ID-1 |
| Supabase | Customers configure row-level security on exposed tables | Every public table has RLS; scripts/db/verify_rls.sql fails on one without it, run nightly |
DB-1, SC-4 |
| Supabase | Customers protect and rotate their API keys and database password | Vault, rotation schedule | OW-8, DB-7 |
| Supabase | Customers enable backups / PITR appropriate to their needs | Daily backups today, PITR decided in AV-2, a timed restore test | AV-1, AV-2 |
| Vercel | Customers manage team membership and roles | MFA and quarterly review of the Vercel team | VE-4 |
| Vercel | Customers keep secrets in environment variables, not code | gitleaks in CI; secrets inventory | SC-3, VE-2 |
| Vercel | Customers protect preview deployments | Vercel Authentication on every deployment except custom domains (the Lucent Axis team's default, read 28 Oct) | VE-3 |
| GitHub | Customers enforce 2FA and manage org access | Required 2FA, quarterly review | ORG-06, ORG-20 |
| Customers manage users, 2-Step Verification, offboarding | Onboarding and offboarding checklists | ORG-19 | |
| AWS | Customers manage IAM users, keys and region choice | Bedrock in a Lucent Axis account, least-privilege role, US region | VN-4 |