Access rights
Granting, reviewing, changing and withdrawing access rights to information and associated assets is to follow the organization's access control policy and rules.
What the requirement asks
Granting, reviewing, changing and withdrawing access rights to information and associated assets is to follow the organization's access control policy and rules. Purpose: keep access to information and assets defined and approved in line with business needs. Guidance on provisioning and revocation of physical and logical rights attached to an authenticated identity: get the asset owner's authorization (5.9), with separate management approval where suitable; weigh business need and the access control policy; apply segregation, keeping approval apart from implementation and conflicting roles apart; withdraw rights when no longer needed and promptly for leavers; consider time-limited access that expires automatically, especially for temporary staff or temporary needs; check the level granted fits the policy (5.15) and other requirements such as segregation of duties (5.3); activate rights, including by service providers, only after authorization is complete; keep a central record of rights held by each user identifier; change rights when people change job; remove or adjust rights by revoking or replacing keys, credentials, ID cards or subscriptions; and log every change to logical and physical rights. Reviews should regularly look at rights after internal moves (promotion, demotion, job change) or employment end (6.1 to 6.5) and at privileged authorizations. Before a change or termination, rights are reviewed and reduced or removed based on risk: who initiated it and why, the person's current duties and the value of what they can reach. Other information: role-based access profiles make requests and reviews easier; contracts can set sanctions for attempted unauthorized access (see 5.20 and 6.2, 6.4 and 6.6); people dismissed or resigning may sabotage systems or gather information; copying one user's access to another (cloning) is convenient but should be based on defined roles, since it tends to grant excess rights. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Access rights are expected to be granted, reviewed and removed against a record. The guidance asks for the owner of each right, the review frequency and the evidence that a leaver lost access on the day.
Status of the guidance. The guidance lens for 5.18 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep access request records showing owner authorization, and management approval where required, before rights were activated and one live sample together.
Evidence an assessor asks for
- Access provisioningAccess request records showing owner authorization, and management approval where required, before rights were activated
- Access provisioningA central record of access rights per user identifier across logical and physical access
- Access provisioningPeriodic access review records including privileged access, with evidence that removals identified in the review were actioned
- Access provisioningLeaver and mover reports showing timely removal or adjustment of rights, including keys, cards and subscriptions
- Access provisioningConfiguration or records of time-limited access that expired automatically for temporary needs
- Access provisioningA change history for every user's logical and physical access
The question an assessor will ask
An assessor will ask for access request records showing owner authorization, and management approval where required, before rights were activated, then trace it to the system it protects. For A.5.18 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- Access is cloned from a colleague's profile, carrying over excessive rights
- Access reviews are rubber-stamped by managers without owner involvement
- Physical access badges are not revoked on the same timeline as logical accounts
- Temporary access granted for projects is never removed
Before the next audit
Before the next audit, check one live sample for this gap: access is cloned from a colleague's profile, carrying over excessive rights.