ISO 27001 access control flowchart (Annex A.5.15)

What the iso 27001 access control flowchart (annex a.5.15) process is

Access control rarely goes wrong at the point of provisioning. It goes wrong afterward: an employee changes department and keeps the old rights, a contractor's account stays open three months after the engagement ends, and nobody can point to who approved it in the first place. That is exactly why Annex A.5.15 is written around the full lifecycle, not around having a procedure for creating users.

A useful flowchart therefore separates two approvals that tend to blur together in practice: the business approval, where the system or data owner decides whether the role should have the access at all, and the technical provisioning, where IT carries out that decision at least privilege. Putting the two steps in separate lanes makes it visible that IT never grants anything without a documented decision behind it.

The diagram also needs its failure paths: a rejected request, a request for privileged access that requires an extra approval, and a right that gets removed at a periodic review. Those are the branches an auditor samples, and a happy path with no branching cannot document any of them.

What this flowchart covers

In this template

• The request stage: who may request access, what role and justification must be supplied, and how the request is logged with a trail back to the requester
• Business approval by the system or data owner, kept separate from technical provisioning, so nobody can approve and provision their own access
• Identity and role management under A.5.16: one unique identity per user, and provisioning at least privilege rather than copying a colleague's rights
• Authentication credential handling under A.5.17: issuing a password or key, requiring MFA, and a separate branch for privileged accounts
• Periodic review of rights under A.5.18, with attestation by the owner and a branch where unjustified access is removed and documented
• Change and termination: adjusting access on an internal role change, and revoking every access on termination within a set deadline, including contractors and service accounts

When to use this template

• You're preparing for an ISO 27001 certification or a surveillance audit and need to show access control as a controlled, approved process
• Access gets granted over Slack or in the hallway in practice, and nobody can later document who approved what
• You run periodic access reviews but have no diagram showing what actually happens when a right can't be justified
• Employees change department without losing their old rights, and you need to see where the internal-transfer path is missing
• Both ISO 27001 and SOC 2 ask about access control, and you want to document the process once instead of twice

Controls documented

• A.5.15
• A.5.16
• A.5.17
• A.5.18

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.