Auditing ISO 27001 Annex A 5.18 Access Rights is the rigorous verification of how user permissions are granted, reviewed, and revoked. This process validates the Primary Implementation Requirement of applying the principle of least privilege through Role-Based Access Control (RBAC). The Business Benefit minimizes insider threats and data leakage by ensuring users only access data necessary for their specific job functions.
This technical verification tool is designed for lead auditors to establish the legitimacy of organisational access governance. Use this checklist to validate compliance with ISO 27001 Annex A 5.18 (Access rights) by ensuring that the allocation and review of access are based on the principle of least privilege and business necessity.
1. Access Rights Provisioning Policy Formalisation Verified
Verification Criteria: A documented procedure defines the full lifecycle of access rights, including the methods for request, authorisation, provisioning, and periodic review.
Required Evidence: Approved Access Control Policy or Identity and Access Management (IAM) Standard with version control.
Pass/Fail Test: If the organisation lacks a documented process for how access is formally requested and authorised prior to provisioning, mark as Non-Compliant.
2. Role-Based Access Control (RBAC) Alignment Confirmed
Verification Criteria: Access rights are assigned based on predefined job roles and the principle of least privilege, rather than individual user requests.
Required Evidence: A Role-Based Access Control (RBAC) matrix or entitlement catalogue mapping roles to specific system permissions.
Pass/Fail Test: If a user is found to have “Super User” or “Admin” rights without a corresponding business justification in their job role description, mark as Non-Compliant.
3. Formal Access Authorisation Records Validated
Verification Criteria: Every grant of access right is backed by a formal authorisation from the relevant asset owner or management representative.
Required Evidence: Completed access request tickets (e.g., Jira, ServiceNow) or signed authorisation forms for a sample of new users.
Pass/Fail Test: If an account has been provisioned without a documented and timestamped approval from the asset owner, mark as Non-Compliant.
4. Privileged Access Right Restrictions Verified
Verification Criteria: The allocation of privileged access rights (e.g., administrator, root) is strictly limited to unique identities and restricted to the minimum time required.
Required Evidence: List of users with administrative privileges and evidence of “Just-in-Time” (JIT) access logs or vaulting software reports.
Pass/Fail Test: If generic administrative accounts (e.g., “admin”, “administrator”) are being shared among multiple staff members, mark as Non-Compliant.
5. Periodic Access Rights Review Execution Evidenced
Verification Criteria: Access rights for all users are reviewed at planned intervals to ensure they remain appropriate for the current business role.
Required Evidence: Signed Access Review reports or digital audit trails showing that asset owners have recertified user access within the last 12 months.
Pass/Fail Test: If the organisation cannot provide evidence of a completed user access review for critical systems within the last year, mark as Non-Compliant.
6. Immediate Revocation of Access for Leavers Confirmed
Verification Criteria: Access rights are disabled or removed immediately upon the termination of employment, contract, or agreement.
Required Evidence: Cross-reference of HR termination dates against the account “Disabled” timestamp in the Identity Provider (e.g., Entra ID, Okta).
Pass/Fail Test: If any sampled leaver retains “Active” status in a primary corporate system more than 24 hours post-termination, mark as Non-Compliant.
7. Modification of Access Rights for “Movers” Validated
Verification Criteria: When a user changes roles within the organisation, their old access rights are removed and new rights are provisioned based on the new role.
Required Evidence: Audit logs for a sample of “Movers” showing the deletion of old permissions and the addition of new role-specific rights.
Pass/Fail Test: If a user who has moved departments retains “legacy” access to their previous department’s sensitive data, mark as Non-Compliant.
8. Access Rights for External Parties Managed
Verification Criteria: Access rights for vendors, contractors, and third parties are restricted to the specific assets required and have a defined expiry date.
Required Evidence: List of external accounts in the IAM system showing “Account Expiry” dates and limited group memberships.
Pass/Fail Test: If third-party accounts are found to have indefinite access without an expiration date or a sunset clause in the contract, mark as Non-Compliant.
9. Segregation of Duties in Access Management Verified
Verification Criteria: The individuals responsible for authorizing access are distinct from those responsible for technical provisioning.
Required Evidence: Workflow audit trail showing different individuals acting as “Approver” and “Implementer” on the same access request.
Pass/Fail Test: If an IT administrator has the authority to both approve and provision their own access rights or those of others without a second set of eyes, mark as Non-Compliant.
10. Access Rights Logging and Monitoring Confirmed
Verification Criteria: Changes to access rights (creations, modifications, deletions) are logged and monitored for unauthorised activity.
Required Evidence: Security Information and Event Management (SIEM) reports or IAM audit logs showing all administrative changes to user permissions.
Pass/Fail Test: If the IAM system does not generate an immutable audit trail of who modified a user’s permissions, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Access Review | GRC tool identifies that a task marked “Review Access” was clicked as “Complete”. | Verify the *content* of the review; did the manager actually scrutinise the list or just “Bulk Approve” to clear the notification? |
| Least Privilege | Tool checks if every user is assigned to a “Group”. | Inspect the *permissions* of that Group; SaaS defaults often give “Editor” or “Admin” access to basic user groups. |
| Revocation | SaaS platform verifies that the “SSO Integration” is active. | Search for “Orphaned Accounts”—accounts created locally in secondary apps (like AWS or marketing tools) that SSO doesn’t kill. |
| Privileged Access | Tool counts the number of “Admins” and reports it. | An auditor must demand the *business justification* for each admin. If 50% of the company has admin rights, the control is broken. |
| Mover Process | GRC tool assumes “Active” status in HR means access is correct. | Verify “Permission Creep”—where users accumulate new rights as they change roles but never lose their old ones. |
| Third-Party Access | Tool verifies that an NDA is on file for the vendor. | Check the *actual access logs*. Does the vendor still have access months after the project ended? |
| Logging Integrity | Tool confirms that logs are being “Ingested”. | Verify that an Admin cannot delete or modify the logs to hide unauthorised permission escalations. |
About the author
