ISO 27001 Annex A 5.15 Audit Checklist

Auditing ISO 27001 Annex A 5.15 Access Control involves the rigorous verification of logical and physical access governance. This process validates the Primary Implementation Requirement of provisioning, reviewing, and revoking access rights based on business needs and the principle of least privilege. The Business Benefit protects information assets from unauthorized access, ensuring data confidentiality and system integrity.

This technical verification tool is designed for lead auditors to establish the rigour of logical and physical access governance. Use this checklist to validate compliance with ISO 27001 Annex A 5.15 (Access Control) by ensuring that access rights are provisioned, reviewed, and revoked based on documented business requirements and the principle of least privilege.

1. Access Control Policy Approval and Communication Verified

Verification Criteria: A documented access control policy exists, is approved by management, and has been communicated to all relevant stakeholders and system users.

Required Evidence: Approved Access Control Policy with version history and evidence of distribution (e.g. staff handbook acknowledgement or intranet logs).

Pass/Fail Test: If the policy lacks a formal management sign-off or does not define rules for both logical and physical access, mark as Non-Compliant.

2. Business-Driven Access Requirement Definition Confirmed

Verification Criteria: Access rights for each information asset are defined based on business needs, job functions, and the classification of information.

Required Evidence: A Role-Based Access Control (RBAC) matrix or access rights register mapping specific job roles to required system permissions.

Pass/Fail Test: If users are granted access based on personal request rather than a predefined role mapping or business justification, mark as Non-Compliant.

3. User Registration and De-registration Records Present

Verification Criteria: A formal process is in place for the unique identification and registration of users, including the immediate removal of access upon termination of employment.

Required Evidence: Completed Joiner/Leaver/Mover (JLM) forms or tickets from the ITSM tool (e.g. Jira/ServiceNow) showing timestamps for access creation and revocation.

Pass/Fail Test: If a sample of recently terminated employees still possesses active accounts in any corporate system, mark as Non-Compliant.

4. Privileged Access Management (PAM) Restrictions Validated

Verification Criteria: The allocation and use of privileged access (e.g. Admin, Root) is strictly controlled, restricted to the minimum necessary, and assigned to unique identities.

Required Evidence: List of users with administrative rights per system and evidence of “Just-In-Time” (JIT) access logs or vaulting (e.g. CyberArk/BeyondTrust).

Pass/Fail Test: If generic administrative accounts (e.g. “admin”, “administrator”) are shared among multiple staff members, mark as Non-Compliant.

5. Periodic Access Rights Review Execution Evidenced

Verification Criteria: Asset owners review users’ access rights at regular intervals (at least annually) to confirm suitability and necessity.

Required Evidence: Signed Access Review reports or digital audit trails from a GRC tool showing that a manager has reviewed and re-authorised user lists.

Pass/Fail Test: If the organisation cannot provide evidence of an access review conducted within the last 12 months for critical systems, mark as Non-Compliant.

6. Strong Authentication and MFA Enforcement Verified

Verification Criteria: Access to sensitive systems and remote environments is protected by strong authentication, including Multi-Factor Authentication (MFA).

Required Evidence: Configuration screenshots from the Identity Provider (e.g. Azure AD/Okta) showing MFA is “Enforced” or “Required” for the ISMS scope.

Pass/Fail Test: If MFA is not required for remote access (VPN) or administrative console access, mark as Non-Compliant.

7. Source Code Access Restrictions Validated

Verification Criteria: Read and write access to program source code is restricted to authorised personnel based on a strictly “need-to-know” basis.

Required Evidence: Repository permission logs (e.g. GitHub/GitLab) showing that access is limited to the current development team and restricted for all others.

Pass/Fail Test: If all employees have read access to the organisation’s proprietary source code repositories, mark as Non-Compliant.

8. Segregation of Access Control Roles Confirmed

Verification Criteria: The person who requests access is not the same person who authorises and provisions the access, preventing unauthorised elevation of privilege.

Required Evidence: Audit trail of access requests showing three distinct actors: the Requester, the Approver (Manager), and the Implementer (IT/Security).

Pass/Fail Test: If an IT administrator can grant themselves additional permissions without a secondary approval layer, mark as Non-Compliant.

9. Generic and Service Account Lockdown Verified

Verification Criteria: Use of generic or shared accounts is prohibited, and service accounts are restricted to non-interactive logins wherever technically feasible.

Required Evidence: System configuration logs showing that interactive login is disabled for service-level accounts.

Pass/Fail Test: If a human user is found to be logging into a system using a shared “guest” or “service” account for daily tasks, mark as Non-Compliant.

10. Physical Access Rights Alignment Verified

Verification Criteria: Physical access to secure areas (data centres, server rooms) is restricted and aligned with the logical access permissions of the individual.

Required Evidence: Access badge logs and the physical access authorisation list, cross-referenced with the individual’s role in the HR system.

Pass/Fail Test: If non-technical staff or third-party cleaners have unescorted/unrecorded access to server rooms, mark as Non-Compliant.

About the author