Annex A 5.18: Access Rights

Annex a 5.18: access rights requirement expects you to control who has access to information and systems, keep those rights aligned to job need, and prove you review and remove access promptly as roles change. Operationalize it by standardizing joiner/mover/leaver (JML) workflows, enforcing least privilege, and retaining recurring review evidence across apps, infrastructure, and third parties. ¹

Key takeaways:

• Define access rights by role, approve them before grant, and remove them when no longer needed. ¹
• Treat access reviews as a recurring control with named owners, scoped systems, and auditable outputs. ¹
• Evidence matters as much as intent: tickets, approvals, review logs, and termination attestations must be retained and searchable. ¹

Annex A 5.18 sits in the “organizational controls” group in ISO/IEC 27001:2022 and is one of the controls auditors probe early because access problems show up everywhere: breaches, outages, fraud, and failed investigations. Your goal is simple to state and easy to get wrong in execution: access rights must be managed across the full lifecycle and kept appropriate to business need. ¹

For a CCO, Compliance Officer, or GRC lead, the fastest path to maturity is to translate 5.18 into an operating rhythm: clear rules (least privilege and separation of duties where needed), a consistent workflow (JML), and recurring verification (access reviews with documented outcomes). The “gotcha” is scope. 5.18 is not just “Active Directory hygiene.” It covers SaaS, cloud consoles, code repos, data platforms, endpoints, and third-party support access that can touch your environment. ¹

This page gives requirement-level implementation guidance you can assign to IT, Security, and system owners, with evidence requirements that hold up in an ISO 27001 audit.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.18 implementation expectation (Access Rights).” ¹

Operator interpretation: You must implement a controlled process to grant, change, review, and revoke access rights for users and non-human identities (service accounts, API tokens) across in-scope systems, and you must be able to demonstrate that the process operates in practice. ¹

What the operator must do (minimum bar):

• Define how access is requested, approved, provisioned, and removed (including emergency access). ¹
• Ensure access rights remain appropriate as people change roles or leave and as systems change. ¹
• Retain evidence that approvals, changes, and periodic reviews occurred and were acted on. ¹

Plain-English interpretation (what 5.18 is really testing)

Auditors use 5.18 to answer three questions:

1. Can the wrong person get access? If yes, your access design and approvals are weak.
2. Can access linger after it should be gone? If yes, your offboarding and mover processes are weak.
3. Can you prove control operation without hand-waving? If no, your evidence trail is weak.
   All three must be addressed with documented process and repeatable records. ¹

Who it applies to (entity and operational context)

Applies to:

• Any organization operating an ISMS aligned to ISO/IEC 27001:2022, especially service organizations handling customer data or running customer-impacting systems. ²

Operational scope you should assume unless your ISMS scope statement excludes it:

• Workforce identities: employees, contractors, interns, temps.
• Privileged users: admins, DBAs, cloud admins, security admins.
• Non-human identities: service accounts, API keys, automation tokens.
• Third-party access: MSPs, consultants, customer support tools with console access.
• Systems: IAM/SSO, HRIS, cloud platforms, source control, ticketing, finance apps, data warehouses, endpoints. ³

What you actually need to do (step-by-step)

1) Set your access rights policy and decision rules

Create (or update) an Access Rights Management Standard that answers:

• What “least privilege” means in your environment (role-based access by default; exceptions require justification).
• Who can approve what (manager approval for standard access; system owner approval for sensitive apps; security approval for privileged roles).
• Required authentication baseline for access (tie to your access control and authentication controls in your ISMS).
• How you handle shared accounts (generally prohibited; if any exist, document compensating controls and approvals).
• How you handle break-glass/emergency access (time-bound, logged, reviewed after use).
  Map this standard to your ISMS control matrix for Annex A 5.18. ¹

Practical tip: Put the approval matrix in a table so it can be tested.

2) Build a system inventory specifically for access rights

You cannot review what you cannot enumerate. Build an “Access Review Population” list:

• System name, owner, data classification, user population, auth method (SSO or local), and how to export users/roles.
• Identify systems that cannot produce an export. Flag them for remediation or compensating controls. ³

3) Standardize Joiner/Mover/Leaver (JML) workflows

Implement JML as the operating backbone of 5.18:

• Joiner: account creation triggered by HR/contractor onboarding; access granted only via approved request; default to role-based groups.
• Mover: role change triggers review of existing access; remove access that no longer fits; add only what’s required for the new role.
• Leaver: termination triggers disablement and revocation, including SaaS, VPN, cloud keys, tokens, and third-party accounts. ¹

Operational minimum: One system of record for identity status (HRIS or equivalent) and one ticket trail for each join/move/leave action.

4) Implement access request and approval controls

For each access grant:

• Require a ticket (or workflow) with: requester, business justification, target system, requested role/permission set, approver(s), and effective date.
• Enforce segregation between requester and approver for privileged access.
• Ensure provisioning is performed by IT/IAM automation or a delegated admin with traceability. ³

5) Establish recurring access reviews (and make them auditable)

Run recurring reviews for:

• Privileged access (admin roles, production access, security tools).
• Sensitive systems (finance, HR, customer data platforms).
• Third-party access (support vendors, MSP accounts). ³

Each review needs:

• A defined reviewer (system owner), a defined method (export of users/roles), and documented dispositions (keep/remove/change).
• Follow-through evidence: tickets showing removals completed, not just “review completed.”

