ISO 27001 A.5.18: Access Rights

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.18 requires that access rights to information and other associated assets be provisioned, reviewed, modified and removed in line with your access control policy, so that every identity holds exactly the access its role justifies, no more, and only for as long as needed.

The Bottom Line: Identity management (5.16) decides who exists; access rights (5.18) decide what they can touch. This is where least privilege lives or dies. Over-grant and every compromised account becomes a catastrophe; review and revoke diligently and you contain the blast radius of every incident.

What the Standard Actually Requires

The ISO 27001:2022 Text

Annex A 5.18 states:

ISO 27001:2022 Annex A 5.18 asks organizations to provision, review, modify, and remove access rights in line with the access control policy.

Four verbs, provision, review, modify, remove, define a complete lifecycle for entitlements (distinct from the identity lifecycle in 5.16).

What ISO 27002:2022 Adds

The implementation guidance requires the provisioning/revocation process to include:

• (a) Owner authorisation. Obtain authorisation from the owner of the information/asset (see 5.9) for its use; separate management approval may also be appropriate.
• (b) Business need + policy. Base access on business requirements and your topic-specific access control policy and rules.
• (c) Segregation of duties. Separate the roles of approving and implementing access; separate conflicting roles (see 5.3).
• (d) Timely removal. Remove access when no longer needed, especially removing leavers' access promptly.
• (e) Temporary access. Consider time-limited access with an expiry, especially for temporary personnel or temporary needs.
• (f) Verify the level. Confirm the access granted matches the access control policy (5.15) and other requirements such as SoD (5.3).
• (g) Activate only after authorisation. Ensure access rights are activated only after authorisation is complete (relevant when service providers implement access).

The standard also requires regular review of access rights, including after any change (role change, promotion, transfer, termination) and for privileged access more frequently, and that records of provisioning and revocation are kept.

The "shall vs should" Analysis

What Auditors Actually Check

1. Access request and approval records, who authorised this access and on what basis?
2. Owner authorisation, did the information/asset owner sign off?
3. Leaver access removal, sample leavers; was access revoked to SLA?
4. Access reviews/recertification, evidence of periodic review with revocations actually executed.
5. Segregation of duties, approver ≠ implementer; no toxic role combinations.
6. Privileged access, tighter controls and more frequent review for admins.

Why Access Rights Matter

The Business Risk Narrative

Most damaging breaches are not about getting in, they are about how far the attacker could go once in. That blast radius is governed almost entirely by access rights. An employee who accumulated entitlements across five role changes, an admin account used for daily work, a contractor who kept access after the project ended, each converts a minor compromise into a major one. Access rights are the control that decides whether one phished password becomes a contained incident or a company-ending breach.

Access-Related Statistics

Indian Regulatory Context

• DPDP Act 2023: Access to personal data must be need-to-know and authorised; a Data Fiduciary's "reasonable security safeguards" (Section 8(5)) explicitly include access control. Over-broad access to personal data is a safeguard failure, with penalty exposure up to .
• RBI Cyber Security Framework & Master Directions: Mandate role-based access, least privilege, maker-checker segregation of duties, periodic access recertification, and prompt removal on exit. RBI IT inspections sample access grants and review evidence.
• SEBI CSCRF (2024): Requires access governance, least privilege and periodic recertification for market entities.
• IRDAI Guidelines: Access on need-to-know, removal on separation, periodic review.
• CERT-In Directions (2022): Access records support incident attribution within the 6-hour window.
• IT Act, 2000: Section 43A (prior to DPDP) and Section 72A (disclosure in breach of contract) reinforce controlling who can access data.

Industry-Specific Consequences

impact of Non-Compliance

Over-provisioned access is the multiplier on every other failure. A single account with excessive rights turns ransomware from "one endpoint" into "the whole estate," and turns a curious insider into a data-exfiltration event. The fix, least privilege, owner-authorised grants, and periodic recertification, is process-heavy but technology-light, making A.5.18 one of the highest-ROI controls you can mature.

Anatomy of an Access-Driven Breach

The pattern that A.5.18 failures enable, step by step:

