ISO 27001 Annex A 5.18 Access Rights Explained

ISO 27001 Access Rights

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.

It is about access rights which means you need to allow people to access what they need to do their job and nothing more.

Key Takeaways

ISO 27001 Annex A 5.18 requires organisations to provision, review, modify, and remove access rights in accordance with the organisation’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 authorisation and is promptly removed or modified when a person’s role changes or their employment ends.

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.

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

Explanation

ISO 27001 Annex A 5.18 Access Rights is a security control that mandates the operational execution of lifecycle management for user permissions. By ensuring only authorised entities access specific assets, organisations achieve a robust security posture and the business benefit of preventing unauthorised data exposure and fraud.

Requirement

• 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

1. 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).”
2. 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?”
3. Review Records: “Show me the evidence of your last quarterly access review. Which accounts were identified as unnecessary and removed?”

FREE 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.

Guidance

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.

Access Control Policy Template

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

How to implement it

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.

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.

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 it

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 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.

Applicability 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. • Leaver Kill-Switch: A checklist to manually remove the user from Microsoft 365, Xero, and change shared passwords (e.g., social media) within 24 hours of departure.
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. • Just-In-Time Access: Granting temporary admin access for specific tasks rather than permanent “Super Admin” rights.
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. • Model Weight Protection: strictly limiting who can download or export proprietary model weights to prevent IP theft.

Applicable Laws and Related Standards

Framework / Law	Relevant Section / Control	Mapping Context & Implementation Focus
NIST CSF v2.0	PR.AA-P1 / PR.AA-P5	Focuses on “Authorisation.” Requires permissions to be granted based on the principle of least privilege and reviewed periodically to prevent “privilege creep.”
NIS2 Directive (EU)	Article 21(2)(g)	Mandates cybersecurity risk-management measures, including “access control policies.” This requires strict management of who can access essential services infrastructure.
DORA (EU)	Article 9(4)(c)	Requires financial entities to implement strict access rights management protocols to ensure that only authorised personnel can access ICT systems and data.
SOC 2 (AICPA)	CC6.1 / CC6.2 / CC6.3	Under the “Logical Access” criteria, SOC 2 requires evidence of how access is provisioned, modified, and revoked throughout the employee lifecycle.
GDPR (EU)	Article 32	Access rights are a critical “technical measure” to protect PII. Over-privileged accounts are a primary source of GDPR-regulated data breaches.
UK Data (Use and Access) Act 2025	Data Trust Frameworks	Evolves GDPR to focus on secure data access. Implementation of 5.18 provides the “Trust” required for administrative ease while maintaining high security thresholds.
Cyber Security and Resilience Bill (UK)	MSP Management Planes	Expands reporting for Managed Service Providers. Strong access rights management for “management planes” is required to prevent systemic supply chain attacks.
CIRCIA (USA)	Reporting Triggers	Incident reporting for critical infrastructure. Unauthorised access resulting from poorly managed rights is a major trigger for the 72-hour reporting mandate.
EU AI Act	Article 15 (Cybersecurity)	High-risk AI systems must implement access restrictions to prevent unauthorised third parties from altering model performance or accessing training data.
ISO/IEC 42001 (AI)	Annex A 8.1 / 8.2	Specific to AI management. Requires that access to AI model weights, datasets, and pipelines be restricted via formal access rights processes.
EU Product Liability Directive (PLD)	Article 6 (Defectiveness)	Strict liability for software flaws. Software with “defective” access controls (e.g., inability to revoke admin rights) can lead to liability for security failures.
ECCF (EU Cybersecurity Certification)	Identity & Access Control	Sets harmonised security labels for products. Achieving “Substantial” or “High” levels requires audited proof of robust access rights management.
HIPAA (USA)	45 CFR § 164.312(a)(1)	The “Access Control” standard. Requires implementation of technical policies to allow only authorised persons access to electronic Protected Health Information (ePHI).
CCPA / CPRA (California)	Section 1798.150	Creates liability for breaches of unencrypted PII. Failing to revoke access for terminated employees is a failure to maintain “reasonable security.”
PCI DSS v4.0	Requirement 7	Strictly mandates that access to system components and cardholder data be limited to “Need to Know” through formal access rights.

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