ISO 27001 A.5.18: Access Rights

ISO 27001 A.5.18 requires that access rights to information and systems are provisioned, reviewed, modified, and removed across the whole lifecycle, in line with the access control policy. It is an Organizational control (A.5), and the action teams get flagged on most is the one that has no natural trigger: the periodic access review that catches standing access nobody can tie to a current need.

What is ISO 27001 A.5.18?

ISO 27001 A.5.18 Access rights is the lifecycle control for access across the ISMS. ISO/IEC 27001:2022, Annex A frames it around provisioning, reviewing, modifying, and removing access rights to information and other associated assets, in accordance with the organization's access control policy. It is the control that governs what happens to an access grant from the day it is requested to the day it is removed.

A.5.18 is where the rules written in the access control policy become dated records: an authorized request that grants access, a review that reconfirms or trims it, a change that follows a role move, and a revocation that follows a termination. A.5.15 states what appropriate access means; A.5.18 is the operating loop that keeps live access matched to that definition over time. The single mechanism that makes the loop work is the periodic access review, because provisioning and revocation each have an obvious trigger while standing access drifts unless someone deliberately re-examines it.

How do you implement A.5.18?

Implement A.5.18 by running access as a closed loop with four operations: provision, review, modify, revoke. Each operation produces a dated record. The sequence a team runs:

1. Provision access from an authorized request tied to a role. Access is granted only after a request that names the requester, the role or system, the business justification, and an approver. Map the grant to a defined role so the access is a known bundle rather than an ad hoc set of permissions.
2. Apply least privilege at the point of grant. Give the access the role requires and nothing broader. A grant that starts minimal is far easier to review later than one that starts generous and has to be walked back.
3. Run periodic access reviews with keep, modify, or remove decisions. On a defined cadence, the owner of each system or dataset reviews who holds access and records a decision for every account: keep it, reduce it, or remove it. This recertification is the control that catches access no one requested to remove and no one can justify keeping.
4. Modify access promptly on role change. When a person changes teams or duties, add the access the new role needs and remove the access the old role no longer justifies. Role changes are where access typically accumulates, because the new access gets added and the old access gets forgotten.
5. Revoke access promptly on termination. When a person leaves, disable their accounts and revoke their access on a defined timeline tied to the departure rather than on the next review cycle. Termination is the highest-risk moment for access, since the person no longer has a business need but the credentials still work.
6. Remove standing and stale access. Access granted for a project, a temporary elevation, or a one-time need should have a removal step. Where the access has no natural end date, the periodic review is the backstop that retires it.
7. Give privileged rights extra scrutiny in the lifecycle. Elevated access follows the same provision-review-modify-revoke loop, but on a tighter cadence and with closer review, because the impact of a stale privileged grant is larger. The mechanism controls for privileged access sit in A.8.2.

In cloud environments

Cloud environments run the A.5.18 lifecycle through the identity provider and its group memberships, so a review or a departure updates access in one place:

• Access as IdP group membership. Provisioning and modification are group changes in the identity provider (Okta, Entra ID, Google Workspace), and a role move is a group swap that both adds and removes access in one action.
• Access-review campaigns. The identity platform or the GRC tool runs scheduled recertification campaigns that route each user's access to the right reviewer and capture the keep, modify, or remove decision as evidence. Wiring that recertification evidence into the platform so it collects itself each cycle is an example of GRC engineering.
• SCIM deprovisioning on termination. Disabling the identity in the IdP flows through SCIM to downstream applications, so revocation is fast and evidenced from a single event rather than chased app by app.
• Requests through a documented workflow. Access requests run through a ticketing or IdP request flow that captures the requester, approver, and justification the lifecycle needs.

On-prem / self-hosted

On-prem environments run the same lifecycle through the directory, with removal often triggered from HR rather than a platform event. The SOC 2 access control on-prem guide covers the implementation in depth; the shape is:

• AD group membership as the access grant. Provisioning, modification, and removal are Active Directory group changes, and the group memberships are what a review recertifies.
• Recertification of directory groups. The periodic access review walks each privileged and sensitive AD group, confirms every member still needs it, and records the decision, since there is no automated campaign to route it.
• HR-triggered removal. A defined handoff from HR to IT starts the revocation on the departure date, because a self-hosted environment has no identity-provider event to fire deprovisioning automatically.
• A written removal timeline. Because enforcement spans heterogeneous systems, the process names the timeline and the owner for disabling accounts on termination so nothing is left to the next review.

Cloud vs on-prem at a glance

What evidence demonstrates A.5.18?

Evidence for A.5.18 is the record that access is granted deliberately, reviewed on a cadence, and removed on time, across the full lifecycle.

How does A.5.18 map to SOC 2?

A.5.18 is a Full overlap with SOC 2 CC6.2 and CC6.3. Organizations with an existing SOC 2 program can reuse their provisioning records, access review reports, and deprovisioning evidence for the ISO 27001 certification audit without adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk and where the same access lifecycle evidence transfers between the two frameworks.

Related controls

A.5.18 is the lifecycle that carries out the access control policy; the controls around it define the rules, the identities, and the elevated case. A.5.15 access control sets the policy A.5.18 provisions and revokes against, and A.5.16 identity management manages the identities those access rights attach to. A.8.2 privileged access rights is the mechanism for the elevated access that runs through the same lifecycle on a tighter cadence, and A.6.5 responsibilities after termination or change of employment covers the people-side obligations that the termination removal step depends on. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Frequently Asked Questions

What is ISO 27001 A.5.18?

ISO 27001 A.5.18 Access rights is an Organizational control in Annex A of ISO/IEC 27001:2022. It requires that access rights to information and systems are provisioned, reviewed, modified, and removed across their whole lifecycle, in accordance with the access control policy. It is the operating loop that keeps live access matched to what each person's role justifies, from the authorized request that grants access to the revocation that removes it.

What evidence satisfies A.5.18?

A.5.18 evidence shows access is granted deliberately, reviewed on a cadence, and removed on time. Auditors expect access request and approval records tied to a role and justification, periodic access review records with keep, modify, or remove decisions, termination deprovisioning records with timing, and role-change access modifications. Privileged access review records on a tighter cadence support the elevated portion of the lifecycle.

How often should access be reviewed?

Access is commonly reviewed quarterly or semi-annually for general access, and quarterly or more often for privileged access, though ISO 27001 sets no fixed interval. The cadence should be defined in the access control policy and matched to risk: higher-impact systems and elevated rights get reviewed more frequently. What matters to an auditor is that the review runs on a stated schedule and produces a recorded keep, modify, or remove decision for every account.

What is the difference between A.5.18 and A.5.15?

A.5.15 is the policy control: it establishes the rules for access, including least privilege, need-to-know, and role-based access. A.5.18 is the lifecycle control: it provisions, reviews, modifies, and revokes access rights in line with that policy. A.5.15 defines what appropriate access means; A.5.18 grants, maintains, and removes it over time.

Is A.5.18 a new control in ISO 27001:2022?

No. A.5.18 is not new to the 2022 revision. It merges three controls from the 2013 version, A.9.2.2 (user access provisioning), A.9.2.5 (review of user access rights), and A.9.2.6 (removal or adjustment of access rights), into a single Organizational control that covers the full access lifecycle.

What is the difference between A.5.18 and A.8.2?

A.5.18 governs the lifecycle of all access rights: provisioning, review, modification, and removal for every user and system. A.8.2 Privileged access rights is the more specific control for elevated access such as administrator and root accounts, which runs through the same lifecycle but on a tighter cadence and with closer scrutiny. A.5.18 is the general lifecycle; A.8.2 is the elevated case with extra controls on allocation and review.