ISO 27001 A.5.18: Keep Access Rights Justified

What A.5.18 requires in practice

Annex A control A.5.18 asks that the permissions people hold over information and its related assets are granted, reviewed, changed and withdrawn. All of this must follow the organisation’s own access control policy for this topic and the rules built from it. The four verbs describe the working life of an access right.

Provisioned means access is given only after proper approval and for a defined purpose. Reviewed means someone checks from time to time that the access is still justified. Modified means rights change when a role, project or responsibility changes. Removed means they end when no longer needed, whether a person leaves or simply moves on.

The control does not set review frequencies, tools or approval forms. The organisation decides what is proportionate, with more sensitive access examined more closely. What matters is that rights are not allowed to accumulate unnoticed and that decisions can be traced back to the access rules.

Grant the requested capability, not a colleague’s history

A request should identify the task, information or asset involved and the permission needed. Appropriate owners authorise that need before access becomes available. Technical administrators can advise on available roles and limitations, but should not have to infer business entitlement from a vague request to “match the existing team.”

Copying another person’s entire access set can reproduce years of exceptions. Use approved role definitions where useful and examine additional rights separately. Consider conflicting permissions and whether approval and implementation need separation. After provisioning, verify that the actual rights match the decision.

Temporary access needs an end condition. A defined expiry can help, but only if the target system applies it and renewal is deliberate. If automatic expiry is unavailable, assign a reliable review or removal task and check completion. An expiry recorded in a request has no protective effect when access remains active elsewhere.

Make reviews intelligible to decision-makers

Give reviewers enough context to judge need. A list of technical group names without their capabilities encourages blanket approval. Explain the role, information reached, sensitive privileges and business owner. Distinguish the identity’s existence from its actual permissions, including inherited and delegated access.

Review timing should reflect risk and change. Periodic review can catch missed events; event-driven review handles departures, transfers and changed assignments when they occur. Privileged and high-consequence access may need closer attention. The organisation should define a defensible approach rather than select a frequency solely because it is easy to schedule.

Why access rights matters to the business

Access tends to grow quietly. People change roles and keep earlier permissions, temporary access becomes permanent and projects end without anyone closing the doors they opened. Over time, many users hold far more access than they need, which raises the chance and impact of error, misuse or compromise.

Regular and disciplined handling of rights keeps exposure in proportion. It also shows customers and assessors that access is deliberate and not accidental. Reviews that are meaningful, with owners who truly decide, are far more convincing than a signed list nobody examined. Clean access also makes incidents easier to investigate, since fewer people could have been involved.

How to implement A.5.18

Make the owner of the information, rather than IT alone, the person who decides whether access is justified. Start the review routine with the most sensitive systems, then extend it as the approach becomes routine. Keep a note of the reasons for each choice.

1. Define how access is requested and approved, so that the approver understands what is being granted and why.
2. Match rights to roles and tasks where possible, to reduce the need for individual decisions.
3. Trigger modification and removal from events such as role changes, project ends and departures.
4. Give special attention to powerful or sensitive rights, with closer approval and more frequent examination.
5. Set a review routine with real decisions: owners confirm, change or end access, and the outcome is acted on.
6. Handle temporary access with an end point that is checked, instead of relying on memory.
7. Test whether review findings were carried out and use patterns to improve the access rules.

Illustrative manufacturing example: a promotion accumulates rights

Illustrative software example: access survives project closure

A hypothetical software company closes a customer integration project. Contractor directory accounts are disabled, yet invitations to the customer’s separate project workspace remain active. The internal exit checklist reports completion because it only covers company-managed systems.

The project owner reconciles external access with the agreed workspace administrator and obtains suitable confirmation. Future project closure includes partner-managed permissions and any local credentials. The organisation tests the actual access boundary through authorised methods. A closed internal ticket alone is not treated as proof that every external permission has ended.

Plan revocation around consequence and dependencies

Removal timing should consider the circumstances of departure or change and the information at risk. Coordinate physical access, application permissions, shared arrangements and relevant authentication changes. Preserve needed business records through an authorised handover; do not leave obsolete access active merely because no one has planned how to transfer work.

Some accounts support services as well as individual work. Identify dependencies before changing them, while avoiding indefinite postponement. A controlled reassignment may be needed. Link personnel changes with continuing responsibilities after employment changes so that technical closure and human obligations align.

Use evidence that shows completion

Common nonconformities with A.5.18

Typical findings show rights that were granted carefully and then left alone. Assessors usually test this control by comparing current rights with what people currently do.

• People who changed roles still hold permissions for their previous work.
• Reviews are signed off without any access being changed, suggesting no real examination took place.
• Temporary or project access has no end date and remains in place long after the work finished.
• Approvals are given by someone who cannot judge whether the access is needed.
• Reviewers receive long lists with no context, so they approve everything without understanding the access.