1. Over-grant at joining: A new analyst is copied from a colleague's profile ("give them the same access as Priya"), inheriting entitlements they will never use. Least privilege is breached on day one.
2. Privilege creep: Over three years and two role changes, access is added each time but never removed, the analyst now holds finance, HR, and reporting access (failure of 27002 (d) on modify/remove).
3. The compromise: The analyst is phished. The attacker now holds the union of three roles' access.
4. Lateral movement: Because there was no segregation of duties (27002 (c)/(f)), the single identity can both create a vendor and approve a payment, enabling fraud, or in another scenario, exfiltrate data across three departments.
5. No detection: No access reviews ever ran, so the accumulated, unused access was never caught (failure of "review").
6. The aftermath: Investigation is slow because the breach touched far more than one role's data; DPDP and CERT-In obligations are triggered across multiple data sets.

Every step maps to a 5.18 verb: provision (least privilege at joining), modify (remove on role change), review (catch the accumulation), and the SoD constraint that would have prevented the toxic combination. Diligent access-rights management collapses this scenario at step 1.

Access-First Security and Zero Trust

In a Zero Trust model, every request is authorised per-session against least-privilege policy, which is precisely A.5.18 operating continuously. The strategic goal is near-zero standing privilege: identities hold little or no permanent access, and elevate just-in-time for specific tasks, with the elevation auto-expiring. This shrinks the attack surface so far that a compromised identity yields almost nothing by default. Organisations that master 5.18 (least privilege, JIT, continuous review) find Zero Trust achievable; those that don't are perpetually one phished account away from a full-estate compromise.

Scope and Applicability

What the Control Covers

• All access rights (logical and physical) to information and associated assets, applications, databases, file shares, cloud resources, SaaS, source code, and physical areas.
• The full entitlement lifecycle: request → owner authorisation → provisioning → use → review → modification → revocation.
• Access for all entity types: employees, contractors, partners, and non-human/service identities.

Who It Applies To

Every organisation. The mechanics scale from a 20-person team managing Google Drive sharing to a bank running entitlement governance across hundreds of systems, but owner-authorised, least-privilege, reviewed access applies to all.

Size-Based Applicability

A Worked Access Matrix

A simple, auditable artefact every organisation should maintain, a matrix of roles vs systems vs access level. Example extract:

Note the deliberate gaps: a Finance Analyst cannot approve (SoD); a Developer gets production only just-in-time; an HR Officer's PII access is scoped to HR. The matrix makes least privilege and SoD visible and testable, and becomes the baseline against which access reviews are run.

Access for Third Parties and Service Identities

Suppliers, contractors and service/non-human identities all hold access rights and fall in scope. They warrant tighter defaults: time-boxed by contract end, scoped to the specific systems needed, owner-authorised, and reviewed at least as often as employee access (often more). Federated/partner access ties to A.5.19 (supplier security); service-account entitlements tie to A.5.16 (non-human identity governance).

Statement of Applicability (SoA) Note

A.5.18 is essentially always applicable. When drafting the SoA, explicitly include cloud and SaaS access and non-human entitlements in scope, a frequent source of findings is an SoA that implicitly meant "on-prem employee access," leaving cloud IAM and service-account permissions ungoverned.

Key Definitions and Terminology

Relationship to Other Controls

Where 5.18 Sits in the Access Chain

Access control is a layered system: A.5.15 writes the policy; A.5.16 establishes the unique identity; A.5.17 secures the credentials; A.5.18 grants and governs the entitlements; A.8.2 adds extra rigour for privileged entitlements; and A.8.3 technically enforces the restriction. A.5.18 is the operational heart, it is where the abstract policy ("least privilege, need-to-know") becomes concrete grants on real systems, and where the discipline of removing access (the most neglected verb) actually happens.

Access Models: RBAC, ABAC, PBAC and Least Privilege

Least Privilege and Need-to-Know

The two foundational principles. Least privilege grants only the access a role requires; need-to-know restricts information access to what a task demands. Both aim to minimise blast radius. Every access decision under 5.18 should be testable against them: does this identity need this access to do its job?

RBAC (Role-Based Access Control)

