User Access Management Process¶
Purpose. Defines how access to Soon's systems and data is granted, reviewed and revoked across the joiner / mover / leaver (JML) lifecycle (ISO/IEC 27001:2022 A.5.16 Identity management, A.5.17 Authentication information, A.5.18 Access rights, A.8.2 Privileged access, A.8.5 Secure authentication). Implements the Access Control Policy and addresses risk R-18 (leaver/contractor access not revoked) and R-04 (privileged access).
1. Principles¶
- Least privilege — access limited to what the role requires.
- Unique identity — every person has their own account; no shared accounts.
- SSO + MFA — use enterprise SSO (WorkOS) where possible; MFA enforced for production and critical systems.
- Authorisation — access is requested and approved before being granted.
2. Joiner — granting access¶
- Access request raised as part of onboarding (New Starter Checklist).
- Role-based access defined for the person's role (a baseline access profile per role).
TODO(owner): document baseline profiles per role. - Approval — the Technical Lead (or system owner) approves; privileged/production access requires explicit approval and MFA.
- Accounts provisioned with least privilege; initial authentication info delivered securely; MFA enrolled.
3. Mover — changing access¶
On role change, access is re-evaluated: new rights granted with approval, and rights no longer needed are removed (avoid privilege accumulation).
4. Leaver — revoking access¶
On termination/end of contract (triggered by the
Termination & Change Checklist):
- Disable/revoke access promptly — target same working day for production and
critical systems. TODO(owner): confirm SLA.
- Revoke SSO, MFA tokens, API keys/secrets the person held; rotate any shared secrets
they knew.
- Return/wipe assets; confirm completion.
5. Privileged access (A.8.2)¶
- Privileged/admin access to AWS, GCP, Azure, databases and the codebase is restricted to named individuals, granted only when required, MFA-protected, and logged.
- Privileged utility programs are restricted and recorded (ISMS-DOC-A08-18-1).
6. Access reviews¶
- Quarterly review of who has access to production and critical systems; confirm it is still appropriate; remove anything unneeded. (Monitoring metric M7.)
- Privileged access reviewed at least quarterly.
- Reviews are recorded as evidence.
TODO(owner): confirm review cadence/owner.
7. Authentication information (A.5.17)¶
- Strong authentication enforced; secrets stored in GCP Secret Manager / a secrets manager — never in code or chat (see Cryptographic Policy).
- Password/secret requirements per the Access Control Policy.
TODO(owner): confirm password policy specifics (length, MFA scope).
8. Roles¶
- Technical Lead (Thomas) — owns this process; approves and provisions access; runs access reviews.
- ISM (Olaf) — ensures JML is followed; reviews evidence.
- Managers / system owners — request and confirm access needs.
Related documents¶
- Access Control Policy (A.5.15)
- Dynamic Access Control Policy
- Termination & Change Checklist (A.6.5)
- Roles & Responsibilities
- Risk Assessment Report — R-04, R-18
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2026-06-25 | Andrea Cardinali / ISMS | First draft — JML lifecycle, privileged access, quarterly reviews, WorkOS SSO + MFA. Baseline profiles, SLAs and password specifics flagged TODO. |