ISO 27001:2022 Annex A 5.18 Access Rights Explained

In this guide you will learn how to implement ISO 27001 Annex A 5.18 Access Rights and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

ISO 27001 Annex A 5.18 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.

Purpose & Definition

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.

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

FREE ISO 27001 Annex A 5.18 Training Video

In this free training video you will learn How to implement ISO 27001 Access Rights (Annex A 5.18 ) and Pass Your Audit.

Implementation Guide

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.

ISO 27001 Access Rights & User Access Review Policy Template

The access control policy sets our your approach to access rights.

How to implement ISO 27001 Annex A 5.18

Implementing ISO 27001 Annex A 5.18 requires a disciplined approach to managing the lifecycle of access permissions. As a Lead Auditor, I recommend a process that moves beyond simple password management to a state where access is dynamically provisioned, regularly reviewed, and revoked based on specific organisational triggers. Following these ten steps will ensure your access rights are technically robust and compliant with the standard.

1. Formalise the Access Control Policy

Establish the foundational rules for how access is granted, managed, and revoked. This policy must be approved by management and aligned with the business requirements for security.

• Define the criteria for granting access based on job roles and responsibilities.
• Specify the requirements for Multi-Factor Authentication (MFA) across all remote and privileged connections.
• Document the organisational stance on the “Principle of Least Privilege” and “Need to Know” basis.

2. Align Access Rights with the Asset Register

Ensure that every information asset identified in your Asset Register has a defined set of access permissions and an assigned owner responsible for approvals.

• Map sensitive data sets to specific system roles.
• Identify the technical owners who have the authority to authorise access to specific applications.
• Categorise assets by risk level to determine the frequency of access reviews.

3. Provision Access via Formal Authorisation Workflows

Grant access rights only through a documented request and approval process. This prevents “shadow access” where permissions are granted informally.

• Use a centralised Identity and Access Management (IAM) system or a formal ticketing system for all requests.
• Ensure that the asset owner provides explicit authorisation before any technical provisioning occurs.
• Maintain a clear audit trail of who requested access, who approved it, and when it was implemented.

4. Implement Role-Based Access Control (RBAC)

Standardise permissions by creating IAM roles that correspond to specific job functions rather than assigning rights to individual users.

• Define standard “profiles” for common organisational roles, such as Finance, HR, or Engineering.
• Simplify the onboarding process by assigning users to these predefined roles.
• Reduce the risk of manual configuration errors by using role-based templates in your directory services.

5. Restrict Access using the Principle of Least Privilege

Limit user permissions to the absolute minimum required to perform their job duties. This limits the potential damage from compromised accounts.

• Audit existing accounts to identify and remove unnecessary high-level permissions.
• Avoid the use of local administrator accounts for daily tasks.
• Ensure that temporary access for specific projects is time-bound and automatically expires.

6. Secure Privileged Access Management (PAM)

Apply stricter controls to accounts with elevated rights, such as system administrators or database owners, as these represent the highest risk.

• Mandate the use of dedicated administrative accounts that are separate from standard user accounts.
• Implement privileged session monitoring or logging for all high-risk activities.
• Enforce strict MFA requirements for every privileged login attempt.

7. Conduct Periodic User Access Reviews (UAR)

Perform regular audits of current access rights to ensure they remain appropriate for the users’ current roles.

• Review all privileged access rights at least quarterly.
• Engage asset owners in the review process to confirm that their staff still require existing permissions.
• Identify and remove “privilege creep” where users retain access from previous roles.

8. Modify Access Rights during Job Role Transitions

Update user permissions immediately when an employee moves to a new department or changes their job function.

• Establish a “Mover” process that triggers an automatic review of existing rights.
• Remove access to old systems and data sets before provisioning new ones.
• Ensure that the new manager approves the updated access profile.

9. Revoke Access via Integrated Offboarding

Integrate your HR termination process with your IAM system to ensure access is disabled the moment an employee leaves the organisation.

• Automate the revocation of cloud service and internal network access upon HR notification.
• Update Record of Employment (ROE) documents to confirm that physical tokens and access cards have been returned.
• Verify that any “hidden” access, such as shared service accounts or API keys, is also rotated or removed.

10. Audit and Document Access Lifecycle Evidence

Maintain the evidence required to prove to an ISO 27001 auditor that your access control processes are functioning as documented.

• Retain logs of all provisioning, modification, and revocation activities.
• Store signed copies of periodic access reviews as proof of governance.
• Review system logs for any instances of unauthorised access attempts or policy violations.

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 audit ISO 27001 Annex A 5.18

