ISO 27001 Control 5.18: Access Rights

A contractor’s VPN credentials sit active for six months after the project ends. A developer accumulates admin privileges across three teams after two role changes. A terminated employee’s cloud account stays provisioned over a long weekend. These are not hypothetical — they are the access rights failures that Control 5.18 exists to prevent.

What 5.18 Requires

Control 5.18 requires organizations to implement a rigorous lifecycle process — as defined in ISO/IEC 27001:2022 — for the provisioning, regular review, modification, and removal of access rights, ensuring that permissions remain aligned with current role responsibilities and the access control policy.

In practice, that means building and operating a repeatable process across four stages:

1. Granting — Access rights are provisioned only after a formal request is approved by the asset owner, following rules defined in the access control policy (Control 5.15).
2. Reviewing — Existing access rights are periodically reviewed to confirm they remain appropriate for the user’s current role and responsibilities.
3. Modifying — When a user changes roles, transfers departments, or takes on new responsibilities, their access rights are adjusted to match — removing what is no longer needed, not just adding what is new.
4. Revoking — When a user leaves the organization, completes a contract, or no longer requires access, all associated rights are promptly removed.

The underlying principle is straightforward: without active management, access accumulates. Permissions drift is the default state in any organization. People change roles, projects end, and temporary access becomes permanent. 5.18 forces organizations to treat access rights as something that requires continuous governance, not a one-time provisioning event.

This control is the operational execution of the rules defined in Control 5.15 (Access Control Policy). Where 5.15 sets the policy, 5.18 ensures the policy is actually enforced through day-to-day processes. For a broader overview of the standard, see our guide to ISO 27001. The implementation details for all Annex A controls are further elaborated in ISO 27002.

Why 5.18 Matters

Organizations that fail to implement this control typically discover the gap the hard way. Consider a common scenario: a third-party contractor is brought in for a six-month infrastructure migration. They receive broad network access and credentials to multiple production systems. The project wraps up, the contractor moves on — but nobody revokes their access. Months later, those credentials are used to access sensitive data. The organization learns about it only after the damage is done.

This is not a fringe case. According to IBM’s 2024 Cost of a Data Breach Report, breaches involving stolen or compromised credentials took an average of 292 days to identify and contain — the longest lifecycle of any attack vector. When access rights are not actively managed, the window for exploitation is measured in months, not hours.

The average cost of a data breach in 2024 reached $4.88 million. A significant share of those breaches trace back to the same root cause: someone had access they should not have had, and nobody noticed.

Poor access rights management creates exposure across multiple threat categories:

• Unauthorized access — Former employees, expired contractors, or users with excessive permissions access systems or data they have no business reason to reach.
• Insider threat — Accumulated privileges give a single user the ability to cause disproportionate harm, whether intentional or accidental.
• Privilege escalation — Attackers who compromise one account can move laterally through the environment when that account has more permissions than its role requires.

What Attackers Exploit

The specific access rights failures that lead to breaches follow predictable patterns:

• Orphaned accounts — Accounts belonging to former employees or expired contractors that were never deprovisioned
• Privilege creep — Users who accumulate permissions across multiple role changes without ever having old permissions removed
• Missing approval workflows — Access granted informally, without asset owner authorization or documented justification
• Unmonitored privileged accounts — Administrator and service accounts that are never subject to periodic review (see privileged access management)
• Shared or generic accounts — Accounts used by multiple people, eliminating individual accountability and making forensic investigation nearly impossible
• Delayed revocation on termination — A gap between the HR event (termination, contract end) and the actual removal of system access

Each of these represents a control failure that 5.18 is designed to prevent. The control does not just require that access be managed — it requires that the management process be systematic, documented, and auditable.

The common thread across all of these attack vectors is time. The longer a stale permission, orphaned account, or excessive privilege remains in place, the greater the window of opportunity for exploitation. Effective access rights management compresses that window to as close to zero as possible.

How to Implement 5.18

For Your Organization (First-Party)

Implementation follows a logical sequence — use our ISO 27001 implementation checklist as a companion resource. Each step builds on the previous one:

Step 1: Define access rights in your access control policy. Before you can manage access rights, you need a policy that defines who can access what, under what conditions, and with what level of privilege. This is the domain of Control 5.15 — your access control policy is the foundation that 5.18 operationalizes. The policy should define role-based access templates, approval authorities for each system category, and the conditions under which temporary or emergency access can be granted.

Step 2: Establish a formal request-and-approval workflow. Every access request should follow a documented path: the user submits a request, the asset owner (not the user’s manager — the person responsible for the system or data) approves or denies it, and a provisioning team implements the change. No access should be granted without a recorded approval.

Step 3: Implement joiner/mover/leaver processes tied to HR events. Access provisioning and deprovisioning should be triggered by HR lifecycle events. When someone joins, they receive role-appropriate access based on their position and department — not a clone of a colleague’s account. When they move to a new role, old permissions are removed and new ones are granted simultaneously; the “mover” step is where most organizations fail, because removing old access requires coordination that adding new access does not. When they leave, all access is revoked. These processes must be formalized, not ad hoc.

