Doc owner: Security Officer
Rationale: Systems Access Control Procedure
Applies to
Design notes
Why a policy plus a procedure rather than a single expanded policy
ISO 27001:2022 has a single overarching access control requirement at A.5.15, supported by a cluster of more granular technical controls at A.5.16–A.5.18 (identity, authentication, access rights) and A.8.2–A.8.5, A.8.18 (privileged access, information access restriction, source code, secure authentication, privileged utilities).
The 2013 edition of the standard had grouped the technical controls under a single Annex A.9.4 heading, "System and application access control." That label is the source of the question whether Allied needs a separate "systems access control policy."
We chose to keep one policy (POL-DIG-002) covering intent, scope, roles, and high-level rules, and split the operational and technical detail into this procedure. Reasons:
- The policy answers "what must be true" (least privilege, MFA where feasible, periodic review). It changes rarely.
- The procedure answers "how Allied does it day to day" (Linear issues, quarterly reviews, 5-minute screen lock, 24-hour termination SLA). It changes more often as systems and practices evolve.
- A single document conflating both would either be too long for the policy's audience or too thin on operational detail for the procedure's audience.
- Auditors are comfortable with this structure; the related policy and procedure together demonstrate the A.5.15 + A.8.x controls.
Concurrent sessions: not applied
Drata's boilerplate includes a concurrent session limit. We removed it. The control's primary purpose — detecting shared credentials and limiting blast radius of a stolen session — is met by Allied's MFA requirement, idle timeouts, device security, and quarterly access reviews. Enforcing a hard concurrent-session cap across Allied's heterogeneous SaaS estate would not be practical without a session-aware IdP proxy, and the incremental benefit over the existing controls is small. The decision is recorded in the procedure itself so it is visible at audit, not buried only in rationale.
Defaults chosen
| Setting | Value | Why |
|---|---|---|
| Access review frequency | Quarterly | Standard for ISO 27001 SMEs; matches the cadence we already plan for related controls |
| Device screen lock | 5 minutes | Aligns with Cyber Essentials Plus expectations |
| In-app idle logout (general) | 30 minutes | Common practice; not so aggressive that it drives bad workarounds |
| In-app idle logout (admin) | 15 minutes | Tighter for higher-privilege surfaces |
| Termination SLA | 24 hours (or end of business day) | Defensible at audit, achievable in practice |
| Inactive account disablement | 90 days | Matches the Drata default and common SaaS hygiene baselines |
Each of these can be revisited as Allied grows or as audit findings emerge.
Things deferred (TBD in the procedure)
- Appendix A (high-risk user scenarios) is left as an example row. Most situations there will be handled case-by-case under incident response and people processes; we don't want to over-codify in advance.
- Appendix B (per-cloud-provider access requirements) needs a separate inventory exercise — list of providers, identity source, MFA enforcement, admin set, review cadence. Tracked as a TBD.
- Incident handling for compromised credentials is routed via POL-DIG-011 Incident Response Plan. The procedure assumes the plan covers credential compromise; if it doesn't, that's a gap to close in POL-DIG-011 rather than duplicating handling here.
ISO 27001:2022 mapping — and where A.8.4 lives
The access control policy and this procedure together cover A.5.15–A.5.18, A.8.2 (privileged access), A.8.3 (information access restriction), A.8.5 (secure authentication), and A.8.18 (privileged utilities).
A.8.4 (Access to source code) is intentionally not held here. It is scoped to POL-DIG-010 SDLC, where it sits alongside secure coding standards, code review, and dependency management. POL-DIG-010 is still a stub; the TBD on its policy statements explicitly calls out source code access as a control to draft.
Administrator rights model
The Access Control Policy describes the centralised admin model: the Security Officer holds administrator credentials for all Allied devices, and day-to-day work — including the Security Officer's own — is done under a regular user account. This replaces an earlier per-person admin list, which read as if a small set of individuals had distributed admin rights on their own devices.
Source
Drafting started from Drata's System Access Control Policy boilerplate, then adapted to:
- British English spelling
- Allied's plain-English style and active voice
- Allied's existing role names (Security Officer)
- Allied's actual tooling (Linear in place of "ticketing system")
- Cloud Service Customer perspective only — the Cloud Service Provider section in the boilerplate was removed because Allied is not a CSP
- Defaults in place of bracket placeholders, with TBDs marked where a decision still needs to be made
Related decisions
None recorded yet. Add DEC-* references here when decisions are taken on the open TBDs above.
Changelog
See Git history for this file and for the procedure.