Implementing ISO 27001 Annex A 5.18 is a fundamental security practice that ensures least privilege access rights are managed throughout the user lifecycle. By enforcing technical verification and role-based controls, organizations realize the business benefit of reduced internal data breach risks and total regulatory compliance.
ISO 27001 Annex A 5.18 Access Rights Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.18. Effective access control is maintained through manual verification and technical rigour at the asset level, rather than relying on the superficial visualisations of a GRC dashboard.
1. Formalise the Topic-Specific Access Control Policy
Control Requirement: A policy must be established, documented, and reviewed based on business and security requirements for access.
Required Implementation Step: Draft a manual policy document that defines the ‘Least Privilege’ principle for every department. Ensure it explicitly bans shared accounts and dictates that access is granted based on specific job roles rather than seniority.
Minimum Requirement: A signed-off Access Control Policy mapped to your current organisational structure.
2. Establish a Manual Provisioning Workflow
Control Requirement: Access rights must be provisioned and assigned in accordance with the access control policy.
Required Implementation Step: Create a paper-based or ticket-driven authorisation trail where every new account requires a formal signature from the asset owner. Verify that the system administrator only acts once the manual authorisation is timestamped and filed.
Minimum Requirement: A sample of 5 recent hires showing a completed ‘Access Request Form’ signed by their respective manager.
3. Execute Role-Based Access Control (RBAC) Mapping
Control Requirement: Access rights should be allocated to users based on their defined roles and responsibilities.
Required Implementation Step: Open your Active Directory or LDAP configuration and manually audit groups. Remove any individual users assigned directly to folders or databases, and re-assign them to specific security groups that match the roles defined in your HR files.
Minimum Requirement: A spreadsheet or matrix showing ‘Role vs. Permission’ for all core business applications.
4. Restrict Privileged Access Rights
Control Requirement: The allocation and use of privileged access rights must be restricted and managed via a formal process.
Required Implementation Step: Log into your production servers and run a script to list all users with ‘sudo’ or ‘Domain Admin’ privileges. Manually justify every single entry; if a user does not need to perform system-level changes daily, revoke their admin rights and move them to a standard user account.
Minimum Requirement: Evidence of a ‘Privileged User Register’ that is updated and verified monthly.
5. Conduct Periodic Manual Access Reviews
Control Requirement: Asset owners must review users’ access rights at regular intervals.
Required Implementation Step: Schedule a quarterly meeting where asset owners must manually sign a ‘User List’ printout for their systems. They must strike through any names that no longer require access, ensuring they aren’t just ‘clicking accept’ in a software portal.
Minimum Requirement: Four quarters of signed and dated ‘User Access Review’ logs for all critical systems.
6. Implement Internal Transfer Modification Protocols
Control Requirement: Access rights must be modified when a user changes roles within the organisation.
Required Implementation Step: Establish a trigger with the HR department where every internal transfer generates a ‘Revoke and Re-issue’ request. Manually strip all previous permissions from the user’s account before granting the new, limited set required for their new role.
Minimum Requirement: A documented case study of an internal transfer where the old permissions were removed within 24 hours.
7. Enforce Immediate Termination Revocation
Control Requirement: Access rights of all employees and external party users must be removed upon termination of their employment, contract, or agreement.
Required Implementation Step: Create a ‘Leaver’s Checklist’ that requires a physical signature from IT confirming that all local accounts, VPNs, and physical fobs have been disabled. This must happen on the employee’s final day, prior to them leaving the premises.
Minimum Requirement: A completed leaver’s file showing that access was revoked at the exact time of the exit interview.
8. Audit Physical Access Rights Integration
Control Requirement: Physical access to sites and facilities must be aligned with digital access rights.
Required Implementation Step: Go to the physical security controller or key-fob system and export the user list. Compare this manually against your HR list; ensure that contractors who have finished their projects no longer have active fobs or codes to the server room.
Minimum Requirement: A monthly reconciliation report between the HR database and the physical door-entry system.
9. Review Database and Application-Level Permissions
Control Requirement: Access to information and application system functions must be restricted in accordance with the access control policy.
Required Implementation Step: Move beyond the OS level and log into specific databases (e.g., SQL Server, Oracle). Manually check the ‘db_owner’ and ‘read/write’ permissions to ensure developers cannot access production data unless specifically authorised for a time-bound change window.
Minimum Requirement: Configuration screenshots showing ‘Deny’ permissions for non-essential staff on production tables.
10. Maintain an Evidence Log for Reconciliation
Control Requirement: Records of access rights management should be maintained for auditing and incident investigation.
Required Implementation Step: Create a central physical or secure digital folder for ‘Access Evidence’. Every month, print the logs of ‘Account Creations’ and ‘Account Deletions’ and have the Security Officer initial them to prove that no ‘shadow IT’ accounts are being created without oversight.
Minimum Requirement: A 12-month archive of system-generated audit logs matched against manual authorisation tickets.
ISO 27001 Annex A 5.18 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Policy Governance | The GRC tool provides a generic template that no one reads or follows. | Compliance fails when the technical reality in the server room contradicts the PDF in the dashboard. |
| User Provisioning | Automated sync with Okta or Azure AD is marked as ‘Complete’. | The tool misses the ‘local admin’ account on the legacy server that isn’t connected to the SSO. |
| Access Reviews | Managers click ‘Approve All’ in a browser notification to clear their inbox. | Effective review requires a manual, eyes-on-glass verification of actual system permissions. |
| Termination | The tool assumes a user is ‘Disabled’ because their email is inactive. | It misses the SSH keys or hardcoded API credentials that remain active on production Linux boxes. |
| Physical Access | The platform has no visibility into physical locks or key-fob systems. | Security is compromised when a ‘Disabled’ digital user still has a working physical key to the office. |
| Privilege Management | GRC dashboards rarely see the ‘sudoers’ file or local group modifications. | Compliance is faked if you don’t manually audit the configuration files on the assets themselves. |
| Internal Transfers | Software often fails to flag ‘permission creep’ where users retain old rights. | Only a manual ‘strip and re-issue’ process ensures the user doesn’t accumulate excessive power. |
| Third-Party Access | Portals focus on employees, often ignoring temporary vendor accounts. | The most common breach point is a forgotten contractor account that the GRC tool never ‘sees’. |
About the author
