Risk register (draft)

Sign-off: approved by [Kyle] on [date], second reader [Dan] on [date]; recorded in approvals.md. Review quarterly.

A first register for ORG-17, 27 Oct 2026, from what the readiness review found. Owners: Kyle and Dan. Kept here, with each review logged in the control calendar (moved into the compliance platform, if one is chosen); review quarterly, reassess yearly.

Fraud and insider risks (CC3.3) are R13 and R14. The register is reviewed at each quarterly security review, and again when a client, a subprocessor, an add-on or a source system is added (CC3.4; for a source system, source-system-integrations.md).

Likelihood and impact on a 1 to 3 scale; score is the product. The response is what we are doing about it; the items are on the readiness page.

#	Risk	L	I	Score	Response	Items	Owner
R1	One customer sees another customer's records: there is no tenant separation in the data	2	3	6	Separate project per client until tenant_id is built	DB-3, VE-1, ORG-33	Dan
R2	Accounts held personally: a departure or lockout takes SCOPE with it	3	3	9	Step 0 moves, two owners, vault	OW-1 to OW-8	Kyle
R3	A leaked key or password gives database access	2	3	6	Rotate after the moves, secret scanning, the demo password out of the bundle	SC-1, SC-3, OW-8	Dan
R4	A driver's token reads investigation findings through the API	3	2	6	Move the investigation columns to an incident_finding table with its own RLS; waits on Paul's switch, a backward-compatible change, or Novvia's clone	DB-2	Dan
R5	Data lost and not restorable in time	2	3	6	Daily backups (RPO up to 24 hours today), the PITR decision, timed restore test	AV-1, AV-2	Dan
R6	A bad change reaches production unreviewed, or a reset wipes data	3	2	6	Branch protection, migrations by CI, separate demo database	SC-5, SC-6, VE-1	Dan
R7	A shared tablet lets driver B act as driver A	2	2	4	Shift-end session expiry, PIN sign-in with rate limits	ID-3, ID-4	Dan
R8	An attack or misuse goes unnoticed: logs kept days, no alerts	3	2	6	Log drains to 12 months, security alerts	LM-1, LM-2	Dan
R9	A personal laptop is lost or compromised	2	2	4	BYOD policy, quarterly device check (endpoint verification or a dated screenshot), MFA	ORG-15, ORG-16	Kyle
R10	A vendor (Supabase, Vercel) is breached or has a long outage	1	3	3	Vendor report review, BC/DR plan, offline capture	VN-1, AV-3	Kyle
R11	A vulnerable dependency is exploited	2	2	4	Dependabot, 7-day patch rule, pen test	SC-7, LM-4	Dan
R12	Key-person risk: two people run everything	3	2	6	Written runbooks (these drafts), two owners, documented on-call	OW-6, NP-6	Kyle
R13	Fraud: a supervisor signs off their own corrective action, or a record is back-dated to look compliant	2	2	4	Two-step sign-off with a named verifier other than the assignee, append-only trails, audit columns on the real clock; raw-token checks prove the RPC rules hold at the table	TS-5, DB-4	Dan
R14	Fraud or insider misuse: one of us reads or exports a client's Confidential data without a reason	2	3	6	Least privilege, quarterly access review, no client data in demo or development, standing access logged (ID-6)	TS-5, ID-6, ORG-20	Kyle
R15	Free tools chosen over paid ones (Free first, 28 Oct) leave a control without continuous evidence	2	2	4	The control calendar and evidence log; the compliance platform before the Type II window	TS-4, ORG-04	Dan
R16	No segregation of duties: one developer writes, merges, migrates and deploys, so a mistaken or deliberate change can reach main with nobody else having seen it	2	2	4	Accepted while there is one developer, with compensating controls (the change-management policy, Segregation of duties): no direct push to main, five required checks, the security owner's monthly review of every merged PR and of the dashboard log against the baseline, a second person for every client production release. One approval required once a second developer joins	TS-11, ORG-07, TS-9, TS-13	Kyle

Accepted risks, if any, are recorded here with who accepted them and when.

#	Accepted by	On	Until
R16	[Kyle], with Dan	[date]	A second developer joins