Joining, leaving and access reviews (draft)
Sign-off: approved by [Kyle] on [date], second reader [Dan] on [date]; recorded in approvals.md. Review yearly.
Draft for ORG-19, ORG-13 and ORG-20, 27 Oct 2026. Owner: Kyle. Covers Lucent Axis staff and contractors with access to SCOPE's systems. Customer users (drivers, supervisors) are managed in the app, not here (ID-5).
Each checklist is copied per person into docs/compliance/evidence/<year>/, ticked, kept, and
logged in the control calendar (or in the compliance platform, if one is chosen): the ticked copy
is the evidence.
Joining
Before any access:
- Signed contract with confidentiality and security clauses (ORG-08)
- Background check completed, if the person will have production access (ORG-13; a pay-per-check service, Checkr or Certn)
- Laptop checked against the BYOD policy: encryption, lock, updates, screenshot filed
Access, least privilege, each one recorded with the date:
- Google Workspace account, 2-Step Verification on
- GitHub: added to the
lucent-axisorg through a team, never as an outside collaborator on a single repo - Vercel team: Developer role unless the job needs more
- Supabase org: Developer or Read-only unless the job needs more; database password only if the job needs it
- Vault: only the folders the job needs
- Compliance platform account, if one is chosen
In the first week:
- Security awareness training completed (security-training.md, ORG-14)
- Every policy read and signed (approvals.md, ORG-14)
- Walked through the incident response plan: who to call
Leaving
All access removed within 24 hours of the last day, or at once if the departure is not friendly. Kyle runs it; Dan is the backup.
- Google Workspace suspended (mail forwarded to the manager if needed)
- Removed from the GitHub org; their personal access tokens and deploy keys for our repos revoked
- Removed from the Vercel team; their tokens revoked
- Removed from the Supabase org; if they ever held the database password or a secret key, rotate it (this-week.md)
- Removed from the vault; any shared item they could read rotated if it is a production secret
- Removed from the compliance platform (if one is chosen), the registrar, Anthropic and AWS, where present
- Any SCOPE app login linked to them through
scripts/db/link_user.shdisabled - Laptop's company data removed (the repository and any customer data), confirmed in writing
Quarterly access review (ORG-20, VE-4, ID-1)
Every quarter (January, April, July, October; due by the month's last working day, see the control calendar), Kyle and Dan together, 30 minutes.
For each account in the system inventory: export the member list, and for each member answer three questions.
| Account | Member | Still works here? | Role still needed? | MFA on? | Change made |
|---|---|---|---|---|---|
GitHub lucent-axis |
|||||
| Vercel team | |||||
| Supabase org | |||||
| Google Workspace | |||||
| Vault | |||||
| SCOPE app: Lucent Axis staff holding app logins on a client deployment |
Rule for business users: app-level admin only, never a database login or a dashboard seat.
Machine credentials (TS-12)
The same review covers what acts on SCOPE without being a person: secrets, keys, tokens and
installed apps. scripts/compliance/access_review.sh lists every one it can read, by name and
date only (GitHub repo, environment and Dependabot secrets, deploy keys, every Vercel project's
environment variables and the team's integrations, and the reviewer's own Vercel tokens). Org
secrets and installed GitHub Apps need an Owner, so Kyle runs the script, or Dan once he is an
Owner (OW-6); Supabase's keys and the database password's date are read in its dashboard. For
each credential:
| Credential | Owner | Scope (what it can reach) | Last rotated | Still needed? | Change made |
|---|---|---|---|---|---|
The rules the answers are checked against:
- An owner by name. A credential nobody owns is removed. An integration's own variables (Vercel's "Added by: integration") belong to whoever owns the integration.
- The narrowest scope. A deploy key is read-only unless a workflow needs to push; a GitHub
App holds the repositories it serves, not all of them; a server secret is never
NEXT_PUBLIC_. - Rotated yearly, and at once when anyone who could read it leaves (see Leaving), at each
account move, and after any suspected exposure. "Last rotated" is the date in the listing
unless a rotation is recorded in the change table of
change-management-policy.md. - Expires. A personal token (Vercel, Supabase, GitHub) carries an expiry date; one that never expires is given one or replaced.
- Unused means removed. A secret no code or workflow reads is deleted, not kept "in case".
scope-web's Supabase integration variables in Preview and Development (SUPABASE_SERVICE_ROLE_KEY,SUPABASE_SECRET_KEY,SUPABASE_JWT_SECRET,POSTGRES_*) are the first case; they go with the DB-7 rotation. Save the exports and the filled table, dated and signed by both, indocs/compliance/evidence/<year>/with a line in the control calendar log (or in the compliance platform, if one is chosen).