Make it real: Sample-check the results. If reviewers rubber-stamp, you will see it in unchanged access despite role changes.

6) Control non-human access rights (service accounts and tokens)

Operators often miss this under 5.18. Require:

• An owner for every service account/token.
• A documented purpose and scope (what it can access).
• Storage and rotation expectations aligned to your security architecture.
• Review alongside privileged access when it can reach sensitive systems. ³

7) Document and retain evidence (recurring capture)

Turn 5.18 into a “recurring evidence capture” control operation: every cycle produces artifacts that can be retrieved quickly. This aligns directly to the recommended practice of mapping 5.18 to documented operation and recurring evidence capture. ¹

Where Daydream fits naturally: If you struggle to keep evidence consistent across systems, Daydream can centralize the control narrative, owners, review cadence, and evidence requests so access reviews stop living in scattered spreadsheets and inbox threads.

Required evidence and artifacts to retain

Keep these in a controlled repository aligned to your ISMS evidence approach:

• Access Rights Management Policy/Standard and approval matrix. ²
• System inventory for access review scope (system owner, export method, sensitivity). ³
• JML procedures (onboarding/offboarding checklists, HR trigger description).
• Sample access request tickets showing approvals and provisioning actions (including privileged access).
• Access review packages for each review cycle:
  • user/role export,
  • reviewer attestation,
  • exception list with justifications,
  • remediation tickets and closure evidence.
• Third-party access approvals and termination confirmations (for external admins/support).
• Break-glass logs and post-use review notes (if applicable). ³

Common exam/audit questions and hangups

Expect these in ISO 27001 certification audits:

• “Show me the last access review for your most sensitive system and the evidence you removed access.”
  Hangup: teams show a sign-off but no removal tickets.
• “How do you know terminated users cannot still access SaaS apps?”
  Hangup: SSO covers some apps; local accounts remain in others.
• “Who approves privileged access and how do you prevent self-approval?”
  Hangup: admin grants done informally in chat.
• “How do you manage service accounts, API keys, and shared credentials?”
  Hangup: no inventory, no owners. ³

Frequent implementation mistakes (and how to avoid them)

1. Treating access rights as only an IT control.
   Fix: assign system owners accountability for access in their apps; Security/GRC sets the standard and tests. ²

2. Relying on “SSO exists” as evidence.
   Fix: prove JML events and app-level deprovisioning outcomes, including exceptions for non-SSO systems.

3. Access reviews without action.
   Fix: require a remediation tracker and closure evidence as part of the review package.

4. Ignoring third-party and non-human access.
   Fix: include them in the review population inventory and review cadence. ³

5. No consistent evidence trail.
   Fix: standardize templates for review sign-offs and store exports, tickets, and approvals in one evidence location; use Daydream to orchestrate evidence requests and retention.

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement, so you should frame risk through audit failure and operational impact rather than citing specific penalties. Poor access rights management commonly leads to unauthorized access, delayed revocation after termination, excessive privilege, and weak investigation trails. Those issues can become security incidents, contractual breaches, or audit nonconformities even when no regulator is involved. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and rules)

• Publish/update the Access Rights Management Standard with an approval matrix and break-glass rule. ²
• Build the access review population inventory for all in-scope systems; name an owner per system. ³
• Define JML triggers and confirm HR/IT handoffs; document the workflow in your ticketing system.
• Pick one evidence repository structure and templates for access requests and review packages.

Next 60 days (implement recurring operation)

• Enforce ticketed approvals for access grants in high-risk systems first (cloud consoles, customer data platforms, finance, security tooling).
• Run the first privileged access review and produce a complete review package with remediation closures.
• Inventory service accounts and tokens for critical systems; assign owners and document purpose. ³

By 90 days (prove control effectiveness)

• Expand access reviews to remaining sensitive systems and third-party access.
• Test JML end-to-end: sample joiners, movers, and leavers; verify access was granted/changed/removed as documented.
• Hold a control review meeting with GRC, IAM, and system owners; capture issues, corrective actions, and the next review schedule.
• If evidence collection is inconsistent, implement Daydream workflows to standardize requests, reminders, and audit-ready packaging.

Frequently Asked Questions

Does Annex A 5.18 require periodic access reviews, or is approval at provisioning enough?

Provisioning approval alone rarely satisfies auditors because it does not address access drift after role changes. Run recurring reviews for privileged and sensitive access and retain evidence of removals. ³

What systems are “in scope” for access rights?

Start with systems in your ISMS scope and then include any system that stores, processes, or can administer in-scope information. If a system cannot export access lists, document a workaround or remediation plan. ¹

How should we handle third-party access for support or managed services?

Treat third-party accounts like workforce privileged access: named identities, documented approval, time-bounded access where possible, and inclusion in access reviews. Keep evidence of access removal when the engagement ends. ³

Are service accounts and API keys part of “access rights” under 5.18?

Yes in practice, because they grant access to systems and data and can be over-privileged. Maintain an inventory, assign ownership, and review them with privileged access populations. ³

What is the minimum evidence auditors expect for an access review?

A user/role export, documented reviewer sign-off, identified exceptions with justification, and tickets proving removals or changes were completed. A meeting note without exports and remediation proof usually fails. ³

We have local accounts in some SaaS tools outside SSO. Is that automatically noncompliant?

Not automatically, but it increases the burden of proof. You need a documented method to provision and deprovision those accounts and include them in access reviews with retrievable evidence. ³

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index