# 13 Access control policy

| | |
| --- | --- |
| Version | 0.1 draft |
| Owner | Infrastructure Owner |
| Review | Yearly |
| Applies to | Every in-scope system, and every workforce system that can reach one (source host, cloud console, DNS, registrar, email, password manager, compliance platform) |

## Principles

Unique identity, least privilege, MFA, approval before access, removal on departure, and a regular review that actually changes something.

## Workforce access

1. **Unique named accounts** for every person on every system. Shared accounts are forbidden. Service accounts are allowed only for machines, have a named owner, and cannot sign in interactively (ACC-02).
2. **MFA** is enforced (not merely available) on the workforce identity provider, GitHub, Cloudflare, the registrar, the cloud console, email, the password manager, and the production access path. Phishing-resistant methods (passkeys, hardware keys) are preferred for administrators. SMS is not accepted for administrators (ACC-03).
3. **Request and approval.** Access is requested in a ticket naming the system, the role, and the reason. The system owner approves. The approval is recorded before the grant (ACC-04).
4. **Least privilege.** Default roles are read-only or developer. Administrator, root, sudo, database superuser and cloud owner roles are held by named individuals listed in the privileged access list (ACC-07).
5. **Removal** within 1 business day of departure or role change, under [12](/soc2/12-people-security) (ACC-05).
6. **Quarterly review.** The Security Owner exports the account list of every in-scope system, each system owner confirms each account or removes it, and the signed review records the before list, the after list, and every change (ACC-06). A review that never removes anything over a year is itself examined.

## Production access

1. Production is administered only through [the chosen path: cloud session manager, or a bastion with SSH certificates or keys, behind MFA]. Password SSH is off. Root login is off. Database ports are never exposed to the internet (ACC-08).
2. Access to customer content in production (reading a mailbox, opening a file, querying a customer's rows) is allowed only for support, security or legal reasons, is logged, and where practical is done with the customer's knowledge.
3. Every privileged action is logged centrally and attributable to a person (OPS-01).
4. Break-glass credentials exist for when the identity provider is down. They are sealed in the password manager, their use pages the Security Owner, and they are rotated after every use.
5. Coding agents never hold production credentials of their own. See [17](/soc2/17-ai-agents).

## Customer authentication

Gate and every in-scope product follow the security defaults in the [compliance prompt](/PROMPT.md): argon2id or bcrypt, breached-password check, minimum length 8, no forced rotation, MFA available to every user and enforced for workspace administrators, rate-limited sign-in, OTP and reset, httpOnly Secure SameSite cookies, session revocation, server-side authorisation on every object, tenant scoping at the query layer (ACC-09, ACC-10).

## Keys and secrets

Under [15 Cryptography and key management](/soc2/15-cryptography).