ISO 27001 access control flowchart (Annex A.5.15)

How it works

1. Draw the lanes the process actually has

   Requester, immediate manager, system or data owner, and IT operations. If a service desk handles the actual provisioning, give it its own lane.

2. Separate business approval from technical provisioning

   The decision on whether the role should have the access, and the act of granting it, need to be two steps with two different owners.

3. Add the privileged-access branch

   Administrator rights, production data and service accounts need an extra approval and a shorter validity period.

4. Put deadlines on revocation

   State how fast access must be removed on termination — same day for privileged accounts is typical.

5. Link every step to its evidence

   Note in the comment field which system holds the proof for each step: the request, the approval, the provisioning, and the review.

Frequently asked questions

What does an ISO 27001 access control flowchart need to cover?

Annex A.5.15 requires the full access lifecycle: request, business approval, technical provisioning, periodic review, change of role, and revocation on leaver/mover events.

Is a process flowchart enough evidence for an ISO 27001 audit?

Auditors want the flowchart, the approval record showing it's the controlled current version, and evidence that operations actually follow it. QueryChart provides the first two natively — approval-tracked, version-controlled, audit-ready.

What's the difference between A.5.15, A.5.16, A.5.17 and A.5.18?

A.5.15 is the access policy and the process around it. A.5.16 is identity management. A.5.17 covers authentication information. A.5.18 is the access rights themselves — provisioning, periodic review and revocation.

How often should access rights be reviewed?

The standard doesn't set an interval — it requires that you set one and follow it. What matters to an auditor is that the interval is written into the controlled process.