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.
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 Audit ISO 27001 Annex A 5.18
- 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 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.18 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
Stop Guessing. Start Passing.
AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt
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.
I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.
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.
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 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.
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.
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
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. • 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. |
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 password standards and MFA requirements 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 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. |
Beyond RBAC: Attribute-Based and Just-In-Time Access
Role-Based Access Control (RBAC) is the baseline, but modern organisations are moving beyond it. If an auditor sees that a user has standing, 24/7 administrative access to a critical database, they are going to raise an eyebrow. You do not need admin rights while you are asleep.
The gold standard for Annex A 5.18 is Just-In-Time (JIT) Access and Attribute-Based Access Control (ABAC). Instead of granting permanent rights, users must request temporary elevation for a specific task. Furthermore, the system evaluates attributes like the user’s location, the time of day, and the security posture of their device before granting access. After a set period, the rights automatically expire. This drastically reduces your attack surface and proves to an auditor that you are strictly enforcing the principle of least privilege.
The Emergency “Break-Glass” Procedure
Your formal access request workflows are fantastic for day-to-day operations. But what happens at 3:00 AM on a Sunday when a ransomware attack takes down your primary IAM system and the service desk is offline? If your engineers cannot get the access rights they need to fix the issue because the “asset owner” is asleep, your business is in serious trouble.
Every robust Access Control Policy must include a documented “Break-Glass” procedure. These are highly privileged, emergency-only accounts that bypass standard approval workflows. To satisfy the auditor, these accounts must be locked down physically or cryptographically, and their use must trigger immediate, high-priority alerts to the security team and senior management. You must also prove that you test these emergency rights annually to ensure they work when you actually need them.
Cloud Infrastructure Entitlement Management (CIEM)
Managing access rights to a local file server is easy. Managing access rights in AWS, Azure, or Google Cloud is a nightmare of nested groups, inherited permissions, and inline policies. This is where most tech companies fail their Annex A 5.18 audit.
If you are fully cloud-native, you cannot rely on manual spreadsheet access reviews. You must use CIEM tools to continuously scan your cloud environments for toxic permission combinations and over-privileged roles. Auditors want to see that you have visibility into effective permissions. If a developer is assigned a role that technically allows them to delete a production database, even if they have never used that right, you are failing the control.
KPIs: Measuring the Effectiveness of Access Rights
You claim to have a perfect offboarding process, but how do you prove it is actually working month after month? You need quantifiable Key Performance Indicators (KPIs) to demonstrate proactive governance to the auditor.
- Leaver SLA Compliance: What percentage of terminated employees had their access completely revoked within your policy’s stated timeframe? The target must be 100%.
- Orphaned Account Ratio: During your quarterly access reviews, how many active accounts were found that do not belong to a current employee or a valid third party? The target must be zero.
- Privilege Reduction Rate: How many access rights were actively removed during your last review cycle because they were no longer needed? A number greater than zero proves your reviews are actually functioning, not just a rubber-stamping exercise by lazy managers.
Tackling Shadow IT and Unmanaged Applications
It is impossible to manage access rights for an application you do not know exists. If your marketing team signs up for a new SaaS tool using their corporate credit card and starts inviting users, your beautifully documented Access Control Policy is completely bypassed.
You must have technical controls in place to detect and restrict Shadow IT. This means using Cloud Access Security Brokers (CASB) or network monitoring to discover unapproved applications. Once discovered, they must either be blocked or formally brought into your IAM program so that access rights can be properly provisioned, reviewed, and revoked according to the strict requirements of Annex A 5.18.
Managing Non-Human Access Rights (Service Accounts)
When I audit Annex A 5.18, the very first place I look for a non-conformity is your service accounts. Organisations spend months perfecting their human HR offboarding process, but they completely ignore the machine identities. Service accounts, API keys, and system-to-system integrations have access rights too, and they are usually highly privileged.
A service account does not hand in a resignation letter, so it never triggers a “Leaver” process. If an IT admin leaves, the service accounts they created often sit dormant but active for years, acting as a massive backdoor for attackers.
- Assign a Human Owner: Every single service account and API key must have a documented human asset owner. When that human leaves, ownership of the service account rights must be formally transferred.
- Include in Periodic Reviews: Your quarterly User Access Reviews (UAR) must include a dedicated section for service accounts. The owner must justify why the machine still needs those specific permissions.
- Strict Least Privilege: Service accounts must be restricted to exact IP addresses or specific API endpoints. Never give a service account global administrative rights.
The Mover Handover Dilemma (Toxic Combinations)
We discussed the “Mover” process, but the real world is rarely a clean cut. When someone moves from Finance to Sales, they are often asked to “hand over” their old job for two weeks while starting their new one. For those two weeks, they hold the access rights of both roles.
This creates a massive Segregation of Duties (SoD) violation. They might have the rights to raise a purchase order (Sales) and approve that same purchase order (Finance). As an auditor, I will actively look for these toxic combinations during transition periods.
- Time-Bound Exceptions: If a user absolutely must retain old access rights during a handover, it must be logged as a formal, time-bound exception with a hard expiry date.
- Heightened Monitoring: During the handover period, the user’s activity in the legacy system must be actively monitored or counter-signed by their old manager to prevent fraud.
Physical Access Rights: Keys, Fobs, and Codes
A fatal mistake is thinking Annex A 5.18 only applies to IT systems and software. The standard explicitly states “information and other associated assets.” This includes physical filing cabinets, server rooms, and office buildings.
I will walk up to your receptionist and ask for an export of the active swipe card system. Then, I will compare it to HR’s list of terminated employees from the last six months. If I find a deactivated IT account but an active physical swipe card for a former employee, you have failed the control.
- Unified JML Process: Your Joiner, Mover, Leaver checklist must explicitly include the provisioning and revocation of physical keys, RFID fobs, and alarm codes.
- Physical Access Reviews: Just like software, physical access rights must be reviewed periodically. If you have a secure server room, the IT manager must regularly recertify who is on the approved access list.
Protecting the Audit Logs: Guarding the Guards
You need audit logs to prove that access rights were granted or revoked correctly. But what stops a rogue IT administrator from granting themselves unauthorised access to the CEO’s mailbox, reading the emails, and then deleting the access log to cover their tracks?
If the people who provision access rights also have the ability to alter or delete the audit logs, your entire access control framework is broken at the root.
- Immutable Logging: System logs detailing changes to access rights must be forwarded to a secure, centralised logging server (like a SIEM) where even the primary IT administrators only have read-only access.
- Alerting on Privilege Escalation: Any time a user is granted “Super Admin” or “Global Admin” rights, an automated alert must be sent to the CISO or a secondary security stakeholder for immediate verification.
Combating the “Rubber Stamp” Access Review
Auditors are not stupid. When you hand me a spreadsheet proving you did your quarterly User Access Review, I look at the timestamps. If a department manager reviewed and approved 300 different user permissions in four minutes, I know they just clicked “Approve All” without actually looking.
This is known as the “rubber stamp” problem, and it completely invalidates the effectiveness of Annex A 5.18.
- Micro-Certifications: Instead of hitting managers with a massive spreadsheet once a quarter, use IAM tools that ask them to recertify small batches of user rights continuously.
- Prove the Revocation: The best way to prove to an auditor that your access reviews are genuine is to show evidence of rights being removed as a result of the review. If nobody ever loses access during a review cycle, your process is not working.
The AI Copilot Nightmare: Weaponised Over-Privilege
Let me tell you the biggest disaster I am seeing right now with the rollout of tools like Microsoft 365 Copilot and enterprise LLMs. These AI assistants are designed to index and retrieve information across your entire environment. Crucially, they operate using the exact access rights of the user submitting the prompt.
If your Annex A 5.18 processes are weak and you suffer from “privilege creep”, AI will expose it instantly. A junior marketing executive might have retained access to a legacy SharePoint folder containing the company payroll from three years ago. Before AI, they probably did not even know that folder existed. Now, they can simply ask the Copilot, “What is the salary of the Sales Director?” and the AI will happily go find that file, read it, and hand over the answer.
- Clean Up Before You Roll Out: Before deploying any enterprise AI, you must conduct a ruthless User Access Review (UAR) to enforce the principle of least privilege. AI makes poorly managed access rights immediately exploitable.
- Test AI Boundaries: Auditors will want to see evidence that you have tested your AI tools to ensure they strictly honour your documented access rights and cannot bypass document-level security labels.
Access Rights to AI Training Data and Vector Databases
If your organisation is building its own AI models or using Retrieval-Augmented Generation (RAG) pipelines, you have entirely new classes of assets that require strict access rights management.
Who has the right to add data to the vector database that feeds your customer service chatbot? If a disgruntled employee with excessive access rights injects malicious or false data into the training pipeline, they can poison your AI model from the inside.
- Isolate Training Environments: Access to AI model weights, training datasets, and vector databases must be locked down using strict Role-Based Access Control (RBAC). Only designated data scientists or machine learning engineers should hold these rights.
- Segregation of AI Duties: The person who prepares the AI training data must not be the same person who holds the access rights to deploy the final model into the live production environment.
Using AI to Fix Access Rights: Identity Threat Detection
It is not all bad news. While AI exposes bad access management, it is also the ultimate tool for fixing it. Managing access rights at scale is practically impossible for humans to do perfectly. This is where AI-driven Identity Governance and Administration (IGA) comes in.
Instead of relying on managers to manually spot anomalies during a quarterly spreadsheet review, modern security teams use machine learning to highlight outlier permissions automatically.
- Automated Anomaly Detection: AI can look at a user in the Finance team and flag that they are the only person in that department holding access rights to the source code repository. The system will then automatically trigger a review request to the asset owner.
- Smart Recertification: Show the auditor that you are using AI to assist managers during access reviews. The AI can pre-approve standard baseline rights while flagging high-risk or unusual permissions for mandatory human scrutiny, completely eliminating the “rubber stamp” problem.
Federated Identity and B2B Partner Access
Modern businesses do not operate in a vacuum. You likely have partner organisations, joint ventures, or major enterprise clients who need access to your systems. To make this seamless, IT teams often set up Federated Identity (using protocols like SAML or OIDC), allowing the partner’s staff to log into your systems using their own company credentials.
Here is the audit trap: if a user at your partner organisation quits their job, how does your system know to revoke their access rights? You do not control their HR system.
- Federation Agreements: You must have a documented, legally binding agreement that dictates the partner organisation is responsible for disabling their leavers immediately.
- Just-In-Time Provisioning limits: When a federated user logs in, their access rights should be provisioned dynamically and set to expire automatically after a short session. If they are removed from their home directory, the subsequent login attempt to your system will fail.
- Cross-Tenant Access Reviews: Your quarterly User Access Reviews must explicitly include external guest accounts and federated partner roles. You must ask the partner organisation to formally attest that their list of active users is still accurate.
Granular Data Rights: Row-Level and Column-Level Security
Most compliance guides talk about access rights at the application level. They think that if John is allowed to log into the CRM, the control is satisfied. But what is John allowed to see once he is inside?
If John is a regional sales manager for the UK, he should not have the access rights to view the sales pipeline for the United States. If your database simply grants blanket “Read” access to everyone who logs in, you are violating the principle of least privilege.
- Row-Level Security (RLS): Show the auditor that your database architecture restricts access at the data row level based on the user’s attributes (like their region or department).
- Column-Level Masking: For highly sensitive data, implement column-level security. A customer support agent might need the access rights to view a client’s profile, but the system should dynamically mask the column containing the client’s full credit card number or national insurance number.
The MSP Trap: Auditing Your Outsourced IT
Many organisations outsource the operational execution of their access rights to a Managed Service Provider (MSP). When a new employee joins, HR sends a ticket to the MSP, and the MSP provisions the account.
As an auditor, I hear this excuse all the time: “We don’t manage the access rights, our IT company does that.” Let me be crystal clear: you can outsource the IT work, but you cannot outsource the compliance risk. You are the organisation getting certified, not your MSP.
- The Right to Audit: Your contract with the MSP must include a “Right to Audit” clause. You must be able to demand their provisioning logs to prove they are following your Access Control Policy.
- SLA Enforcement: If your policy states that a leaver’s access must be revoked within 24 hours, but your MSP’s Service Level Agreement only guarantees a 48-hour turnaround for standard tickets, you have a structural non-conformity. The MSP’s operational reality must perfectly align with your documented ISO 27001 rules.
- Dedicated MSP Admin Accounts: The engineers at your MSP must use named, dedicated administrator accounts when managing your environment. If the MSP uses a single shared “Admin” account to provision your users, you have no audit trail of which specific engineer granted the access rights.
The Birthright Access Matrix: Automation Without the Errors
In my 30 years of auditing, I have seen too many companies rely on manual tickets for every single permission. This leads to human error and inconsistent security. To pass your audit with flying colors, you should implement a Birthright Access Matrix.
A Birthright Matrix defines the baseline access every employee gets automatically based on their department or role. This is your “Day 1” configuration. By standardizing this, you prove to the auditor that your provisioning is consistent, repeatable, and governed by policy rather than the whims of an IT admin.
| Department | Baseline (Birthright) Systems | Permission Level | Approval Required? |
|---|---|---|---|
| All Staff | Email, Slack, HR Portal | Standard User | Automatic |
| Finance | Accounting Software, Finance Drive | Read Only | Automatic (Role Based) |
| Engineering | GitHub, AWS Sandbox, Jira | Contributor | Automatic (Role Based) |
The Leaver “Hidden” Risk: Shared Secrets
Most organizations remember to disable the user account, but they forget the shared secrets. If your Marketing Manager leaves and they knew the password to the corporate Twitter account or a shared admin login for a legacy tool, your security is still compromised.
ISO 27001 Annex A 5.18 requires the removal of access rights. Knowledge is access. If a leaver still knows a password, they still have access. Your leaver process must include a step to rotate any shared passwords or secrets the individual had access to. If you use a password manager, this is where you revoke their vault access and rotate any high risk credentials.
Preventing Fraud with the SoD Conflict Matrix
Auditors love to look for “Toxic Combinations.” This is where one person has enough power to commit fraud without being caught. For example, if the person who can create a new vendor in your system is the same person who can authorize a payment, you have a major security hole.
You need a Segregation of Duties (SoD) Conflict Matrix. This is a simple grid that identifies which roles are incompatible. When someone moves roles (a “Mover”), you check their new requested rights against this matrix to ensure you aren’t creating a toxic combination.
Stuart’s Pro Tip: If you must have a conflict due to a small team size, you must document a Compensating Control, such as an independent weekly review of all payments by the CEO.
The Auditor’s Trap: Negative Testing
When I audit your access rights, I don’t just look at who has access. I look for proof of who doesn’t. I will ask you to show me a leaver from three months ago and then ask you to attempt to log in as them. This is called Negative Testing.
To pass, you need to maintain the following evidence:
- The “Access Denied” Log: Evidence of someone attempting to use a revoked account and being blocked.
- Rejection Records: Prove that your Asset Owners actually say “No” sometimes. If 100 percent of requests are approved, the auditor will suspect a rubber stamp process.
- Out of Band Verification: Documentation showing that high risk access changes requested via chat or phone were verified through a second channel to prevent social engineering.
Frequency: Why “Once a Year” Might Fail You
Many people ask how often they should review access. The answer is found in your Risk Assessment. If you are reviewing access to your coffee machine logs once a year, that is fine. If you are reviewing access to your production database only once a year, you will likely get a non conformity.
Align your review frequency to the asset’s criticality:
- Critical Systems (PII, Financials, Code): Quarterly reviews.
- Privileged Accounts (Admins): Monthly or Quarterly reviews.
- Low Risk Systems (General Office Apps): Annual reviews.
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 and Further Reading
| Related ISO 27001 Control | Auditor’s Relationship Context |
|---|---|
| ISO 27001 Annex A 5.15 Access Control | This is the parent control. 5.15 sets the high-level rules and ‘Need to Know’ philosophy, while 5.18 is the operational execution of those rules at the individual permission level. |
| ISO 27001 Annex A 5.16 Identity Management | Identity is about ‘Who’ the person is. You cannot assign access rights in 5.18 until a unique identity has been formally established and verified under 5.16. |
| ISO 27001 Annex A 5.17 Authentication Information | Authentication is the process of proving that identity. Once a user proves who they are via 5.17 (passwords/MFA), 5.18 dictates what they are actually allowed to touch. |
| ISO 27001 Annex A 8.2 Privileged Access Rights | This is the high-risk sibling. While 5.18 manages standard user rights, 8.2 adds extra layers of scrutiny and protection for administrative and ‘super-user’ permissions. |
| ISO 27001 Annex A 8.3 Information Access Restriction | This control provides the technical ‘locks’ on the doors. It works with 5.18 to ensure that system settings actually block anyone who hasn’t been granted explicit rights. |
| ISO 27001 Annex A 5.18 Access Rights (Main Page) | The primary authority for the management of access lifecycle. This page serves as the source of truth for provisioning, reviewing, and revoking permissions. |
| ISO 27001 Annex A 7.2 Learning and Awareness | Rights are useless if people don’t respect the boundaries. 7.2 ensures that staff understand the responsibilities that come with their access rights and the consequences of misuse. |
| ISO 27001 Annex A 8.5 Secure Authentication Log-on | This relates to the point of entry. 8.5 secures the logon process itself, ensuring that access rights are only exercised in a safe and monitored technical environment. |
| ISO 27001 Annex A 5.33 Protection during Audit Testing | When auditors come to check your rights, 5.33 ensures they don’t get over-privileged access themselves that could compromise the integrity of your production data. |
| ISO 27001 Annex A 5.1 Policies for Information Security | The policy engine. Your access rights management framework must be explicitly authorised and governed by the top-level policies defined in Annex A 5.1. |
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
