UnixTime

Research Note

ISO 27001 A.5.18 - Access Rights

Access rights must be granted, changed, reviewed, and removed through a controlled process.

On this page

Requirement

Requirement lens

Treat this as the control objective. The implementation, evidence, and audit sections explain how to make it operational and provable.

“Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.”

Plain-language meaning

Access rights must be granted, changed, reviewed, and removed through a controlled process.

This is where the access control policy becomes operational. A.5.15 defines access control rules. A.5.16 manages identities. A.5.18 manages the actual access rights assigned to those identities.

Why this matters

Access rights drift. People change roles, join projects, leave teams, become promoted, inherit group membership, or retain access after contract end. If rights are not reviewed and removed, the organization accumulates hidden exposure.

The risk is higher for:

  • sensitive information;
  • privileged access;
  • shared credentials;
  • long-tenured staff;
  • promoted staff;
  • contractors;
  • third-party users;
  • physical access cards and keys;
  • subscriptions, distribution lists, and specialist groups.

Implementation guidance

Implementer focus

Turn this section into owners, procedures, records, review cadence, and evidence locations. A control is not implemented until it operates repeatedly.

1. Use formal access requests

Access should be requested and approved before provisioning.

Useful request fields:

Field Purpose
User identity Links request to registered user
System/service/application Identifies requested resource
Access level Defines read/write/admin/physical/group membership
Business justification Shows need-to-use
Conditions of access Shows rules accepted by user
Asset owner approval Shows authorization
User ID assigned Links approval to implementation
Review date Supports later removal

2. Provision access based on policy

Provisioning should follow A.5.15 Access Control, A.5.16 Identity Management, and role-based access profiles where practical.

Avoid “special cases” unless they are justified, approved, time-bound, and visible.

3. Review access regularly

Access reviews should compare actual access to authorized access.

Reviewers should check:

  • does the person still need access?
  • does the access match their current role?
  • is privileged access still justified?
  • is access consistent with classification?
  • should old project or role access be removed?
  • are shared credentials still needed?
  • are contractors and third parties still active?

The review must result in action. A review that never removes anything is suspect.

4. Modify and remove access promptly

Access should be updated when:

  • someone leaves;
  • someone changes role;
  • a project ends;
  • a contract ends;
  • a supplier relationship changes;
  • an asset classification changes;
  • a risk assessment changes;
  • an access review finds excess rights.

Removal should cover both physical and logical access: accounts, groups, email, applications, networks, badges, keys, tokens, subscriptions, and interest groups.

5. Handle high-risk terminations carefully

When termination is initiated by management or involves a disaffected employee, contractor, or third-party user, access removal may need to be immediate or pre-coordinated.

The goal is to prevent information collection, disclosure, modification, or destruction during the period between notification and loss of access.

6. Avoid shared credentials

If shared credentials are used, change them whenever any user no longer requires access.

Individual credentials are preferable because they preserve accountability.

Audit guidance

Auditor focus

Look for evidence that the process operates in practice, not just that a document exists.

Auditors should sample access registrations, authorizations, actual system permissions, movers, leavers, long-tenured staff, promoted staff, privileged users, and shared credentials.

Audit tests:

  • compare access request records to actual access;
  • verify asset owner approval;
  • check access granted after role changes;
  • check old access removed after role changes;
  • review leaver access removal timing;
  • test physical and logical access removal;
  • inspect access review records;
  • confirm actual access was compared to authorized access;
  • verify changes identified in reviews were completed.

Auditors should interview staff who changed roles. The direct question is: “Do you still have access from your old role?”

Evidence examples

Evidence quality

Strong evidence links requirement, owner, action, date, review, and outcome. Weak evidence usually proves only intent.

Evidence What it proves
Access request form Access was requested and justified
Owner approval record Access was authorized
System access export Actual access can be tested
Access review record Rights are periodically checked
Removal tickets Excess rights are removed
Joiner/mover/leaver workflow Access changes follow personnel events
Privileged access review Elevated access is controlled
Shared credential register Shared access is known and controlled
Physical access logs Physical rights are included
Subscription/group membership review Non-system access is included

Strong evidence

  • Access rights are traceable from request to approval to implementation.
  • Actual access is compared against authorized access.
  • Reviews include physical, logical, privileged, group, subscription, and third-party access where relevant.
  • Mover access is both added and removed promptly.
  • Leaver access removal is evidenced.
  • Shared credentials are changed when a user leaves the group.
  • Review findings lead to completed removals.

Weak evidence

  • Access is granted informally.
  • Access reviews are just screenshots with no decisions.
  • Movers keep old privileges.
  • Leavers retain accounts or group memberships.
  • Shared credentials are unchanged after users leave.
  • Physical access cards and keys are not reviewed.
  • Delayed provisioning causes staff to share accounts as a workaround.

Common failures

Implementation watchouts

These are the fastest ways this topic fails in real ISMS work.

Failure Why it matters
Reviews do not compare actual to authorized access Excess rights remain hidden
Movers keep old access Privilege accumulation becomes normal
Shared credentials not changed Former users may retain access
Physical access excluded Facility and paper risks remain
Delayed access provisioning Users create informal workarounds
No high-risk termination process Disaffected users can damage or exfiltrate information

Exam traps

Exam focus

Read these as distractor patterns. Exams often test scope, timing, ownership, applicability, and evidence quality.

  • A.5.18 is about provisioning, reviewing, modifying, and removing access rights, not merely defining access rules.
  • Movers matter as much as leavers.
  • Physical access rights are in scope.
  • Access reviews should compare actual access to authorized access.
  • Senior, long-tenured, and promoted staff are high-risk samples for accumulated access.
  • Shared credentials require credential change when a user no longer needs access.

KB-ready summary

Quick refresher

Use this section for last-day review and for explaining the topic to a control owner.

A.5.18 requires access rights to be provisioned, reviewed, modified, and removed according to access control rules. The practical control is traceability: request, approval, implementation, review, correction, and removal should all be evidenced.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Organizational controls
  • Access rights
  • Access control
  • Joiner mover leaver
  • Audit

Note Metadata

Aliases: A.5.18, Access Rights

Source: 02 Annex A Organizational Controls/A.5.18 Access Rights.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

10

links

01
02

Implementation artifacts

Templates and working records that help operate the control.

03

Audit checks

Audit questions, checklists, or review material connected to the control.

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.