Doc owner: Security Officer
Systems Access Control Procedure
This procedure sets out how Allied grants, modifies, reviews, and revokes access to its systems and applications. It operationalises POL-DIG-002 Access Control Policy and covers the technical controls under ISO 27001:2022 Annex A.8.2, A.8.3, A.8.5, and A.8.18. Source code access (A.8.4) is scoped to POL-DIG-010 SDLC.
Scope
Applies to all Allied systems, applications, and data — and to anyone who needs access: staff, contractors, vendors, service accounts, and any other identity acting on Allied systems.
Roles
| Role | Responsibility |
|---|---|
| Security Officer | Approves access requests, runs reviews, owns this procedure |
| System owners | Apply the controls to systems they own; provide evidence at review |
| Line managers | Raise joiner, mover, and leaver requests; confirm continued need at review |
| People function | Notifies the Security Officer of starters and leavers |
Granting and modifying access
Access is granted on the basis of role-based access control (RBAC) and the principle of least privilege. The level of access assigned to a user reflects the minimum needed to perform the duties of their role. Segregation of duties is considered when assigning rights.
All access changes — additions, modifications, removals, and changes to authentication factors — require formal documentation and authorisation.
The process is:
- The requester (or their manager) raises an issue in Linear describing the access needed and the business reason.
- For new accounts, the requester's identity is verified before access is granted. In person where possible; over a known channel (e.g. a video call on a previously verified account) for remote staff. The verification method is recorded on the issue.
- The Security Officer grants or rejects the request based on the user's role.
- If the request is for access beyond the minimum needed for the role, the requester must justify it on the issue.
- Rejected requests are returned for further information.
- Approved requests are completed and the issue is closed with notes.
Access reviews
The Security Officer reviews user access quarterly to confirm that accounts, roles, and permissions remain appropriate. The review covers:
- Allied staff and contractor accounts
- Third-party and vendor accounts
- Service and application accounts
- Privileged access (admin and equivalent)
Reviews are evidenced in Linear. Any access no longer required is revoked as part of the review.
Identification and authentication
Every user has a unique login ID. Shared, group, or generic accounts are not used unless strictly necessary — and where they are, they require a documented business justification, management approval, and a control that ties every action to an individual user.
Users authenticate using at least one of:
- Something they know (password or passphrase)
- Something they have (security token, smart card, hardware key)
- Something they are (biometric)
Password requirements and single sign-on (SSO) are set in POL-DIG-004 Password Policy. Passwords are never displayed, transmitted, or stored in plain text.
Default accounts on production systems (including root) are deleted, disabled, or restricted to a small number of named administrators. They are only used under exceptional circumstances with documented business justification and management approval.
Automated log-on configurations that store passwords or bypass entry are not permitted, with the exception of Allied's approved password manager.
User identifiers include status where useful (e.g. contractor) to support attribution.
Multi-factor authentication
MFA is required for user authentication wherever technically feasible, and always for:
- Remote access to Allied systems
- Privileged and administrative accounts
- Third-party and vendor accounts
Where MFA is in use, the system must:
- Use at least two different factor types
- Resist replay attacks
- Not allow bypass by any user (including administrators) except by documented, time-limited, management-approved exception
Idle session and device lock
| Control | Setting |
|---|---|
| Device screen lock | 5 minutes of inactivity |
| In-app idle logout (general) | 30 minutes |
| In-app idle logout (admin consoles and other privileged tools) | 15 minutes |
Settings apply to Allied-issued devices and to any personal or third-party device used to access Allied data.
Concurrent sessions
Allied does not apply a hard limit on concurrent sessions. The security objective is met by the combination of MFA, idle timeouts, device security under POL-DIG-002, and the access review cadence above. Real users legitimately work across multiple devices; enforcing a concurrent-session cap across Allied's SaaS estate is not practical and offers little incremental benefit.
This decision is documented here so it is visible at audit.
Third-party and vendor access
Vendor and third-party accounts used to support or maintain Allied systems are:
- Enabled only for the period needed, based on a documented authorisation
- Disabled when not in use
- Monitored during use for unexpected activity
Application and service accounts
Application, service, and machine accounts are provisioned on the same authorisation basis as human accounts and are limited to the access needed for the system to operate.
If a service account can be used interactively:
- Interactive use is prevented unless required for an exceptional circumstance
- Interactive use is limited to the time needed for that circumstance
- The business justification is documented and explicitly approved by management
- Individual user identity is confirmed before access is granted, so every action is attributable
Cloud service access
Allied operates primarily as a customer of cloud services. For each cloud service used, access requirements are recorded in Appendix B and follow this procedure: least privilege, MFA, named accounts, and inclusion in the quarterly access review.
Where a cloud provider exposes administrative consoles, those consoles are treated as privileged systems under POL-DIG-002.
Privileged utilities
Access to utility programs that can bypass normal system or application controls — anti-virus consoles, diagnostic tools, patching tools, backup tools, network management tools — is restricted to authorised administrators. Standard users cannot run or reconfigure these utilities.
Account disablement and termination
Inactive accounts
Accounts that have not been used to log into Allied systems for 90 days are disabled.
High-risk users
Where a specific risk to Allied's systems is identified, the Security Officer may disable the account immediately. See Appendix A.
Termination and offboarding
When a person leaves Allied (employee, contractor, or vendor), their system and physical access is revoked within 24 hours of the effective termination date, or by end of the same business day where notice is shorter.
The process is:
- The People function notifies the Security Officer of upcoming separations and completes the termination checklist together with the manager.
- The Security Officer revokes access rights within the SLA above.
- The People function tracks return of devices, hardware tokens, access cards, and any other physical assets.
The People function, the user's manager, or any colleague must notify the Security Officer immediately where there is evidence that:
- A user has been using their access rights inappropriately
- A user's authentication credentials have been compromised
In either case, an incident is raised under POL-DIG-011 Incident Response Plan and access is suspended pending review.
Related
- POL-DIG-002 Access Control Policy
- POL-DIG-004 Password Policy
- POL-ENT-008 Physical Security Policy
- ISO 27001:2022 Annex A.5.15–A.5.18, A.8.2, A.8.3, A.8.5, A.8.18 (A.8.4 source code access is scoped to POL-DIG-010 SDLC)
Appendix A — High-risk user account disablement
Accounts of users who pose a specific risk to Allied's systems are disabled by the Security Officer. The table below illustrates the format; specific scenarios are handled case-by-case under incident response.
| Risk | Time to disable | Duration of disablement |
|---|---|---|
| User intends to disclose company information to a third party | Immediately | Until investigation closes; may become permanent |
TBD — populate with scenarios and durations agreed with the Security Officer and People function.
Appendix B — Per-cloud-provider access requirements
Access requirements for each cloud service Allied uses are recorded here.
TBD — inventory and per-service requirements to be drafted. Each entry should record: provider, purpose, identity source (SSO or local), MFA enforcement, who has admin, and how access is reviewed.