Access Control Policy¶

Purpose. Defines who gets access to Soon's systems and data, how that access is granted, authenticated, reviewed and removed. It protects customer workforce data (Soon is a GDPR processor) and Soon's own systems against unauthorised access.

1. Scope¶

Applies to all Soon employees and contractors and to every system holding Soon or customer data: the production environment (AWS eu-west-1), source code and CI/CD (GitHub), and business SaaS (Google Workspace, Slack, Stripe, Intercom, Sentry, PostHog, Netlify and other approved services).

2. Policy¶

2.1 Principles¶

Least privilege, deny by default. Access is granted only when needed for the role, at the minimum level needed. Anything not explicitly granted is denied.
Role-based access. Access is assigned according to job role, not individually negotiated per person.
Unique, individual accounts. Every account maps to one named person. Shared and generic accounts are not permitted. Service/machine accounts must be documented, owned and restricted to their purpose.
Segregation. Where team size allows, the person approving access must not be the person granting it to themselves; administrators must not modify their own permissions.

2.2 Joiners, movers, leavers¶

Joiner. Access is provisioned at start date based on role. Access to production or Restricted data requires explicit approval by the system owner.
Mover. When someone changes role, access required by the old role but not the new one must be removed at the time of the change.
Leaver. All access must be revoked on the leaver's last working day (same-day offboarding). Where there is a perceived risk, access may be revoked earlier. Accounts are disabled, not deleted, and usernames are not reused, to preserve audit trails.

2.3 Privileged access¶

Privileged (admin) rights are granted only to people who need them for their role, on named individual accounts.
Privileged accounts must not be used for day-to-day work where the platform supports separate roles or elevation.
Privileged access is reviewed quarterly (see 2.4).

2.4 Access reviews¶

Quarterly: review of all privileged access (AWS admin roles, GitHub org owners, IdP admins, admin roles in business SaaS).
Annually: review of all user access across in-scope systems by the system owners, checking for leavers, excess rights and shared accounts.
Findings must be corrected promptly and the review recorded.

2.5 Authentication¶

MFA — risk-tiered (confirmed 2026-07-03). Soon does not apply MFA uniformly; it is tiered by sensitivity:

Sensitive/critical systems (e.g. AWS, GitHub): MFA is required.
Lower-value internal tools: access via Google login where offered, which inherits Google's own account protections in place of a separate MFA requirement.
Low-importance tools: password only, protected by the password requirements below; no MFA required.

SSO. Single Sign-On (SSO) is used wherever the system or service supports it and it is practical to do so. An exception applies to accounts that only provide access to non-sensitive information; such accounts may use a separate local login, provided the password complies with the table below. TODO(owner: Thomas): confirm the identity provider used for SSO (WorkOS) and maintain the list of systems that are not behind SSO.

Product (customer-facing) authentication — known gap. The Soon platform does not currently offer native MFA for customer accounts using email/password login. Mitigation today relies on offering social login (Google/Microsoft) and enterprise SSO as alternatives, not on MFA itself. Tracked as product risk R-22; native MFA is a planned product improvement.

Passwords. Where a password is used (with or without MFA), it must meet:

Parameter	Value
Minimum length	12 characters
Re-use	Must not be reused across accounts (work or personal)
Forced expiry	None (confirmed 2026-08-13). Passwords are changed on suspicion or evidence of compromise. Periodic rotation is deliberately not required — current NIST guidance is that it drives predictable, reused passwords.
Account lockout	After 10 consecutive failed attempts (confirmed 2026-08-13), reset by the identity provider's normal recovery flow. Where a system's lockout is not configurable, the compensating controls are MFA and monitoring.
Screening	Length is preferred over complexity rules. Enpass is the company password manager, so every credential should be long, unique and generated. Where the provider offers breached-password screening (e.g. Google Workspace), it must be enabled.

Passphrases and the use of a password manager are encouraged. Exceptions to these rules must be approved and documented by the policy owner.

2.6 Production access (AWS)¶

Access to the production environment (AWS eu-west-1) is granted through AWS IAM roles mapped to job function, not through shared root or long-lived personal credentials. The root account is not used for day-to-day work.
Where role-based access is not granular enough (for example to segregate a dedicated customer tenant or Restricted data), attribute/tag-based access control (ABAC) in AWS is used to further restrict access. The asset owner decides when this finer-grained control is required.
Production access is included in the quarterly privileged access review.

2.7 Access control in systems and services¶

When adopting or building a system, it must support: individual user accounts, role- or group-based permissions, MFA and/or SSO (see 2.5), and audit logging of authentication and permission changes. Source code is protected in private GitHub repositories with access per this policy.

3. Roles & responsibilities¶

System owners — approve access to their systems, run the annual access review, decide where ABAC-style restrictions are required.
Managers — request access changes for joiners/movers and trigger same-day offboarding for leavers.
Engineering lead (Thomas Picauly) — administers AWS IAM and GitHub access; runs the quarterly privileged access review.
Policy owner (Olaf Jacobson, ISM) — maintains this policy and approves exceptions.

Change log¶

Version	Date	Author	Comments
0.1	2023-12-11	Olaf Jacobson	First draft document
0.2	2026-07-02	Andrea Cardinali	§3.8 aligned with practice: SSO where supported (exception for non-sensitive accounts), MFA in use, minimum password length 12
0.3	2026-07-03	Olaf Jacobson	Clarified actual MFA posture is risk-tiered (required for AWS/GitHub, Google login for lower-value tools, password-only for unimportant tools); separated internal MFA from the customer-facing product's lack of native MFA (risk R-22)
0.4	2026-07-18	Andrea Cardinali	Rewritten lean and Soon-specific (ISMS overhaul); absorbs Dynamic Access Control Policy (ISMS-DOC-A08-3-1); preserves the 0.3 risk-tiered MFA posture and R-22 product gap