Access Control Policy

Document ID: ISMS-POL-003 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: Information Security Manager

Purpose and Scope

This policy defines the requirements for controlling access to information, systems, and facilities across [Organisation Name]. It implements the principle of least privilege and need-to-know across the organisation’s information assets in accordance with ISO/IEC 27001:2022 Annex A controls 5.15–5.18 and 8.2–8.5.

This policy applies to all employees, contractors, and third parties who access organisational systems or data, and to all System Owners who approve and manage access to assets under their ownership.

1. Principles

2. Access Request and Approval Procedure

All access to organisational systems must be requested and approved through the formal process below. Informal requests (verbal, instant message, or direct email to IT without a ticket) will not be actioned.

Step-by-Step Process:

1. Raise a service desk ticket — the requester submits an access request ticket via the IT service desk portal, specifying: the system or resource required, the level of access needed (read, write, admin), and the business justification.
2. State business justification — the requester clearly explains why the access is needed and how it relates to their role. “Everyone else has it” is not an acceptable justification.
3. Line manager approval — the requester’s line manager approves or rejects the request in the service desk ticket. The line manager is accountable for the appropriateness of the request.
4. System Owner approval — for Confidential or Restricted systems, the System Owner reviews and approves the request. The System Owner confirms the access is appropriate and consistent with the access control list for their system.
5. IT provisions access — IT implements the access change following the approved ticket. Access is granted as configured — no additional permissions beyond what was approved.
6. Access recorded — the access grant is recorded in the Access Register for the system, including the ticket reference, date, and approver.
7. User notified — IT notifies the requester that access has been provisioned. User accepts responsibility for appropriate use as a condition of access.

Service Level Agreements:

3. Access Review

Regular access reviews ensure that access rights remain appropriate as roles change over time. System Owners are responsible for conducting reviews of their systems on the schedule below.

Access Revocation SLA:

4. Privileged Access Rules

Definition: Privileged access means any account or access right that allows actions beyond those of a standard user, including but not limited to: local or domain administrator rights, root access on servers, cloud management console access, database administrator access, security tooling administration, and firewall or network device administration.

Requirements for all privileged accounts:

• Dedicated privileged account — privileged activity must use a separate named account (e.g., jsmith-admin); the standard day-to-day account (jsmith) must never be granted privileged rights.
• MFA mandatory — MFA is non-negotiable for all privileged accounts; hardware token preferred.
• PAM tool — privileged sessions must be initiated via the Privileged Access Management tool (e.g., CyberArk, AWS Systems Manager Session Manager, or Azure Privileged Identity Management); direct RDP or SSH with stored credentials is prohibited.
• Session recording — privileged sessions on production systems must be recorded where technically feasible; recordings retained for 90 days.
• Just-in-time access — standing privileged access must be replaced with just-in-time activation (time-limited elevation) wherever the PAM tooling supports it.
• Maximum tenure — privileged access must be re-approved by the CISO every 12 months; it is not granted indefinitely.
• No shared admin accounts — named Service Accounts are acceptable for automated processes but must have a documented owner, no interactive login permitted, and minimal permissions.

5. Multi-Factor Authentication Requirements

SMS-based MFA is not recommended as a primary method due to SIM-swapping risk. It is permitted only for low-risk systems as a fallback.

6. Password Policy

All passwords for organisational accounts must meet the following minimum requirements. Password managers (e.g., 1Password, Bitwarden for Business) are approved and encouraged for generating and storing complex credentials.

7. Remote Access Policy

• VPN requirement: All access to internal systems (file shares, internal web applications, management interfaces) from outside the office network requires an active VPN connection. Direct internet-facing access to internal systems without VPN is prohibited.
• Split tunnelling: Disabled for privileged access sessions. Permitted for standard users with DNS filtering enforced to block malicious domains.
• Personal devices: Personal (BYOD) devices may access corporate email and calendar via managed app (Intune MAM) only. Personal devices must not be used to connect to VPN or access internal systems without MDM enrolment and ISM approval.
• VDI option: Where personal device VPN access is required, a virtual desktop (VDI) solution is the preferred approach — no data stored locally.
• Unattended sessions: All remote sessions auto-lock after 10 minutes of inactivity. VPN sessions automatically terminate after 8 hours; re-authentication required.
• Connection from high-risk regions: Connections from countries classified as high-risk by the organisation’s threat intelligence feed trigger an additional MFA challenge or are blocked pending review.

8. Exceptions

All exceptions to this policy (e.g., a legacy system that cannot support MFA, a service account that requires shared credentials for technical reasons) must be:

1. Submitted in writing to the ISM with a description of the exception, the technical reason, the affected systems, and proposed compensating controls.
2. Reviewed and approved in writing by the CISO before the exception is in place.
3. Documented in the Exceptions Register with an expiry date (maximum 12 months per exception).
4. Reviewed quarterly by the ISM; renewals require CISO re-approval; expired exceptions with no renewal result in the non-compliant configuration being remediated.

9. Review History