The workhorse model. Define roles that bundle the entitlements for a job function; assign people to roles; access flows from role membership. Benefits: scalable, reviewable, supports birthright access. Pitfalls: role explosion (too many fine-grained roles) and over-broad roles (one role granting too much). Good practice: a small set of well-governed business roles, composed of finer technical entitlements.

ABAC / PBAC (Attribute/Policy-Based)

Access decided dynamically by attributes (department, location, data classification, device posture, time) evaluated against central policies. More expressive than RBAC, ideal for context-aware and Zero Trust scenarios, but harder to author and audit. Most mature organisations run RBAC for the baseline + ABAC for context (e.g. RBAC grants the app, ABAC restricts to office hours / managed devices).

Choosing a Model

The Access Rights Lifecycle

Request

Access is requested with a stated business justification, ideally from a catalogue of defined roles/entitlements rather than free-text. The requester identifies the resource and the level (read/write/admin).

Authorise (owner approval + SoD check)

The asset/information owner authorises (27002 (a)); management approval may be added for sensitive access. The approver must not be the implementer (27002 (c)), and an SoD check confirms the new right does not create a toxic combination with existing rights.

Provision

Access is implemented, ideally automatically from the approved request, and activated only after authorisation is complete (27002 (g)). The grant is recorded (who, what, why, approver, date).

Use & Modify

As roles change (mover events), access is re-evaluated: new access added through the same authorised process, and, critically, access no longer needed is removed to prevent privilege creep (27002 (d)).

Review

Access is periodically recertified (Section 11) and reviewed after any significant change. Privileged access is reviewed more frequently.

Remove

Access is revoked promptly when no longer needed, on task completion, role change, or exit. Temporary access carries an expiry and auto-revokes (27002 (e)). Leaver access removal is time-bound to an SLA and is the single most-audited element.

Detailed Implementation Guidance

Anchor on the Access Control Policy (A.5.15)

5.18 enforces 5.15. Ensure your topic-specific access control policy defines least privilege, need-to-know, role definitions, approval authority, review cadence, and SoD principles, then 5.18 operationalises it.

Establish Asset Ownership

Access cannot be authorised without an owner. Use your asset inventory (A.5.9) to ensure every information asset/system has a named owner empowered to approve access, without this, 27002 (a) cannot be satisfied.

Build a Role Model

Map job functions to roles and roles to entitlements. Start with the highest-population roles and most sensitive systems. Define birthright access (granted automatically by role) and requestable access (granted on approved request). Keep roles few, meaningful, and owned.

Implement an Access Request & Approval Workflow

Replace email/verbal grants with a workflow that captures justification, routes to the asset owner, runs an SoD check, provisions on approval, and records everything. Even a lightweight ticketing workflow beats undocumented grants.

Automate Provisioning and Revocation

Drive birthright access from role assignment; use SCIM/connectors for downstream apps; and, most importantly, wire leaver and mover events to automatic revocation. Automation is what makes "timely removal" (27002 (d)) reliable rather than aspirational.

Enforce Segregation of Duties (see Section 10)

Define SoD rules (incompatible role/entitlement pairs), check them at request time, and detect violations continuously.

Govern Cloud Entitlements (CIEM)

Cloud estates accumulate excessive permissions silently. Use cloud-native tools (AWS IAM Access Analyzer, Azure Entra Permissions Management, GCP IAM Recommender) or a CIEM platform to right-size permissions toward least privilege and remove unused entitlements.

Handle Privileged, Temporary and Emergency Access

• Privileged access: minimise standing admin, broker through PAM, prefer just-in-time elevation (link A.8.2).
• Temporary access: always time-boxed with auto-expiry (27002 (e)).
• Emergency/break-glass: pre-approved, vaulted, alarmed, and reviewed after every use.

Cloud Infrastructure Entitlement Management (CIEM), Deeper Look

Cloud is where excessive permissions accumulate fastest and most invisibly. IAM policies get copied, broadened "to unblock the deploy," and never tightened. A CIEM practice:

