A periodic access-review procedure is documented in the repo

SOC 2 CC6.3 requires that access to systems and data is modified or removed based on roles, and that access grants are periodically reviewed: an auditor's first request in the logical-access section is "show me your access-review procedure and its last output." This is an evidence-pointer check: it verifies committed evidence of the control (a doc naming who holds production and admin access, how often the grant list is reviewed, and who runs the review), which is exactly the artifact an auditor will ask for. It does not, and cannot, verify that reviews actually happen off-repo. AI-generated and vibe-coded apps almost never carry this artifact: coding assistants scaffold roles, RBAC middleware, and admin routes on request, but "write down our quarterly access-review ritual" is an organizational habit, not a code prompt, so the repo ships with admin surfaces and zero paper trail. Teams then discover the gap during audit readiness, when reconstructing months of undocumented review history is impossible and the Type II observation window has to restart. Committing the procedure now (even a half-page in SECURITY.md) is the cheapest control in the whole SOC 2 readiness set.

Commit an access-review section to SECURITY.md (or a dedicated docs/security/access-review.md) that names three things: scope (which systems and roles are reviewed, e.g. production database, Vercel team members, Supabase dashboard, admin-role users), cadence (e.g. quarterly), and owner (the role or person who runs the review and revokes stale grants). Example skeleton:

## Access review
- Scope: production DB, hosting dashboard, admin-role app users, CI secrets
- Cadence: quarterly
- Owner: engineering lead; findings tracked as issues, stale grants revoked within 7 days

This is the committed evidence a SOC 2 auditor asks for under CC6.3; keeping it beside the code means it evolves with the roles it governs.