RM Compliance
llms.txt
SOC 2/Policies13

Access control policy

Version0.1 draft
OwnerInfrastructure Owner
ReviewYearly
Applies toEvery in-scope system, and every workforce system that can reach one (source host, cloud console, DNS, registrar, email, password manager, compliance platform)
Markdown

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 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.

Customer authentication#

Gate and every in-scope product follow the security defaults in the compliance prompt: 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.