As an ISO 27001 Lead Auditor, I have designed this audit process to help you verify that access rights are provisioned, reviewed, and revoked in strict accordance with Annex A 5.18. Auditing this control requires a deep dive into the lifecycle of a user’s permissions, ensuring that the principle of least privilege is not just a policy statement, but a technical reality. Follow these ten steps to ensure your organisation meets the rigorous requirements of the 2022 standard.

1. Inspect the formal Access Control Policy

Verify that a documented policy exists which defines the rules for granting and managing access rights. The auditor will check that this policy is approved by management and communicates the requirements for least privilege and need-to-know across the organisation.

• Confirm the policy covers all information assets and systems.
• Check for specific mandates regarding Multi-Factor Authentication (MFA).
• Ensure the policy defines the roles responsible for approving access requests.

2. Cross-reference the Asset Register with system permissions

Review the Asset Register to ensure that every information asset has a clearly defined owner and that access rights are mapped to these assets. The result should show that permissions are not arbitrary but are linked to specific business requirements.

• Identify the owners for critical applications and databases.
• Validate that owners have reviewed and approved the access profiles for their assets.
• Check that asset classifications dictate the level of access security required.

3. Validate the Joiners process for formal authorisation

Sample a selection of new employees to ensure that their access was provisioned only after formal authorisation. You must prove that no access was granted without a documented request and a corresponding approval from the asset owner.

• Inspect the ticketing system or IAM workflow for initial access requests.
• Verify that identity verification took place before credentials were issued.
• Ensure that the provisioned access matches the authorised request exactly.

identity and access management workflow, AI generated Shutterstock

4. Evaluate Identity and Access Management (IAM) role assignments

Analyse the technical configuration of IAM roles to ensure they align with the Role-Based Access Control (RBAC) framework. The auditor looks for evidence that permissions are assigned to roles rather than individuals to prevent configuration drift.

• Review the permissions associated with standard user roles.
• Check for “orphaned” accounts that are not linked to active employees.
• Verify that generic or shared accounts are disabled or strictly controlled.

5. Verify Multi-Factor Authentication (MFA) enforcement

Test the enforcement of MFA across the organisational perimeter and for all privileged accounts. The result must demonstrate that single-factor authentication is not permitted for remote access or high-risk administrative tasks.

• Perform a technical check on VPN and cloud service login configurations.
• Review a sample of privileged accounts to confirm MFA is active.
• Check for documented justifications where MFA is technically not feasible.

6. Assess Segregation of Duties (SoD) within critical systems

Inspect system configurations to ensure that conflicting duties are separated between different individuals. This prevents a single person from executing a complete process that could lead to fraud or error without detection.

• Check that the person who initiates a payment cannot also approve it.
• Verify that developers do not have administrative access to production environments.
• Review the SoD matrix to ensure it is up to date and technically enforced.

7. Audit the Movers process for permission drift

Select a sample of staff who have changed roles within the organisation to verify that their previous access rights were revoked. The auditor looks for “privilege creep,” where employees accumulate permissions from multiple departments over time.

• Compare current access rights against the requirements of the new job description.
• Check the timestamps for when old permissions were removed versus when new ones were added.
• Verify that the new manager has reviewed and accepted the user’s current access profile.

8. Examine Leaver revocation timelines against Record of Employment (ROE) data

Reconcile HR termination records with IAM system logs to ensure that access was revoked immediately upon departure. Any delay in de-provisioning represents a significant security risk and a non-conformity.

• Verify that access was disabled on or before the final date in the ROE documents.
• Check that physical access cards and hardware tokens were collected.
• Ensure that remote access and cloud application accounts were included in the revocation.

9. Review evidence of periodic User Access Reviews (UAR)

Inspect the outputs of recent access reviews to ensure they are conducted at planned intervals. You must prove that asset owners have verified the continued necessity of permissions for every user under their remit.

• Check for signed UAR reports from the last six to twelve months.
• Verify that any discrepancies identified during the review were remediated promptly.
• Ensure that privileged accounts are reviewed more frequently than standard accounts.

10. Analyse system logs for unauthorised access attempts

Review audit logs to confirm that the organisation monitors for and responds to unauthorised access activity. The auditor expects to see that logs are protected from tampering and are reviewed regularly.

• Inspect logs for multiple failed login attempts on privileged accounts.
• Verify that alerts are triggered for access to sensitive data outside of normal hours.
• Ensure that audit trails include the identity of the person granting or modifying 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 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.

ISO 27001 Annex A 5.18 FAQ

Related ISO 27001 Controls and Further Reading

• ISO 27001 Annex A 8.2 Privileged Access Rights
• 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

About the author