ISO 27001 Annex A 5.18: access rights, joiners, movers and leavers

The due-diligence questionnaire asks you to reconcile leavers against live accounts. Your HR export shows six departures last quarter, and your identity provider still lists two of those people as active. ISO 27001 Annex A 5.18 is the control that turns that gap into a finding, and it is one of the most heavily sampled controls in any assessment.

This guide covers what the control requires, how to run joiners, movers and leavers as one workflow, how to run reviews that revoke, which evidence assessors sample, and how much you can automate. It is written for IT heads, security leads and compliance officers at 25–250-person firms who need to pass a Stage 2 audit without buying an enterprise identity platform.

What does ISO 27001:2022 Annex A 5.18 access rights require?

ISO/IEC 27001:2022 Annex A 5.18 access rights requires access to be granted only after the asset owner approves, adjusted when someone changes role, removed promptly when they leave, and checked again on a schedule in between. The control covers physical access such as badges as well as digital accounts, and it expects exit timing to reflect risk.

The control is preventive. Owner approval before a grant, expiry on temporary access and prompt removal at exit all close doors before anyone walks through them, while periodic review stops closed doors drifting open. The ISO/IEC 27001:2022 standard specification sets requirements for an ISMS that preserves confidentiality, integrity and availability through risk management, and an account with rights it shouldn't have can leak, corrupt or disable whatever it reaches.

Orphaned accounts are among the cheapest ways into a company. Leavers who are still live and contractors who were never switched off are the first thing a forensic report highlights after a breach. For a regulated firm, a departed employee keeping access to client data is reportable territory.

Exit judgement is where the control asks most of you. A badge is an access right as much as an admin role is, and a managed departure on bad terms carries a different risk from a friendly resignation. A disgruntled leaver with live admin rights is the incident scenario insurers ask about by name.

How does ISO 27001 A.5.18 differ from A.5.15 access control policy?

ISO 27001 A.5.18 is the operational process; A.5.15 is the rulebook. A.5.15 sets who may access what, while A.5.18 applies those rules across a person's whole tenure through grants, role changes, removals and reviews. An auditor reads your policy under A.5.15, then tests whether it operates under A.5.18.

Four neighbouring controls each own a slice of the lifecycle, so it helps to know where this page stops:

• A.5.15 Access control holds the rules for who may access what.
• A.5.16 Identity management supplies the identities that rights attach to.
• A.5.17 Authentication information covers the credentials those identities use.
• A.6.5 Responsibilities after termination or change of employment carries the employment-side duties that survive exit.

A.5.18 owns the running record between them: who approved, who changed, who removed and who reviewed. A policy line saying owners approve non-standard access proves nothing until a ticket shows an owner doing it.

Sequencing follows the same logic. With the A.5.15 policy and A.5.16 identities in place, standing up the lifecycle takes one to two weeks of workflow design and configuration. Nearly every technical Annex A control assumes it works, so schedule it early.

How do you run ISO 27001:2022 Annex A 5.18 access rights management from joiner to leaver?

Build joiner, mover and leaver handling as one workflow anchored to HR, not three ad-hoc habits. A starter triggers provisioning to a role profile, a mover has old rights removed before new ones are added, and a leaver is revoked the same day. The NCSC 10 Steps guidance expects an explicit joiners, movers and leavers policy.

The NCSC 10 Steps to Cyber Security: Identity and access management page frames the purpose plainly: access is revoked when no longer needed, or changed for movers. Here is the workflow we would put in front of a 50-person regulated firm:

1. Starter. Creating the HR record triggers provisioning to the role profile for that team. Anything beyond the profile waits for owner approval.
2. Mover. A role change triggers an adjustment that removes the old rights before adding the new ones.
3. Third parties. Contractor, supplier and project access gets an expiry date at creation and ends automatically. Extension needs a fresh approval.
4. Leaver. Disable access the same working day. For a management-initiated exit, or a leaver with reach into valuable data, pull rights at or before notification.
5. Physical layer. Badges, keys and tokens come back, and shared secrets the leaver knew get rotated.
6. Record. Log every grant, change and removal, and keep exceptions such as local accounts, SaaS outside SSO and door systems in the same picture.

If HR events don't reach IT automatically, the gap between the two teams is where your findings live.

Three habits undo this workflow in practice:

• Departures announced by corridor conversation, so revocation happens whenever somebody remembers.
• A contested dismissal treated exactly like a friendly resignation.
• Badges left active, keys unrecovered and server-room codes never changed.

"Within the month" reads as a finding, not a policy.

Why does cloning accounts cause privilege creep, and who should approve access?

Never clone an existing user's account: you inherit years of built-up rights nobody can explain. Grant from a small set of role profiles, have the asset owner approve anything beyond the standard profile, and keep the approver separate from the person who grants, so no single person controls a whole sensitive transaction.

Cloning copies history, not need. Every right the colleague has gathered transfers invisibly, and at review time nobody can say why the new starter holds it. Movers create the same problem from the other side: each role change adds rights, none removes them, until a five-year employee can touch everything.

A model that works for a 50-person firm:

• Role profiles. Define a small set by team or function, so the standard grant is identical every time.
• Asset owners. Name an owner for each key system and data set. They approve anything beyond the profile.
• Ticketed approval. The requester's manager or the asset owner approves in a ticket before the admin grants.
• Mover rule. Remove the old profile's rights before adding the new profile's.