• Discover all identities (human and machine) and their effective permissions across AWS/Azure/GCP, effective matters, because inherited and policy-combined permissions differ from what's written.
• Right-size by comparing granted vs actually-used permissions (e.g. AWS IAM Access Analyzer's last-accessed data, Azure Permissions Management's Permission Creep Index) and removing the unused.
• Detect risky grants: wildcards (*:*), privilege-escalation paths, cross-account trust, and public exposure.
• Right-size continuously, cloud drifts daily; a one-off cleanup regresses within weeks without automation.

Just-in-Time (JIT) Access and Zero Standing Privilege

The strategic end-state for high-risk access. Instead of permanent entitlements, identities request elevation for a specific task and time window; access is granted on approval and auto-revoked at expiry. Implemented via PAM, Entra PIM, or access-request tooling. Benefits: the standing attack surface shrinks toward zero, and every elevation is logged and justified, turning "who has admin?" from a scary open question into "nobody, by default."

Role Mining and Role Hygiene

Building a role model is not a one-time project. Use role mining (analysing existing access patterns) to design roles that reflect reality, then maintain role hygiene: retire unused roles, split over-broad roles, and prevent role explosion. A role model that drifts from reality drives people back to ad-hoc grants, undoing the control.

Access Rights Maturity Model (L1–L5)

Target L3 for certification; regulated BFSI is typically expected at L4.

Sector-Specific Notes (India)

• BFSI: RBI expects RBAC, least privilege, maker-checker SoD, and periodic recertification; privileged access via PAM. Inspections sample grants and review evidence directly. Target L4.
• IT/ITeS & SaaS: dominant risks are standing production access and multi-tenant entitlement sprawl; JIT + CIEM are high-value, and client SOC 2 reviews probe access-removal evidence.
• Healthcare: need-to-know on patient records is non-negotiable for DPDP; avoid "everyone sees everything" defaults.
• Manufacturing: keep ERP/financial entitlements separate from plant-operations roles to avoid SoD violations.
• Government/CII: broad administrative entitlements are a serious NCIIPC finding; minimise and review.

Segregation of Duties and Toxic Combinations

ISO 27002 5.18(c) and (f) explicitly tie access rights to segregation of duties (A.5.3). The goal: no single identity can execute and conceal a fraudulent or harmful action end-to-end.

Common Toxic Combinations

Implementing SoD

1. Define an SoD matrix of incompatible duties/entitlements (with input from finance, ops, and risk).
2. Preventive check at request time, block grants that create a violation.
3. Detective check continuously, scan existing assignments for violations.
4. Mitigating controls where separation is impossible (small teams): compensating monitoring, dual review, logging, documented and approved.
5. Separate approval from implementation (27002 (c)), the person who approves access must not be the one who configures it.

Access Reviews and Recertification

The "review" verb in the control, and the most common audit gap.

Review Cadence (risk-based)

Running an Effective Campaign

