Control Definition
Access rights to information and other associated assets must follow a managed lifecycle — granted only with proper authorization, adjusted when roles or needs change, reviewed at intervals, and withdrawn when no longer required — all in line with the organization's access control policy and rules.
Control Objective
To keep the access each identity actually holds matched to current business need — granted on authorization, adjusted as roles change, and removed the moment the need ends.
What This Really Means
Anyone can grant access; the control is the lifecycle. The set of rights in your estate starts drifting from business need the moment it is granted — people join, change roles, pick up projects, and leave, while their entitlements quietly stay behind. A.5.18 is the discipline that keeps the drift in check, and it closes the four-control chain: A.5.15 wrote the rules, A.5.16 established the identities, A.5.17 secured their secrets — A.5.18 is where rights are actually granted, reviewed, and taken away.
The operational skeleton is joiner-mover-leaver. Joiners get access through a workflow: a request with justification, approval from the asset or information owner (not from IT on its own authority), and provisioning by a third party so requester, approver, and provisioner stay separated per A.5.3 — with role-based birthright bundles covering the standard grants automatically. Movers are the dangerous population, because access is additive by default: the transfer into a new role adds entitlements and removes none, so the control expects a re-baselining step that strips the old role bundle rather than stacking it. Leavers get revocation to a defined SLA — same business day is the common bar, immediate for high-risk exits — executed against a checklist that covers the directory, SSO applications, the non-federated SaaS tail, VPN, badges, tokens, and shared mailboxes.
Between lifecycle events sit periodic access reviews, and the standard expectation in practice is quarterly for privileged access and semiannual for standard access. A real review exports actual entitlements, puts them in front of the asset owner with context — role, grant date, last use — records a keep-or-revoke decision per line, and tracks flagged removals to closure within an SLA. A review that never revokes anything across cycles is not cleanliness; it is a rubber stamp, and auditors read it as one.
The heart of this control at audit is sampling. Auditors take recent leavers from HR and reconcile termination dates against revocation timestamps; they pull grants and trace each back to an owner approval; they take a completed review and check that flagged access actually disappeared from the live system. A.5.18 is won or lost on whether the trail exists — request, approval, grant, review, decision, removal — for every right they happen to pick.
Why It Matters
Every excess entitlement is pre-positioned breach impact. When an account is phished, the blast radius is exactly the set of rights it holds — so stale grants, accumulated mover access, and unrevoked leaver accounts convert directly into incident scope, notification duties, and recovery cost. Departed employees retaining live access is one of the most persistent insider-incident patterns there is, and it is almost always a process failure rather than a technology one: the termination simply never reached the people who run revocation.
This control is also where A.5.15 becomes testable. The access policy declares need-to-know; the provisioning trail, review records, and revocation timestamps are the only evidence that the declaration describes reality. Certification auditors sample here heavily because the artifacts are objective, and customer due-diligence teams do the same — access review evidence is now a standing request in enterprise security questionnaires.
When the rights lifecycle breaks down, the failures are predictable:
- •Ex-employees with live access – revocation gaps turn ordinary departures into insider incidents and reportable breaches
- •Privilege creep – movers accumulate the union of every role they ever held, making tenure itself a risk factor
- •Rubber-stamp reviews – attestation without revocation gives false assurance and collapses under audit sampling
- •Grants without owners – when IT approves on its own authority, nobody with business context ever authorized the access
- •Inflated blast radius – one compromised account exposes everything its excess rights reach, multiplying incident scope and cost
Regional Compliance Context
For RBI-regulated entities and SEBI-registered intermediaries in India, periodic user access recertification is a supervisory expectation, not just an ISO practice — inspections routinely request access review evidence and probe revocation timelines for leavers, so the artifacts this control produces serve both audiences. For any organization processing personal data in India, demonstrable access limitation and prompt revocation form part of the reasonable security safeguards the DPDP Act 2023 expects, with full compliance obligations landing on 13 May 2027.
Implementation Guidance
Define the Provisioning Workflow Against the Access Policy
Route every grant through a workflow derived from A.5.15: a request with business justification, approval by the asset or information owner, and provisioning by someone other than the requester or approver, per A.5.3. Run it through a ticketing system so each grant carries a requester, an approver, a justification, and a date — that record is the unit of evidence auditors will sample.
Establish Role-Based Birthright Bundles for Joiners
Define the default entitlements per role once, have the relevant owners approve each bundle, and let the HR feed grant it automatically at onboarding. Everything beyond birthright requires an individual request and owner approval. This keeps day-one productivity without day-one over-provisioning, and it gives reviews a baseline to compare reality against.
Re-Baseline Access on Every Internal Move
Treat a transfer as leave-and-rejoin for entitlements: remove the old role bundle within a defined window, grant the new one, and require fresh owner approval for anything carried across. The manager and receiving asset owners confirm residual needs explicitly. Movers are where privilege creep is born — an additive-only process guarantees long-tenured staff end up holding the union of every job they ever did.
Enforce Leaver Revocation to a Defined SLA
Set the bar — same business day is common practice, immediate and pre-coordinated for terminations for cause — and execute against a leaver checklist spanning the directory, SSO applications, non-federated SaaS, VPN, badges, hardware tokens, and shared mailbox access. Verify completion rather than initiation: a ticket closed is not an account disabled. Reconcile weekly against HR as the safety net.
Run Access Reviews That Produce Decisions
Schedule quarterly reviews for privileged access and semiannual for standard access, with asset owners — not IT alone — as reviewers. Export the actual entitlements, present them with context (role, grant date, last use), require an explicit keep-or-revoke decision per line, and execute revocations within a defined SLA with closure tracked. Retain the full campaign record; it is the single most requested artifact under this control.
Time-Bound Exceptional and Temporary Access
Give every project grant, contractor right, and emergency elevation an expiry date at creation, enforced by automatic disablement in the identity provider or PAM tool where possible. Send owners a monthly expiry report, make renewal an active decision with justification, and read repeated renewals as a signal that the underlying role definition needs updating.
Automate With IGA Where Scale Demands It
Identity governance tooling earns its cost when manual completeness fails: automated joiner-mover-leaver flows, SCIM provisioning into SaaS, and review campaigns with system-recorded attestations. Below that scale, a role matrix in a spreadsheet, a ticketing workflow, and calendar-driven reviews pass audits comfortably — auditors test completeness and follow-through, not the logo on the tool.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.18:
Documentation
- Sampled access request tickets showing requester, business justification, asset-owner approval, and provisioning date
- Access review campaign records: scope, reviewers, per-line decisions, revocations executed, and remediation closed
- Leaver checklists with revocation timestamps reconciled against HR termination dates
- Exception and temporary access register showing expiry dates and disablement evidence
- Role-to-entitlement matrix or birthright definitions with owner approval of each bundle
Interviews
- IAM or IT administrator on how joiner, mover, and leaver events execute in practice and what SLAs apply
- An asset or information owner on how they conduct access reviews and what they actually revoked in the last cycle
- HR representative on how termination and transfer events are communicated to IT — probing the reliability of the trigger
Observations
- A recent leaver traced live across the directory, SSO portal, and key non-federated applications to confirm revocation
- A completed review record reconciled against current live entitlements to confirm flagged access was actually removed
- A sampled mover's current rights compared against their new role definition to test for residual access from the old one
Practitioner Insights
Review records are the first place I look, and I read them across cycles, not in isolation. When three consecutive quarterly campaigns in a growing company revoke nothing at all, that is not hygiene — that is reviewers bulk-approving to clear a task. I then sample five users myself against their role definitions, and the gap usually appears within minutes. A review is evidence only when it records decisions: who looked, what they compared against, what they removed, and when the removal closed.
Everyone obsesses over leavers, but movers are the quiet failure in most smaller organizations. Leavers get caught eventually because payroll stops; the support engineer who moved into development keeps admin on the ticketing system for years, and nobody ever asks why. The cheapest fix I know is to treat every internal transfer as a leave-and-rejoin for entitlements — strip to the new role bundle, regrant on fresh approval. It feels heavy-handed for about a week and then becomes the routine that stops creep from ever starting.
Common Challenges & Solutions
Challenge
Terminations reach IT late or informally, so accounts outlive employees by days or weeks.
Solution
Wire the trigger to the system of record: an HRIS integration that disables access on the termination date without human relay. Where integration is not yet possible, set a binding same-day notification rule from HR with a named owner, and run a weekly HR-to-directory reconciliation as the net that catches what the process drops. Measure termination-to-revocation lag as a standing metric.
Challenge
Access reviews arrive as thousand-row spreadsheets that owners approve wholesale just to be done.
Solution
Shrink the decision surface: split campaigns per system or per team, show each entitlement with context — role, grant date, last use — and require an explicit keep-or-revoke decision per line. Track revocation rate as a health metric; a campaign that converges on zero across several cycles is telling you the review has become ritual, not assurance.
Challenge
People who change roles internally keep their old entitlements, and tenure quietly becomes privilege.
Solution
Make re-baselining a standard step of every transfer: HR flags the move, the old role bundle is removed within a defined window, the new bundle is granted, and any carry-over needs fresh owner approval. IGA policies can swap bundles automatically; smaller teams achieve the same with a mover checklist that mirrors the leaver one.
Challenge
A long tail of SaaS applications sits outside SSO, so provisioning and revocation miss them entirely.
Solution
Adopt an SSO-first procurement rule so the tail stops growing, inventory the existing exceptions with a named owner per application, and add the highest-risk ones explicitly to the leaver checklist and review scope. For the remainder, a quarterly owner-led reconciliation of application accounts against HR records is the pragmatic floor.
Challenge
Temporary access for projects, support escalations, and contractors never gets removed when the need ends.
Solution
Refuse open-ended grants: every exceptional access carries an expiry date at creation, enforced by automatic disablement where the platform allows. Send owners a monthly report of upcoming and lapsed expiries, make renewal an explicit decision with justification, and treat a grant renewed three times as a sign the role definition itself needs changing.
