SOC 2: the work outside the code
Drafts and owners for every item on the readiness page that is not code: the to-do list (ORG-01 to ORG-36) and every gap whose status is Org task. Started 27 Oct 2026.
Every item below has either a draft in this folder or a named owner and a next step. The drafts are our own policies, written under Free first and adopted once Kyle approves them. If a compliance platform is chosen under ORG-04, they are carried into its templates; until then they stand on their own.
Nothing here has been changed on GitHub, Vercel, Supabase or Google by these drafts (Kyle's own Step 0 work is recorded below). Each dashboard step is marked with who can do it.
The audit boundary (Dan, 28 Oct): everything in a Lucent Axis account, and nothing else. Dan's personal GitHub repo, Vercel projects and Supabase project are Paul's demo on synthetic data and are not tested against the requirements.
The personal demo is frozen (Dan, 27 Oct). Paul is demoing to clients on the personal
Vercel project, Supabase project and repo. Until Lucent Axis has its own Vercel and Supabase
running, nothing that demo depends on changes: Step 0 builds a COPY under Lucent Axis, Paul
switches to it when it is proven, and only then is the personal setup paused. Branch protection
applies to lucent-axis/scope only (Dan, 28 Oct): the company repo follows the rules now, the personal repo does not change. Ticks are made on the readiness page, with a name and a date.
The drafts
| Draft | Covers |
|---|---|
| Approvals, signatures and what waits on Kyle | Every document to approve, the signature record (ORG-14), the owner-only clicks, decisions and questions to send, in one sitting |
| This week: Step 0, MFA, scanning, branch protection | ORG-01, ORG-02, ORG-03, ORG-06, ORG-07, OW-2 to OW-8, VE-4, ID-1, DB-7 |
| Criteria matrix | Every in-scope Trust Services Criterion against our controls; TS-1 to TS-16 |
| Control calendar and evidence log | TS-2, TS-4, and every recurring control |
| System description | ORG-10, TS-8 |
| Information security policy | ORG-09, TS-1, TS-7 |
| Change management policy | SC-5, SC-6, ORG-07, TS-9 |
| Security-settings baseline | TS-13 |
| Data classification, retention and disposal | DB-5, DB-6, TS-6 |
| Security awareness training | ORG-14 |
| System inventory | OW-5, OW-7, ORG-10 (the first half), ORG-32 |
| Subprocessors and vendor reports | VN-1 to VN-4, ORG-18 |
| Policy set | ORG-09, ORG-14 |
| BYOD and laptops | ORG-15, ORG-16 |
| Incident response plan | LM-3, ORG-25 |
| Business continuity and disaster recovery | AV-1 to AV-3, ORG-23, ORG-24, NP-6 |
| Joining, leaving and access reviews | ORG-13, ORG-19, ORG-20 |
| Risk register | ORG-17 |
| Connecting a source system | VE-2, TS-12, VN-3, LM-2, ORG-10 for each new integration |
| Platform, auditor, pen test, counsel | ORG-04, ORG-05, ORG-08, ORG-12, ORG-27 to ORG-31, ORG-36, LM-4, VN-5, NP-7 |
Found while drafting (27 Oct)
Read from GitHub and Vercel without changing anything:
- Kyle is the only owner of the
lucent-axisGitHub org. Dan is a member with admin on both repos. So the org-wide settings (require two-factor, org-wide secret scanning, owner recovery codes) are Kyle's to change, and OW-6 needs a second owner. - The org is on GitHub Team. Secret scanning and push protection on a PRIVATE repo are not included in Team: they need the paid GitHub Secret Protection add-on, priced per active committer. That makes ORG-03 a spending decision. Check the current price on the org's billing page before deciding.
lucent-axis/scopeandlucent-axis/novvia: private, every security feature off, main not protected.- Both SCOPE Vercel projects (
scope-safety-poc,scope-novvia) are on Dan's personal Vercel account, alongside unrelated personal projects. OW-2 is new projects in a Lucent Axis team, not a transfer: the personal ones keep running for Paul. The plan is not visible from the command line. If it is Hobby, it does not allow commercial use, which is one more reason to move first. - No custom domain: both apps are served on
*.vercel.app, so OW-4 has nothing to move today. A company domain is a decision (see this-week.md). - Supabase could not be read: the command line has no Supabase login. Plan, region, PITR and members need Dan in the dashboard (ORG-32).
Free first (Dan, 28 Oct)
The rule: whenever it is possible and defensible, a control uses a free tool or one we already have. Where the free route is likely to fail an audit or a customer's security review, the table says so and names the industry-standard tool to put in instead. SOC 2 names outcomes, not products: Kyle's roadmap named paid tools because they are the usual way to meet a criterion, not because the criterion asks for them. Prices and free-tier limits change; check them on the vendor's page the day a choice is made.
| Item | Free or already owned | Defensible? | If not, put in instead |
|---|---|---|---|
| ORG-03, SC-3 secret scanning | gitleaks over the whole history in CI on every push (running), and gitleaks before every commit on each laptop (built on the pre-commit branch, same version as CI). Decided, Dan 28 Oct | Yes, written into the change-management policy as the control. Weakness: the laptop hook can be skipped, so CI catches a leak after the push, not before | GitHub Secret Protection (server-side push protection, live-key checks) once more people commit, or if the chosen platform bundles it |
| SC-7 code scanning | Semgrep Community Edition as a CI job (open source rules), alongside ESLint. CodeQL on a private repo needs the paid GitHub Code Security | Yes | GitHub Code Security (CodeQL) or Semgrep's paid tier if the auditor asks for findings tracked in one place |
| ORG-26 dependency scanning | Dependabot alerts (free on Team) and npm audit in CI, critical fixes in 7 days |
Yes | Nothing needed |
| OW-6, DB-7 the vault | Bitwarden's free organization (two users: enough for the two owners' recovery codes and the database password). Dan can create it now and invite Kyle when he is back | Yes while only the owners need it | Bitwarden Teams or 1Password Business once a third person needs shared secrets |
| ORG-04 compliance platform | Run it ourselves: policies drafted here, evidence in dated folders, the hub's ticks, and a CPA firm hired directly | Type I: yes, small firms do it. Type II: likely to fail in practice: 6 to 12 months of monthly and quarterly evidence collected by hand, and a missed month is an exception in the report | Vanta, Drata, Secureframe or Sprinto, signed before the Type II window opens (ORG-30). Sprinto and Secureframe are usually the cheapest for a team this size |
| ORG-15 device checks | Google Workspace endpoint verification, if our Workspace edition reports disk encryption, screen lock and OS version; else a dated screenshot per laptop each quarter | Type I: yes for a handful of laptops. Type II: weak, the checks must be continuous | The platform's own agent (comes with ORG-04), or an MDM: Kandji, Jamf or Intune |
| ORG-14 security training | A short annual session from free material (CISA's, or our own deck) plus a signed policy acknowledgement kept per person | Yes | The platform's built-in training |
| ORG-13 background checks | None is free | Most auditors expect them for anyone with production access | A pay-per-check service (Checkr, Certn, or the platform's partner); tens of dollars a person |
| LM-4, ORG-27 pen test | An OWASP ZAP scan of the app in CI, plus the RLS proofs we already run (verify_raw_writes.sql and the other verify_*.sql scripts) |
For the SOC 2 audit itself, usually yes: it asks for vulnerability testing, not a named firm. For an enterprise customer such as Novvia, likely no: their security review asks for a third-party letter | A third-party pen test before the first enterprise go-live; most platforms resell one |
| LM-1, ORG-21 logs kept 12 months | The audit trail already in Postgres (audit columns, incident_event, the request and training trails) kept with the backups; platform logs exported nightly by a GitHub Actions job to our own storage |
Database trail: yes. Platform logs on free log-tool tiers: no, they keep days, not a year | Supabase log drains (a higher plan) or a paid log store (Axiom, Better Stack, Datadog) |
| AV-4, ORG-22 uptime and status page | UptimeRobot or Better Stack free tier, both include a status page | Yes | Nothing needed |
| SAML SSO for our own team | MFA enforced on every account plus the quarterly access review | Yes: SOC 2 asks for strong sign-in, not SSO | Vercel and Supabase SSO when the team grows |
| VN-1 Supabase's own SOC 2 report | None on Pro: Supabase gives it on Team and Enterprise only | No: the auditor relies on it for the carve-out | Ask Supabase for it under NDA first; else a month on Team each year to download it, or Team throughout (subprocessors.md) |
| Production database | None: Supabase's free plan pauses idle projects and has no point-in-time recovery | No | Supabase Pro at least (in place since 27 Oct); PITR is off, so RPO is up to 24 hours today until AV-2 decides |
Found on 28 Oct
- Kyle started Step 0 on 27 Oct. A Lucent Axis Vercel team (
lucent-axis, Pro trial, MFA enforced) holds a projectscope-webbuilt fromlucent-axis/scope, with Supabase connected through Vercel's integration. Its production builds fail until it gets Production env vars. Outcome of each this-week item, and Dan's remaining clicks: this-week.md.
In order
1. This week: dashboards, no vendor needed, none of them touching the personal demo
| ID | Step | Who | Next step |
|---|---|---|---|
| ORG-06 | MFA on GitHub, Vercel, Supabase, Google | Kyle (GitHub org, Supabase org switch), Workspace admin (Google); Vercel done 27 Oct | this-week.md |
| ORG-03 | Secret scanning and push protection | Dan | Done (Dan, 28 Oct): gitleaks in CI (the required secrets check) and in the pre-commit hooks on every laptop. GitHub Secret Protection is the upgrade, see Free first |
| OW-6 | Two owners on every account, recovery codes in a company vault | Kyle | Make a second GitHub owner; pick the vault (this-week.md) |
| OW-2 | A Lucent Axis Vercel team, and a NEW demo project in it built from lucent-axis/scope |
Kyle | Done: created by Kyle 27 Oct (team lucent-axis, project scope-web). The personal scope-safety-poc is not touched |
| OW-3 | A Lucent Axis Supabase org, and a NEW project with the demo's data copied in | Kyle, then Dan | Done: connected to scope-web by Kyle's Supabase integration 27 Oct; Dan brought the database current 28 Oct. The personal project is only read |
| OW-4 | Domain and DNS | Kyle or Business lead | Nothing to move today; decide whether SCOPE gets a company domain |
| OW-5, OW-7 | Inventory every service and account | Dan | Drafted: system-inventory.md. Dan fills the blanks only the dashboards show |
| OW-8, ORG-02 | Fresh keys and secrets in the new projects | Dan | They come with the new projects; the personal demo's keys stay as they are until it is paused. List in this-week.md |
| ORG-01 | Step 0 as a whole | Kyle | Done when OW-1 to OW-8 are ticked |
| VE-4 | Vercel team MFA, roles, quarterly review | Dan | After OW-2; the review is in onboarding-offboarding.md |
| ID-1 | Supabase org MFA, roles, quarterly review | Kyle (Owner switch) | Both members have MFA on (read 28 Oct); requiring it for the organization is the Owner's switch. Same review |
| DB-7 | SSL enforced, network restrictions, database password in the vault | Kyle (or Dan once Owner) | The switches need the Owner or an Administrator, and the vault; this-week.md |
| ORG-26 | Dependabot with a 7-day patch rule | Dan | Alerts are free on Team: switch on in repo settings. The dependabot.yml file is code (SC-7) and goes in its own change |
| ORG-07 | Protect lucent-axis/scope main: pull request required, checks must pass, no approval needed (Dan, 28 Oct), monthly after-the-fact review by Kyle |
Dan (repo admin) | Ruleset steps in this-week.md; applies to lucent-axis/scope only, the personal repo and Paul's demo untouched (Dan, 28 Oct) |
After Paul switches to the company copy
| ID | Step | Who | Next step |
|---|---|---|---|
| OW-1 | Personal repo archived (lucent-axis/scope has been origin since 28 Oct) |
Dan | After the switch |
| OW-2, OW-3 | Pause the personal Vercel and Supabase projects | Dan | After the switch; this also retires their keys |
2. Needs a decision or a vendor
| ID | Decision | Who decides | Next step |
|---|---|---|---|
| ORG-04 | Compliance platform, and its partner auditor | Kyle and Dan | Send the quote request in vendors-and-counsel.md to three platforms |
| ORG-05 | Connect GitHub, Supabase, Vercel, Google to the platform | Dan | After ORG-04 AND Step 0: connect the company accounts, never the personal ones |
| ORG-12 | Synthetic-data period counts toward the window | Kyle | Ask the auditor in writing once chosen; wording in vendors-and-counsel.md |
| ORG-36, VN-5, ORG-08 | Counsel for the DPA and contractor clauses | Kyle or Business lead | Brief for counsel drafted in vendors-and-counsel.md |
| ORG-31 | Cyber insurance | Business lead | One question to the broker, in vendors-and-counsel.md |
| ORG-32 | Supabase and Vercel plans, regions, PITR, log retention, SAML | Dan | Read the dashboards; blanks are marked in system-inventory.md |
| ORG-33 | Novvia on the shared project or its own | Dan | Decided (Dan, 28 Oct): own projects, cloned from lucent-axis/scope; does not wait for tenant_id (DB-3) |
| ORG-34 | Novvia accepts Type I plus a bridge letter | Kyle | Ask Novvia |
| ORG-35 | COFI in the boundary at Type II | Dan and Kyle | Default in the system inventory: out, until a COFI client asks |
| VN-4 | Data region confirmed in the US | Dan | Read Supabase project settings and Vercel function region |
| LM-1, ORG-21 | Logs kept 12 months | Dan | Both accounts are on Pro and drains are available on both (a paid add-on on Supabase, per GB on Vercel), so this is a spending decision |
| LM-4, ORG-27 | Vulnerability testing | Kyle | Decided 28 Oct: an OWASP ZAP scan plus the RLS proofs for the Type I; a third-party pen test before the first enterprise client goes live. Scope in vendors-and-counsel.md |
| ORG-11 | Client-one production and staging, separate from demo | Dan | After OW-3, so the new projects are born in the company org |
3. Month 2 and 3: drafted here, adopted in the platform
| ID | Item | Owner | Next step |
|---|---|---|---|
| ORG-09 | Policy set | Kyle | policies.md: the list, and which are drafted |
| ORG-10 | System description | Kyle, with Dan | Starts from system-inventory.md |
| ORG-13 | Background checks | Kyle | A pay-per-check service (Checkr or Certn); the platform's partner as the alternative |
| ORG-14 | Security training and policy acceptance | Everyone | Our own training, security-training.md, signed with the policies; the platform's course as the alternative |
| ORG-15, ORG-16 | Quarterly device check and BYOD policy | Everyone, Kyle | byod-policy.md |
| ORG-17 | Risk register | Kyle, Dan | risk-register.md: sixteen risks |
| ORG-18, VN-1, VN-2 | Vendor reports and CUECs | Kyle | subprocessors.md |
| VN-3 | Subprocessor list | Kyle | subprocessors.md |
| ORG-19 | Joining and leaving | Kyle | onboarding-offboarding.md |
| ORG-20 | First quarterly access review | Kyle, Dan | Template in onboarding-offboarding.md |
| ORG-22 | Uptime monitor and status page | Dan | Code (AV-4); the vendor is a choice to make with it |
| ORG-23, AV-1, AV-2 | Restore test, PITR | Dan | Record template in bc-dr-plan.md |
| ORG-24, AV-3 | BC/DR plan and tabletop | Kyle, Dan | bc-dr-plan.md |
| ORG-25, LM-3 | Incident response plan and tabletop | Kyle | incident-response-plan.md |
4. Month 4 and Type II
| ID | Item | Owner | Next step |
|---|---|---|---|
| ORG-28 | Readiness check in the platform | Kyle | After everything above |
| ORG-29 | Type I fieldwork | Kyle | Book with the auditor when ORG-04 is signed |
| ORG-30 | Type II window starts the day after the Type I date | Kyle | Put the date in the calendar once the Type I date is known |
| NP-6 | Uptime SLA, on-call rota, yearly DR drill | Kyle, Dan | The rota and drill are in bc-dr-plan.md; the SLA is a contract term for counsel |
| NP-7 | Trust page | Kyle | Once the Type II report and pen-test letter exist; most platforms host one |