Manager approval suits modest requests. Sensitive systems need the asset owner, because a manager may not know what a given right actually reaches.

Segregation of duties sounds like an enterprise concept, but it scales down to a single admin. When one person both receives the request and holds the admin rights, the ticket supplies the separation, because someone else says yes first. Approvals that live in chat messages or memory leave no trail an auditor can sample.

At this scale, five or six role profiles and a ticket template are hours of setup, and they are exactly what the auditor samples.

How do you run access reviews that actually revoke something?

Run reviews that change something: privileged accounts quarterly, standard access every six to twelve months, plus an ad-hoc check on any role change. The reviewer must understand the asset, and the record must show what was revoked, not just confirmed. The ICO expects regular review of access rights and adjustment when roles change.

The ICO Data Protection Audit Framework: Access control toolkit puts it in one line: review access rights regularly and adjust them if staff change role or responsibilities. Set the cadence by account type:

• Privileged accounts: quarterly.
• Standard access: every six to twelve months.
• Role changes: an ad-hoc check when someone moves.
• Third-party accounts: at expiry, with extension needing a fresh approval.

Choose reviewers who know what the access reaches. An owner clicking "approve all" is worse than no review.

A review that never revokes anything isn't a review. It certifies the drift.

A review record that survives sampling carries four things:

• A named reviewer and the review date.
• A decision against every line.
• The list of revocations flagged.
• Proof that those revocations happened.

Make the review cheap to run before you make it frequent. Show reviewers the changes since the last cycle and raise revocation tickets straight from their decisions. Then the reviewer's time goes on judgement, not on rebuilding the list.

What evidence will auditors and due-diligence assessors sample under A.5.18?

Auditors sample approval tickets against account creation dates, review records with proof that flagged revocations happened, HR leaver dates beside account disable timestamps, mover cases showing old entitlements removed, and role and owner definitions. Enterprise due-diligence teams run the same leaver reconciliation, so one evidence set serves both audiences.

Keep these artefacts ready, indexed by control:

• Access request tickets showing the owner's approval preceding the grant.
• Review records with named reviewers, dates, decisions per line and proof of revocations.
• HR departure dates beside account disable timestamps, plus signed returns for badges and tokens.
• Mover cases where old entitlements were removed, not just new ones added.
• The role profile definitions and asset-owner assignments the approvals rest on.
• Change logs from the identity platform and door-control system covering grants, changes and removals.

The leaver reconciliation shows quickly whether the management system operates or merely exists, so run it yourself each quarter, before an auditor or a customer does. A leaver still live in your own export is a ticket to close today. The same leaver in an assessor's sample is a finding.

What do auditors ask about A.5.18, and when is a finding major?

Expect to be asked to trace a leaver list from HR against live accounts, show approvals for recent accounts, and explain what happened to a mover's old access. Leavers with live access, reviews that never ran, or granting with no approval route grade major; a single late revocation or missing ticket grades minor.

These are the questions that tend to come up in the room:

• "Pick this system. Show me how someone gets access, who approved these three accounts, and where the tickets are."
• "Here is your HR leaver list for the last six months. Show me each account's disable date."
• "This person moved from support to engineering in April. What happened to their support-era access?"
• "Who ran your last access review, what did they revoke, and can you show me the revocations landing?"
• "Which contractor accounts are live right now, and when does each expire?"

The leaver reconciliation is near-universal. Auditors usually trace three to five departures end to end, physical badges included, then walk the privileged-account list line by line. They also follow one review cycle from launch to actioned revocations. Certification-body practice lets minor findings add up to a major when they form a pattern.

Three pitfalls generate most of the findings:

• The HR–IT gap surfaces as leavers with live access, the major-grade case.
• Open-ended contractor accounts surface when the auditor asks which are live and when each expires. This is one of the most common findings at this scale.
• Rubber-stamp reviews invite the question of whether a review ran at all, since none ever records a revocation.

How much of ISO 27001 Annex A 5.18 can you automate?

A.5.18 is one of the most automatable Annex A controls. The HR platform drives the identity provider, SCIM connectors sync entitlements to SaaS, review campaigns execute revocations directly, and scheduled jobs flag orphaned or dormant accounts. At 25–250 staff, your existing identity provider and a ticket workflow are enough; no enterprise governance platform is needed.

The payoff compounds across five layers:

• HR as the trigger. Starters are provisioned to their role profile, movers re-profiled and leavers disabled the same day, with timestamps generated as a by-product.
• Provisioning to the apps. SCIM or equivalent connectors push and pull entitlements, so the central record reflects reality instead of hopeful documentation.
• Review campaigns, not spreadsheets. The review runs inside the identity platform on schedule, shows reviewers the diff since last cycle, chases non-responders and executes revocations. Decision and action form one auditable loop.
• Orphan and dormancy detection. A scheduled job flags accounts with no matching active employee, no expiry or no recent login, and opens tickets automatically.
• Platform-enforced expiry. Third-party access is created with a mandatory end date, and extension needs a fresh approval.

Over-engineering is the opposite trap. A 40-person firm that buys enterprise identity-governance tooling, when a tight ticket workflow and a quarterly export would satisfy the control, has missed the point. Process discipline, not the platform, is what gets assessed.

At this scale, that setup satisfies auditors and enterprise customers while your team spends its time on exceptions rather than chasing spreadsheets.

Frequently asked questions