Step 4: Enforce segregation of duties. The person requesting access, the person approving it, and the person provisioning it should be three different people. This prevents any single individual from granting themselves unauthorized access.

Step 5: Schedule periodic access reviews. Privileged accounts should be reviewed quarterly. Standard user accounts should be reviewed at least semi-annually. Reviews must be substantive — a reviewer who rubber-stamps a list of 500 users in ten minutes is not conducting a review.

Step 6: Automate where possible. Identity providers like Microsoft Entra ID or Okta, combined with SCIM provisioning, can automate much of the lifecycle. Automated deprovisioning on termination eliminates the gap between the HR event and access removal. Automation does not replace governance, but it reduces the window for human error.

Step 7: Log all access changes. Every grant, modification, and revocation should produce an auditable record — who requested it, who approved it, when it was implemented, and what changed. These logs are essential for both security monitoring and audit evidence.

Common mistakes to avoid:

• Cloning existing user accounts instead of provisioning from role-based templates — this copies accumulated permissions from one user to another
• No defined SLA for revocation after termination — access should be removed within hours, not days
• Reviewing access annually instead of quarterly for privileged accounts
• Treating access reviews as a checkbox exercise — reviews must result in actual changes, not just sign-offs
• No process for temporary or contractor access expiration — all non-permanent access should have a defined end date

For Your Vendors (Third-Party Assessment)

When assessing vendors against 5.18, focus on three areas: their process, their evidence, and their red flags.

Questions to include in security questionnaires:

• “Describe your access provisioning and deprovisioning process.”
• “What is your access review cadence for standard and privileged accounts?”
• “How do you handle contractor and temporary access, including automatic expiration?”

Evidence to request:

• The vendor’s access control policy
• Sample access review records (redacted as needed) showing reviewer decisions
• System logs demonstrating revocation timelines — specifically, the elapsed time between a termination event and access removal

Red flags that indicate weak controls:

• No formal access review process or documentation
• Annual-only reviews for all account types, including privileged accounts
• No automated deprovisioning capability
• Inability to produce revocation timestamps or approval records

Do not rely solely on self-attestation. Request screenshots of the vendor’s access review tool, or ask for the relevant sections of their SOC 2 Type II report covering the CC6.x trust services criteria for logical and physical access controls. For more on evaluating vendors against ISO standards, see meeting the third-party risk requirements of ISO 27001.

Audit Evidence for 5.18

Auditors assessing 5.18 expect specific, documented artifacts — not generic references to “access management documentation.” For a broader view of what to expect, see our guide to ISO 27001 audits. The table below lists the evidence types and concrete examples of what to produce:

Produce these artifacts continuously, not just before an audit. If you are assembling evidence retroactively, your process is not operating as 5.18 requires. Auditors are specifically trained to distinguish between documentation produced as a byproduct of a functioning process and documentation created after the fact to satisfy a checklist.

Cross-Framework Mapping

Control 5.18 maps to equivalent access management controls across major compliance frameworks:

Organizations subject to multiple frameworks can use a single access rights management process to satisfy 5.18 and its equivalents, provided the process meets the most stringent requirements across all applicable standards. In practice, NIST 800-53 AC-02 is the most prescriptive of these mappings, so an implementation that satisfies AC-02 will generally cover the others. The NIST 800-53 AC-02 mapping is sourced from the official NIST OLIR (Online Informative References) crosswalk.

Related ISO 27001 Controls

Control 5.18 does not operate in isolation. It connects to a network of controls that collectively govern identity and access management:

Frequently Asked Questions

What is ISO 27001 5.18?

ISO 27001 Control 5.18 (Access Rights) is an organizational control that requires organizations to manage the full lifecycle of user access rights — from initial provisioning through periodic review, modification on role change, and revocation on departure. It ensures that every user’s permissions remain aligned with their current responsibilities and the organization’s access control policy.

What happens if 5.18 is not implemented?

Without a functioning access rights lifecycle, organizations accumulate orphaned accounts, unchecked privilege creep, and stale permissions that create direct pathways for unauthorized access. Breaches involving compromised credentials are among the most costly and take the longest to detect — an average of 292 days according to IBM’s 2024 research. Beyond breach risk, failure to implement 5.18 will result in a nonconformity during ISO 27001 certification audits.

How do you audit 5.18?

Auditing 5.18 involves verifying that a documented access rights process exists and is operating effectively. Auditors will sample access request records to confirm asset owner approvals, review access review logs to verify periodic reviews are occurring at the required cadence, check revocation records against HR termination dates to measure deprovisioning speed, and test segregation of duties by examining whether the same individual can request and approve their own access. The audit focuses on evidence of ongoing operation, not just the existence of a policy document.

How UpGuard Helps

Managing access rights across your organization and vendor ecosystem requires visibility that spreadsheets and manual reviews cannot provide. UpGuard User Risk continuously monitors user access patterns, identifies excessive permissions, and flags access anomalies across your environment — helping you maintain the lifecycle governance that Control 5.18 demands. Explore UpGuard User Risk →