ISO/IEC 27001:2022 · derived mapping target
A.5.18Access rights
Provision, review and revoke access rights in line with your access policy, especially when people change roles or leave. Regular reviews catch access that should have been removed.
Mapping at a glance
A.5.18Access rightsISO/IEC 27001:2022
RCF-0027Third-party risk managementGovernance & Risk · TechnicalRCF-0062Identity lifecycleIdentity & Access Management · ProcessRCF-0063Identity lifecycleIdentity & Access Management · TechnicalRCF-0067Least privilege / RBACIdentity & Access Management · PolicyRCF-0068Least privilege / RBACIdentity & Access Management · Process
A.5.18 is covered by 18 Sekit CSF controls. +13 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0027Third-party risk management · TechnicalsupportsGiving third parties named, individually attributable accounts with logged, reviewed access is A.5.18's provisioning and review discipline applied to non-employee access rights.RCF-0062Identity lifecycle · ProcesssupportsRunning onboarding and offboarding from a repeatable checklist is how access rights get granted and revoked on schedule, the operational side of A.5.18.RCF-0063Identity lifecycle · TechnicalsupportsAutomatic revocation everywhere once a person is disabled centrally closes the gap between deciding to remove access rights and them being removed.RCF-0067Least privilege / RBAC · PolicysupportsDefining the access each role needs and granting from that definition rather than copying a colleague supports A.5.18's provisioning step, though the review and revocation legs the control also requires sit with other Sekit controls.RCF-0068Least privilege / RBAC · ProcessequivalentGranting strictly from the role definition, adjusting on role change and stripping unneeded access on review is A.5.18 in full: provision, review, revoke, tied to the access policy.RCF-0085Access reviews (recertification) · PolicysupportsCommitting in writing to a periodic access review, naming who reviews and the removal deadline, supports A.5.18's review step, though provisioning and revocation are covered by other Sekit controls.RCF-0086Access reviews (recertification) · ProcesssupportsManagers confirming access against current duties, with IT removing what is flagged inside the agreed deadline, is what makes the access review requirement real rather than a calendar entry.RCF-0087Access reviews (recertification) · TechnicalsupportsPulling access listings directly from identity provider exports and per-application reports means the review checks what access exists, not what someone remembers granting.RCF-0088JML (joiner-mover-leaver) · PolicysupportsNaming who triggers each joiner, mover and leaver event gives A.5.18's access rights process a defined starting point instead of relying on informal notice.RCF-0089JML (joiner-mover-leaver) · ProcesssupportsExecuting the joiner-mover-leaver flow reliably, so IT hears about every departure in time, is what stops A.5.18's revocation deadline from being missed in practice.RCF-0090JML (joiner-mover-leaver) · TechnicalsupportsConnecting HR to the identity provider so leaver events disable accounts automatically removes the manual relay step where A.5.18 revocations most often slip.RCF-0167Local admin control · ProcessrelatedKeeping the local admin list approved and current is A.5.18's provisioning-and-review discipline applied to one specific, high-impact access right rather than access rights generally.RCF-0185Zero Trust network access · ProcessrelatedReviewing conditional access rules and their exceptions periodically is a related check on standing access decisions, adjacent to A.5.18's broader access rights review requirement.RCF-0188VPN management · ProcesssupportsGranting VPN access only on approval and removing it the day someone leaves is A.5.18's provisioning and revocation requirement applied to remote network access specifically.RCF-0299Facility access control · ProcessrelatedReviewing who holds keys, badges and alarm codes and revoking them the same day someone leaves mirrors A.5.18's principle for physical rather than system access rights.RCF-0326Offboarding vendors · ProcesssupportsExecuting the vendor exit checklist so no account or API key survives termination is A.5.18's revocation requirement applied to supplier access rights.RCF-0327Offboarding vendors · TechnicalsupportsAutomating supplier access revocation and technically confirming nothing residual remains closes the same gap A.5.18 targets for employee offboarding, applied to vendors.RCF-0335Cloud IAM · ProcesssupportsReviewing cloud access rights on a recurring cycle and trimming what exceeds a person's role is A.5.18's access review requirement carried into cloud platforms.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Joiner-mover-leaver procedure
The process the company follows when someone joins, changes role, or leaves: how access and devices are granted and removed.
From the Sekit evidence catalog
In practice
This control is where access control theory meets the calendar: a periodic access review, usually quarterly, where managers confirm each team member's access still matches their current job. Auditors ask for the last completed review cycle and check whether flagged access was removed within the stated deadline, not only flagged and left open. The most common gap traces back to the joiner-mover-leaver procedure: a mover event, someone changing teams internally, that only strips old access when the review catches it months later, rather than at the moment the role changed.
Common gaps
The last completed access review flagged several accounts for removal, but the deadline passed and the access is still active with no record of why.
Internal role changes, movers rather than leavers, are not treated as a trigger for an access review, so old permissions accumulate quietly over a person's tenure.
The access review relies on managers recalling each team member's permissions from memory rather than a pulled listing from the identity provider.
Questions your auditor will ask
How often is access reviewed, and who is responsible for it?
Reference the periodic access review commitment, naming the reviewing managers, the review cadence and the removal deadline for flagged access.
What happens when the review flags access that should be removed?
Show the last completed review's flagged items alongside evidence, such as removal tickets or identity provider logs, that the access was revoked within the deadline.
How is access listed for review generated, from memory or from the system?
Point to the identity provider exports and per-application permission reports pulled directly from the systems rather than reconstructed by a manager's recollection.
Where regulation demands it
NIS2 art. 11.2 (Management of access rights) requires the same provisioning-review-revoke cycle A.5.18 describes.
ENS op.acc.4 (Proceso de gestión de derechos de acceso) is Spain's equivalent for the access rights management process.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.18?”
Also via MCP, free with account