• Reviewers: the asset owner (does this person still need this access?) and/or line manager.
• Scope discipline: keep campaigns small and targeted so they are not rubber-stamped.
• Close the loop: revocations identified must actually be executed and evidenced, an uncompleted revocation is worse than no review (it shows you knew and didn't act).
• Micro-certifications: trigger a focused review on role change rather than waiting for the cycle.
• Evidence: retain reviewer, decisions, date, and revocation confirmations.

Why Reviews Catch What Automation Misses

Automation handles clean joiner/leaver events; reviews catch the messy middle, the analyst who moved teams but kept old access, the "temporary" grant that never expired, the entitlement added for a one-off project. Recertification is the safety net under your provisioning process.

Running Campaigns Without Rubber-Stamping

The failure mode of access reviews is the 500-line spreadsheet a manager approves wholesale in five minutes. Counter it:

• Right-size the scope: review one application or one team at a time, not everything at once.
• Give context: show the reviewer what each entitlement allows and when it was last used, "unused for 9 months" prompts revocation; a bare permission name does not.
• Default to revoke on no-response: non-response should remove access (after escalation), not retain it.
• Track remediation to closure: a revocation decision is not done until the access is actually gone and confirmed. Maintain a remediation log with owner and due date.
• Separate certifier from implementer: consistent with 27002 (c), the person confirming access should not be the one technically removing it.

Remediation Tracking

Every review produces a list of "remove" decisions. Track each to closure:

Review ID | Identity | Entitlement | Decision | Owner | Target date | Status | Confirmed-removed date

Auditors specifically test whether review decisions became review actions. A campaign that flagged 40 revocations but executed 12 is worse evidence than no campaign, it documents known, unactioned risk.

Tools, Technologies, and Solutions

Access Governance / IGA

Privileged Access & Cloud Entitlements

• PAM: CyberArk, Delinea, BeyondTrust, ARCON (Indian-origin, widely deployed in Indian BFSI).
• CIEM: Entra Permissions Management, AWS IAM Access Analyzer, GCP IAM Recommender, Wiz/Orca (CNAPP with CIEM).

Selection Guidance

Rule: model roles and run reviews before buying heavy tooling. An IGA suite automates a good access model; it cannot create one.

Access Control Policy and Request Templates

Access Rights Policy (extract)

Access Rights Policy — Acme Technologies Pvt Ltd
ISO 27001:2022 Annex A 5.18

1. Purpose
   To ensure access rights to Acme's information and assets are provisioned, reviewed,
   modified and removed on a least-privilege, need-to-know, owner-authorised basis.

2. Scope
   All logical and physical access rights for all identities (human and non-human).

3. Policy Statements
   3.1 Access shall be granted on least privilege and need-to-know.
   3.2 All access requires authorisation by the information/asset owner; sensitive access
       requires additional management approval.
   3.3 The approver of access shall not be the implementer (segregation of duties).
   3.4 Access that would create a segregation-of-duties conflict is prohibited unless a
       documented compensating control is approved.
   3.5 Access shall be re-evaluated on role change and removed when no longer required;
       leaver access shall be revoked within [4h privileged / 24h standard].
   3.6 Temporary access shall carry an expiry and auto-revoke.
   3.7 Access rights shall be recertified on a risk-based schedule (privileged quarterly;
       standard at least annually).
   3.8 Records of all grants, modifications, reviews and revocations shall be retained.

4. Roles
   Asset owners (authorise), IAM (implement/record), Managers (request/justify),
   CISO (govern), Internal Audit (assure).

5. Review
   Reviewed annually or on significant change.

Access Request Form (fields)

- Requester / Manager:
- Identity (unique ID):
- Resource / system:
- Access level requested: [Read | Write | Admin | Custom]
- Business justification:
- Duration: [Permanent | Temporary until <date>]
- Asset owner approval:
- SoD check result: [Pass | Violation -> mitigation]
- Implemented by (≠ approver) / date:

Risk Assessment and Treatment

Audit and Compliance Checklist

(The toolkit 04-audit-evidence-checklist.md maps each question to the exact ISO 27002:2022 5.18 guidance clause and a sample evidence artefact.)

What Auditors Actually Probe

• "Show me how this person got admin on this system, request, justification, and who approved it." Tests owner authorisation (27002 (a)) and approver≠implementer (27002 (c)).
• "Run your last access-review campaign and show me what was revoked." Tests that reviews are real and close the loop.
• "Pick a leaver, show their access is gone everywhere, not just the directory." Tests downstream revocation, not just identity disablement.
• "Demonstrate that maker and checker can't be the same person here." Tests SoD enforcement. The organisations that pass are the ones whose access-request workflow and recertification produce clean, owned, actioned evidence on demand.

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian Private-Sector Bank (5,200 staff): RBAC, SoD and Recertification

Challenge. An RBI IT examination flagged that branch staff had accumulated access across multiple role changes (privilege creep), that some users held both maker and checker rights in a payments application (an SoD violation), and that no periodic access recertification existed. Each was an RBI Cyber Security Framework breach and an ISO 27001 nonconformity.

Solution (Singahi-guided, 14 weeks).

1. Built an RBAC role model mapped to job functions; replaced ad-hoc grants with birthright + requestable access.
2. Defined an SoD matrix (starting with maker/checker and finance combinations) enforced at request time in Saviynt, with continuous detective scanning.
3. Wired mover events to access re-evaluation, removing access not needed in the new role.
4. Launched quarterly recertification for privileged and payments access, semi-annual for the rest, with revocations tracked to closure.

Results. Maker/checker SoD violations reduced to 0; average entitlements per user fell ~30% as privilege creep was unwound; the RBI observations were closed at follow-up and the bank passed ISO 27001 recertification with no access findings.

Illustrative Scenario 2, Indian SaaS Company (Bengaluru, 900 staff): Least Privilege in the Cloud

Challenge. A B2B SaaS company found engineers held standing production access across AWS accounts, IAM policies had been copied and broadened over years (massive excess permissions), and several ex-contractors retained access. A prospective enterprise customer's security review flagged this, threatening a major deal.

Solution (Singahi-guided, 10 weeks).

1. Deployed CIEM (Entra Permissions Management + AWS IAM Access Analyzer) to baseline and right-size permissions, removing unused entitlements.
2. Replaced standing production access with just-in-time elevation via PAM, approved per request and time-boxed.
3. Implemented an access request workflow with resource-owner approval and SoD checks for sensitive scopes.
4. Wired contractor offboarding to automatic revocation with expiry on all temporary access.

Results. Unused cloud permissions cut by ~75%; standing production access eliminated in favour of JIT; ex-contractor access reduced to 0; the enterprise customer's security review passed and the deal closed. The access-governance evidence became a reusable asset for future customer due diligence.

Illustrative Scenario 3, Indian Manufacturing Enterprise (Chennai, 3,000 staff): Fixing SoD in ERP

Challenge. A discrete-manufacturing group running SAP found, during ISO 27001 implementation, that plant and finance access had blurred: some plant supervisors could raise purchase orders, receive goods, and approve invoices, a classic procurement-fraud toxic combination, and several users retained finance access from prior roles. There was no SoD ruleset and no recertification.

Solution (Singahi-guided, 12 weeks).

1. Defined an SoD matrix for the core procure-to-pay and order-to-cash processes with finance and internal audit.
2. Remediated existing toxic combinations, splitting roles so PO creation, goods receipt, and invoice approval sat with different identities; documented compensating controls where small teams genuinely required overlap.
3. Implemented preventive SoD checks in the access-request workflow and detective scans monthly.
4. Ran the first semi-annual recertification, unwinding privilege creep from prior roles.

Results. Procurement-fraud toxic combinations reduced to 0 (with documented, monitored exceptions for two small sites); finance privilege creep unwound; the SoD matrix and recertification evidence satisfied both the ISO 27001 auditor and the group's statutory financial controls (ITGC).

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Foundation (Weeks 1–3)

• Confirm/align the access control policy (A.5.15); confirm asset ownership (A.5.9).
• Inventory current access on the most sensitive systems; run a first access review (quick win).
• Draft and approve the Access Rights Policy.

Phase 2, Model & Workflow (Weeks 4–7)

• Build the RBAC role model for top roles/systems; define birthright vs requestable access.
• Stand up the access request + owner-approval workflow with SoD checks.
• Wire automated provisioning and leaver/mover revocation.

Phase 3, SoD & Cloud (Weeks 8–10)

• Define and enforce the SoD matrix (preventive + detective).
• Deploy CIEM to right-size cloud permissions; introduce JIT for privileged access.

Phase 4, Certify & Mature (Weeks 11–12+)

• Launch recertification campaigns; build the KPI dashboard.
• Internal audit dry-run against the Section 15 checklist; schedule recurring reviews.

Detailed 90-Day Plan

RACI Snapshot

(R = Responsible, A = Accountable, C = Consulted, I = Informed.)

Sustaining the Control

Access drifts continuously. Keep A.5.18 healthy by operationalising leaver/mover automation, running recertification on schedule, maintaining role hygiene (retire/split roles), right-sizing cloud entitlements continuously, and feeding access-related incidents back into the process (link A.5.27). Re-baseline maturity (L1–L5) annually and pair the access dashboard with each ISMS management review (Clause 9.3).

FAQ

Q1: Is A.5.18 mandatory for certification? Yes. It is assessed against your SoA and is applicable to essentially every organisation. Auditors actively sample access grants, leaver removals, and review evidence.

Q2: What's the difference between A.5.15, A.5.16 and A.5.18? 5.15 is the access control policy; 5.16 is identity (who exists); 5.18 is access rights (what they can do). 5.18 operationalises 5.15 for the identities established by 5.16.

Q3: How is A.5.18 different from A.8.2 Privileged access rights? 5.18 governs all access rights; A.8.2 adds stricter controls for the privileged subset (PAM, JIT, session recording). Implement 5.18 broadly and layer A.8.2 on admin access.

Q4: How often must we run access reviews? Risk-based: privileged quarterly (or monthly), sensitive systems quarterly–semi-annually, standard access at least annually, plus event-driven reviews on role change.

Q5: We're a small team and can't fully separate duties, is that a finding? Not necessarily. Where separation is impractical, document compensating controls (dual review, monitoring, logging) and have them approved. The finding is unmanaged SoD risk, not small size.

Q6: What's the highest-impact quick win? Run an access review of your most sensitive system and revoke everything unjustified, then wire leaver events to automatic revocation. This addresses the two most common findings at once.

Q7: How does 5.18 support DPDP Act compliance? DPDP "reasonable safeguards" include access control. Need-to-know access to personal data, owner authorisation, and timely removal are exactly what demonstrates that safeguard.

Q8: What about access for service accounts and vendors? They get access rights too, governed the same way: owner-authorised, least-privilege, time-bound where possible, reviewed, and revoked on decommission/contract end.

Q9: Isn't removing access the same as disabling the identity (5.16)? No. 5.16 disables the identity; 5.18 removes the entitlements. A leaver needs both: identity disabled and access revoked everywhere downstream. A common gap is disabling the central login while local app entitlements linger.

Q10: How do we do least privilege without blocking the business? Use birthright access for day-one productivity (the access a role genuinely needs), make everything else a quick self-service request with owner approval, and add JIT for occasional high-risk tasks. Least privilege fails when requests are slow, invest in a fast, owner-approved workflow so people don't hoard access "just in case."

Key Takeaways

• A.5.18 governs entitlements across four verbs: provision, review, modify, remove, the last two are the most neglected and most audited.
• Owner authorisation + segregation of duties are mandatory in substance: every grant needs an authoriser, the approver must not be the implementer, and toxic combinations must be prevented.
• Least privilege and need-to-know limit blast radius, they are the difference between a contained incident and a full-estate breach.
• Timely removal of leaver access and periodic recertification are the two evidence sets auditors test hardest; reviews must close the loop with actual revocations.
• Cloud is where excess accumulates, use CIEM to right-size continuously, and move high-risk access to just-in-time with near-zero standing privilege.
• In India, A.5.18 satisfies RBI-, SEBI-, IRDAI- and DPDP-style access expectations at once, least privilege, SoD/maker-checker, and recertification.
• Quick win: review your most sensitive system now, revoke the unjustified, and automate leaver revocation.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022, Annex A control 5.18.
• ISO/IEC 27002:2022, Clause 5.18, Access rights (provisioning/revocation guidance (a)–(g); access reviews).
• Related: ISO/IEC 27002:2022 §5.15 (Access control), §5.3 (Segregation of duties), §5.9 (Asset ownership).

Supporting frameworks

• NIST SP 800-53 Rev 5, AC-2 (Account Management), AC-3 (Access Enforcement), AC-5 (Separation of Duties), AC-6 (Least Privilege).
• NIST CSF 2.0, PR.AA-05 (access permissions, least privilege, SoD).
• CIS Controls v8, Control 6 (Access Control Management).
• PCI DSS v4.0, Requirement 7 (need-to-know) and Requirement 8.
• SOC 2 (TSC 2017), CC6.1–CC6.3.
• COBIT 2019, DSS05.04.

Indian regulations

• Digital Personal Data Protection Act, 2023, Section 8(5) reasonable safeguards.
• RBI, Cyber Security Framework (2016); Master Direction on IT Governance, Risk, Controls and Assurance Practices.
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF), 2024.
• IRDAI, Information and Cyber Security Guidelines.
• CERT-In, Directions under Section 70B of the IT Act, 2000 (2022).
• IT Act, 2000, Sections 43A, 72A.

Singahi resources: the A.5.18 toolkit and related guides for A.5.15 Access control, A.5.16 Identity management, A.5.3 Segregation of duties, and A.8.2 Privileged access rights.