Control calendar and evidence log

Every recurring control, when it runs, who runs it and what it leaves behind. Without a compliance platform this is how the controls show they operated; with one, it becomes the platform's task list. Draft 28 Oct 2026. Owner: Dan. SOC 2 CC1.2, CC4.1, CC4.2, CC5.3; items TS-2, TS-4.

The rule for evidence: each run leaves a dated file under docs/compliance/evidence/<year>/ (or in the platform once chosen), named <date>-<control>.md, and a line in the log at the foot of this page. An auditor samples the dates; a missing one is an exception in the report.

When each control is due. A control is on time if it is done by its due date; the calendar date is a reminder that the window has opened, not the deadline. An auditor tests against what this page says, so it says a window rather than a day:

Cadence	Reminder	Due by
Monthly	First Monday of the month	The 10th working day of the month
Quarterly	Third Monday of January, April, July and October	The last working day of that month
Yearly	Second Monday of the month in its Month column	The last working day of that month

The three reminders fall on different Mondays so no single day carries a month's, a quarter's and a year's work at once. Working days are Monday to Friday.

A yearly control's month is the month it first runs. Each first run is a readiness task before the Type I (Month 2 is December 2026, Month 3 is January 2027, fieldwork is Month 4), so the first run counts as the first year's and the anniversary falls in the same month. If a first run lands in a different month, move the row to that month.

On a calendar. The hub draws this page with its schedule on top and a calendar link anyone may add to their own calendar; nothing is put on anyone's calendar for them. The dates come from this file; change a row here and the calendar follows on the next build.

Schedule starts: 2026-12-07. Until then the schedule is planned, not run: we are preparing for SOC 2, and the evidence log fills once the controls start. Move the date here when the start moves.

Monthly

Control	Who	Evidence	Items
Review every pull request merged into lucent-axis/scope last month (gh pr list --state merged --search "merged:YYYY-MM-01..YYYY-MM-31")	Security owner	The list, with a line per High-risk or emergency change; a change the security owner made is reviewed by the platform owner	CC8.1, CC5.1, ORG-07, TS-11
Dependabot and CI scan findings: open criticals older than 7 days, highs older than 30	App owner	Screenshot or export of the open alerts, and the fix or the risk-register entry	ORG-26, SC-7
Dashboard change log up to date	Platform owner	The table in the change-management policy	TS-9
Security settings against the baseline: python3 scripts/compliance/baseline_check.py --save, then the dashboard rows read by hand into the same file; every DRIFT either named to its readiness item or put back and logged	Platform owner	<date>-security-baseline.md	TS-13, CC7.1
Capacity: psql "$SUPABASE_DB_URL" -f scripts/compliance/capacity.sql per client project (disk, connections, cache, largest tables, long queries; WATCH at 70%), and Supabase > Reports for CPU; anything WATCH gets a plan	Platform owner	The script's output and a line	AV-5, A1.1
Security events: app logins flagged NEW or needing attention, and every access change of the last 35 days (psql "$SUPABASE_DB_URL" -f scripts/compliance/app_access.sql, per client database), and sign-in failures in Supabase > Logs > Auth	Platform owner	The script's output and a line on anything unexpected	LM-2, CC7.2

Quarterly

January, April, July and October: reminder on the third Monday, due by the month's last working day.

Control	Who	Evidence	Items
Access review of every account	Security and platform owners	scripts/compliance/access_review.sh output plus the filled review table, signed by both	ORG-20, VE-4, ID-1
Security review meeting: this calendar's misses, open risks, incidents, changes to the system	Security and platform owners	Minutes: who attended, what was decided, each miss and its fix	TS-2, CC4.2
Risk register reviewed	Security owner	The register's date and changes	ORG-17
Restore spot check: one table restored from backup into a throwaway project	Platform owner	The restore test record	ORG-23, AV-1
Device check against the BYOD policy: Google Workspace endpoint verification where the edition reports it, else a dated screenshot per laptop (disk encryption, screen lock, OS version)	Everyone, collected by the security owner	The report or the screenshots, per laptop	ORG-15

Yearly

Control	Month	Who	Evidence	Items
Security awareness training, then the policies reviewed and re-signed by everyone (one sitting)	December	Security owner, everyone	Completion record and signed acknowledgement per person	ORG-09, ORG-14
Risk assessment redone	December	Security owner	The new register	ORG-17
Vendor SOC 2 reports read; CUECs checked	December	Security owner	Notes per vendor	VN-1, ORG-18
Secrets and keys rotated: the database password, Supabase secret keys, Vercel and GitHub tokens, the vault's production items; the credential listing's "Last rotated" updated (onboarding-offboarding.md)	December	Platform owner	The credential listing with its new dates, and a line in the dashboard change log	VE-2, OW-8
Incident response tabletop (tabletop-exercises.md, exercise 1)	January	Both owners	Exercise record	ORG-25
Full timed restore test against RPO and RTO; DR tabletop (tabletop-exercises.md, exercise 2)	January	Platform owner, both owners for the tabletop	Restore test record, exercise record	ORG-23, ORG-24
Vulnerability scan or pen test	January	Security owner	Report and fixes	LM-4

On an event

Event	Control	Evidence
Someone joins or leaves	The joining or leaving checklist	The ticked checklist, dated
A security incident	The incident response plan	The incident record
A new client, subprocessor or add-on	Risk register and subprocessor list reviewed	The updated documents
A new source system connected	The source-system checklist, ticked in its pull request	The merged PR
An emergency merge	Comment on the PR within one working day	The PR

Evidence log

Date	Control	Who	Where	Notes
2026-10-27	MFA enforced on the Vercel team	Kyle	Vercel API, read 28 Oct	First Step 0 evidence
2026-10-28	Dependabot alerts switched on	Claude, approved by Dan	GitHub API (204)	0 open alerts at first read
2026-10-28	Main ruleset applied on lucent-axis/scope (id 26059181); first changes merged through it, PRs #2 and #3	Dan, the CI session	GitHub	A direct push refused with GH013 the same day
2026-10-28	Access review member lists, Lucent Axis accounts and database	Claude, for sign-off	evidence/2026/2026-10-28-access-review.md	GitHub: one owner (Kyle). Vercel: Kyle Owner, Dan Member, MFA enforced. Supabase: Kyle Owner, Dan Developer, both MFA on, not required. Company database: 8 persona logins and the hub's sales login, none unexplained. Awaiting the owners' review table
2026-10-28	Monthly review, October (first)	Claude, for sign-off	evidence/2026/2026-10-28-monthly-review-october.md	PRs #1 to #8, all through the required checks; 0 open Dependabot alerts. Awaiting Kyle's sign-off
2026-10-28	App logins on the personal demo database, outside the boundary (app_access.sql; a dry run of the control)	Claude	This line	9 logins; one with no person behind it, created 25 Sep, signed in once that day. It sees nothing (RLS keys on the person) but should be removed or linked. Not changed: the demo database is frozen while Paul demos on it. Owner: Dan, at the switch
2026-10-29	Security settings against the baseline (first run)	Claude, for Dan's review	evidence/2026/2026-10-29-security-baseline.md	19 settings read, 8 differ: 7 are open items (OW-6 twice, VE-2 twice, DB-7 twice, LM-1); one is new, GH-6: any member of the GitHub org can create a public repository. Kyle's switch