In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.18 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.18 Access Rights
ISO 27001 Annex A 5.18 requires organizations to provision, review, modify, and remove access rights in accordance with the organization’s access control policy. While Annex A 5.15 sets the rules for access, this control is about the operational execution of those rules throughout the user lifecycle. The objective is to ensure that access is only granted after proper authorization and is promptly removed or modified when a person’s role changes or their employment ends.
Core requirements for compliance include:
- Lifecycle Management: You must manage access rights from start to finish. This is triggered by HR events: hiring (Joiner), role changes (Mover), and terminations (Leaver).
- Owner Authorization: Access to any system or data set must be authorized by the specific Asset Owner before it is provisioned.
- Segregation of Duties: To prevent fraud, the person who requests access (e.g., a line manager) should be different from the person who grants it (e.g., IT Admin).
- Avoid Account Cloning: When setting up new users, do not simply “clone” a similar user’s account. This leads to Privilege Creep, where users accumulate excessive permissions they don’t actually need.
- Temporary Access for Third Parties: Suppliers and contractors should only be given access for the specific duration of their task, with an automatic “kill date” where possible.
- Periodic Access Reviews: Rights must be re-certified at regular intervals (e.g., quarterly). Managers must confirm that their team members still require the access they currently have.
Audit Focus: Auditors will look for “The JML Lifecycle Trail”:
- Timestamp Verification: “Show me the exit date for your last three leavers. Now show me the system logs proving their access was disabled within the timeframe defined in your policy (e.g., within 24 hours).”
- Mover Rights: “When this employee moved from Finance to Marketing, can you prove their Finance system access was revoked before their Marketing access was granted?”
- Review Records: “Show me the evidence of your last quarterly access review. Which accounts were identified as unnecessary and removed?”
Access Lifecycle Triggers (Audit Prep):
| Event Type | Critical Trigger | Required Security Action | Target Timeline | ISO 27001:2022 Control |
|---|---|---|---|---|
| Joiner | Signed Contract. | Provision based on Least Privilege. | By Day 1. | Annex A 5.18 / 6.3 |
| Mover | HR Role Change. | Revoke old rights + Add new rights. | < 48 Hours. | Annex A 5.18 |
| Leaver | Resignation / Notice. | Immediate Disable (Kill Switch). | < 1 Hour. | Annex A 5.18 / 6.5 |
| Review | Calendar Schedule. | Manager recertifies current access. | Every 90 Days. | Annex A 5.18 |
Table of contents
- What is ISO 27001 Annex A 5.18?
- Watch the ISO 27001 Annex A 5.18 Tutorial
- ISO 27001 Annex A 5.18 Implementation Guidance
- How to implement ISO 27001 Annex A 5.18
- Lifecycle Triggers Table
- ISO 27001 Access Control Policy Template
- How to comply
- How to pass the ISO 27001 Annex A 5.18 audit
- What will an audit check?
- Top 3 ISO 27001 Annex A 5.18 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.18 across different business models.
- Fast Track ISO 27001 Annex A 5.18 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.18 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 controls and attribute values
What is ISO 27001 Annex A 5.18?
ISO 27001 Annex A 5.18 is about access rights which means you need to allow people to access what they need to do their job and nothing more.
ISO 27001 Annex A 5.18 Access Rights is an ISO 27001 control that requires an organisation to mange the full life cycle of access rights based on the topic specific policy and rules of access control.
ISO 27001 Annex A 5.18 Purpose
The purpose of ISO 27001 Annex A 5.18 is a preventive control that ensures access to information and other associated assets is defined and authorised according to the business requirements.
ISO 27001 Annex A 5.18 Definition
The ISO 27001 standard defines ISO 27001 Annex A 5.18 as:
Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organisation’s topic-specific policy on and rules for access control.
ISO 27001:2022 Annex A 5.18 Access Rights
Watch the ISO 27001 Annex A 5.18 Tutorial
In the video ISO 27001 Access Rights Explained – ISO27001:2022 Annex A 5.18 I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 5.18 Implementation Guidance
General considerations
Role based access is a great mechanism for managing access and should be considered.
Cloning accounts should be avoided. It is easy when creating new accounts to clone accounts. It is not that should not do it but if you do do it take great care with it. We have seen this go badly wrong and all users end up with super user access.
Managing Access Rights
Managing access rights is a straightforward process and easy to get right. Consider the following in your process.
- You want to get the authorisation from the asset owner
- Access will be granted based on policy and business requirements
- We separate out the person making the request for access from the person granting access. This is called segregation of duty.
- Access rights are provided for as long as needed and removed when no longer required.
- Access rights are removed when a person leaves the organisation.
- Suppliers and third parties that require access are provided the temporary access they need for the time they need it before it is removed.
- Access is provided after it has been authorised and not before. We do not grant access then go back and complete the process for audit purposes.
- Records of who have access to what are maintained and managed.
- Reviews of access are carried out regularly and more frequently for privileged accounts. We keep records of access reviews.
How to implement ISO 27001 Annex A 5.18
Implementing ISO 27001 Annex A 5.18 requires a robust framework for managing the lifecycle of user permissions. By transitioning from ad-hoc provisioning to a policy-driven approach, organisations can ensure that access is granted based on the Principle of Least Privilege (PoLP) and revoked immediately when no longer required. This technical guide outlines the action-oriented steps to formalise your identity and access management (IAM) processes and satisfy lead auditor requirements.
1. Formalise the Access Rights Policy and Procedures
Establish a documented framework that dictates how permissions are requested, approved, and assigned. This action results in a standardised governance layer that prevents “access creep” and ensures accountability for every permission granted.
- Define clear criteria for access based on the “Need to Know” and “Need to Use” principles.
- Document the mandatory authorisation path, requiring Asset Owner approval for all new or modified access requests.
- Specify technical requirements for different types of access, such as remote vs local or administrative vs standard user.
2. Provision Access Rights via a Centralised IAM Framework
Execute the provisioning of user permissions through a formalised request system. This result-focused step ensures that all access is linked to a specific business requirement and a validated identity.
- Utilise Role-Based Access Control (RBAC) to map IAM roles to specific job functions within the organisation.
- Implement Multi-Factor Authentication (MFA) as a technical prerequisite for accessing sensitive or critical systems.
- Maintain a centralised User Access Register that provides a real-time inventory of all active accounts and their associated permissions.
3. Execute Periodic Access Rights Reviews
Perform regular audits of existing permissions to verify their ongoing necessity. This action ensures that access remains aligned with current job roles and that redundant permissions are identified for removal.
- Schedule quarterly reviews for privileged or administrative accounts and annual reviews for standard user accounts.
- Require Asset Owners to provide a formal sign-off or digital re-authorisation for all continuing access rights.
- Document the outcome of every review, including any identified discrepancies and the subsequent corrective actions taken.
4. Formalise Access Modification and Transfer Protocols
Establish a structured process for updating permissions when a user’s role or responsibilities change. This results in the immediate adjustment of access levels to match the new risk profile of the individual.
- Implement a “mover” workflow that triggers a full review and reset of permissions during internal transfers.
- Require the revocation of old access rights before new permissions are provisioned to prevent the accumulation of excessive privileges.
- Update the User Access Register immediately to reflect changes in role or department.
5. Revoke Access Rights and Decommission Identities
Execute the immediate removal of all physical and logical access upon the termination of an employee’s contract or third-party agreement. This critical step prevents unauthorised access by former staff and mitigates the risk of insider threats.
- Coordinate with Human Resources to ensure IT is notified of all leavers in real-time.
- Disable all logical accounts, VPN tokens, and MFA credentials within a defined timeframe (typically within 24 hours of termination).
- Recover physical assets, including badges, keys, and mobile devices, as part of the formal offboarding checklist.
Lifecycle Triggers Table
| Event | Trigger | Action Required | Timeline |
| Joiner | Signed Contract + Start Date. | Provision Account based on Role. | Day 1. |
| Mover | Job Title Change (HR). | Revoke old rights + Add new rights. | < 48 Hours. |
| Leaver | Resignation / Termination. | Immediate Disable (Kill Switch). | < 1 Hour. |
| Review | Quarterly Schedule. | Manager recertifies current access. | Every 90 Days. |
ISO 27001 Access Control Policy Template
The ISO 27001 Access Control Policy template is pre written and ready to go. It is one of the required ISO 27001 policies that sets out the organisations approach to access control.
How to comply
To comply with ISO 27001 Annex A 5.18 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to
- Implement a process for creating, updating and removing access rights
How to pass the ISO 27001 Annex A 5.18 audit
To pass an audit of ISO 27001 Annex A 5.18 you are going to make sure that you have followed the steps above in how to comply.
What will an audit check?
The audit is going to check a number of areas. Lets go through the most common
1. That you have not done something stupid
The auditor is going to check the rules, procedures and access control methodology and make sure you followed them. As with everything having documented evidence of anything you can is going to be your friend. So practical things like asset registers, access control procedures that you can evidence are in operation, reviews of access. Work through recent hires for example and ensure the processes were followed and look for the gotchas. Is there an approval audit trail. When you log into the system that was approved does the users access match what was requested.
The easiest win for an auditor is get you to show them the admin accounts on what ever system you are using and then explain the accounts that are in the admin group. 9 out of 10 times there are admin accounts in here you forgot about, are for people that left or you are unsure yourself what the account is. Instant problem. Check now.
2. That you have rules, processes and you have followed them and have trained people
This is obvious but they are going to look that you have documented what you say you do, that you follow it and that you have trained people. The biggest gotcha here is having people with accounts that have left. In other words you didn’t have or follow a leaver process and so people’s access remain even though their contract has ended.
3. Documentation
They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match. Doing anything else would be a massive own goal.
Top 3 ISO 27001 Annex A 5.18 Mistakes People Make and How to Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.18 are
1. People have left but they still have an account
Make sure that access to systems is up to date and that people or third parties that have left no longer have access or accounts.
2. Third parties have open access and account they do not need
Third parties should follow process and the process should be to grant access to them when the access required and remove it when it is not. It should not be open and continual access. Consider the example where you need a third party to fix something. You would grant access to allow the fix and then remove it. You would not have open ended access granted.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability of ISO 27001 Annex A 5.18 across different business models.
| Business Type | Applicability & Interpretation | Examples of Control |
|---|---|---|
| Small Businesses |
Manual JML Checklists. You likely lack expensive IAM software. Compliance is achieved via manual checklists (Joiners/Leavers) ensuring no one retains access after they leave. |
• New Starter Form: A simple document (or email trail) where the Business Owner approves exactly what software a new hire needs. |
| Tech Startups |
RBAC & Automated Offboarding. Auditors expect Role-Based Access Control (RBAC) to prevent “Permission Creep.” When a developer becomes a manager, their old permissions should be revoked. |
• Identity Provider (IdP): Using Okta or Google Workspace to map groups (e.g., “Engineering”) to AWS roles. Removing the user from the group automatically revokes access to all connected apps. |
| AI Companies |
Dataset & Model Granularity. Access rights must separate those who build models from those who deploy them. Research teams should often have Read-Only access to production data to prevent corruption. |
• Data Silos: Using IAM policies to ensure only specific ETL service accounts (not humans) have “Write” access to raw training data buckets. |
Fast Track ISO 27001 Annex A 5.18 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.18 (Access rights), the requirement is to manage the full lifecycle of access rights, provisioning, reviewing, modifying, and removing them, in accordance with your organization’s access control policy. This is a critical preventive control that ensures the right people have the right access at the right time, and that access is promptly removed when no longer needed (e.g., when an employee leaves).
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Policy Ownership | Rents access to your JML rules; if you cancel the subscription, your documented provisioning standards and history vanish. | Permanent Assets: Fully editable Word/Excel Access Control Policies and Trigger Tables that you own forever. | A localized “Access Control Policy” defining a 1-hour “kill switch” timeline for involuntary terminations. |
| Operational Utility | Attempts to “automate” workflows via dashboards that cannot decide specific role-based permissions or verify manual “kill switch” actions. | Governance-First: Formalizes your existing IT ticketing and HR processes into an auditor-ready “Least Privilege” framework. | A “Lifecycle Triggers Table” proving that access is modified or revoked immediately upon an HR status change. |
| Cost Efficiency | Charges an “Access Event Tax” based on user count or JML events, creating perpetual overhead as your headcount grows. | One-Off Fee: A single payment covers your access governance for 10 joiners a year or 1,000. | Allocating budget to advanced IAM or MFA technology rather than monthly “access recertification” dashboard fees. |
| Strategic Freedom | Mandates rigid reporting and monitoring formats that often fail to align with hybrid-work models or lean startup cultures. | 100% Agnostic: Procedures adapt to any environment—high-end IAM automation or manual risk-managed checklists. | The ability to evolve your JML process and access review frequency without reconfiguring a rigid SaaS compliance module. |
Summary: For Annex A 5.18, the auditor wants to see that you have a formal process for managing access rights and proof that it is followed (e.g., timely de-provisioning and regular access reviews). The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 5.18 FAQ
What is ISO 27001 Annex A 5.18?
ISO 27001 Annex A 5.18 is an organisational control that requires access rights to information and other associated assets to be provisioned, reviewed, modified, and removed in accordance with the organisation’s topic-specific policy.
- Covers the entire lifecycle of access, from onboarding to termination.
- Ensures the Principle of Least Privilege (PoLP) is maintained across all systems.
- Applies to internal employees, third-party contractors, and external partners.
Is a formal process for revoking access rights mandatory?
Yes, a formalised process for the timely removal or revocation of access rights is a mandatory requirement to prevent unauthorised data exposure and “access creep.”
- Access must be revoked immediately upon termination of employment or contract.
- The process must encompass both logical (digital) and physical access permissions.
- Revocation actions must be documented to provide an audit trail for certification bodies.
How often should access rights be reviewed for compliance?
While the ISO 27001 standard does not mandate a fixed frequency, industry best practice suggests reviewing privileged access rights quarterly and standard user rights annually.
- High-risk or “Critical” assets require more frequent validation by asset owners.
- Ad-hoc reviews should be triggered by internal role changes or transfers.
- All reviews must result in a signed record confirming that access remains necessary for business functions.
Who is responsible for managing and authorising access rights?
The responsibility for authorising access rights lies with the designated Asset Owner, while the technical execution is typically managed by the IT or Security team.
- Asset Owners define who needs access based on the “Need to Know” principle.
- IT teams provision or revoke rights based on formalised requests from those owners.
- HR departments are responsible for notifying IT of joiners, movers, and leavers.
What is the difference between Access Control (5.15) and Access Rights (5.18)?
The difference is that Annex A 5.15 (Access Control) defines the high-level rules and policy, whereas Annex A 5.18 (Access Rights) focuses on the operational lifecycle of granting and removing specific permissions.
- 5.15 is the “What”: The strategy and rules governing who can see what.
- 5.18 is the “How”: The tactical provisioning and de-provisioning of users.
- Together, they form a complete identity and access management (IAM) framework.
What evidence do auditors expect for Annex A 5.18?
Auditors expect to see a documented audit trail that proves access was formally authorised, regularly reviewed, and promptly revoked when no longer required.
- User access registers mapping users to specific permission levels.
- Signed authorisation forms or digital tickets for new access requests.
- Minutes or logs from periodic access review meetings showing changes were made.
How should third-party access rights be managed?
Third-party access rights must be managed with the same level of rigour as internal staff, including time-limited permissions and immediate revocation at the end of a contract.
- Access should be restricted to the specific systems required for the service.
- Contracts should specify the supplier’s obligation to report staff changes.
- Regular reviews are essential to ensure “dormant” vendor accounts are disabled.
Related ISO 27001 Controls
ISO 27001 Annex A 5.16 Identity Management
ISO 27001 Annex A 8.2 Privileged Access Rights
ISO 27001 Annex A 5.15 Access Control
Further Reading
ISO 27001 Access Control Policy Beginner’s Guide
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Protect | Identity and access management | Protection |
| Integrity | ||||
| Availability |
