Access request process flowchart
Access request process flowchart: role-based request, line manager and system owner approval, segregation of duties check, provisioning and recertification.
How it works
Name your real approvers
Rename the five lanes to the roles you have. In smaller organisations the system owner and security reviewer are often the same person; merge those lanes rather than drawing an approval that never happens. Keep one lane per decision-maker, not per individual, so the chart survives someone changing job.
Define what counts as privileged or sensitive
The "Privileged or sensitive access?" decision only works if the criteria are written down next to it. Typical triggers are administrator and root accounts, service accounts, access to personal or financial data, and anything that can change production. Set the bar so the security branch fires on a minority of requests, or it becomes a rubber stamp.
Write down your segregation of duties rules
List the combinations no one person may hold, for example raising a supplier and approving payment, or writing code and releasing it to production. Without that matrix the conflict check is theatre. Also decide who signs off a mitigating control when the conflict is unavoidable, and record it against the entitlement.
Decide where the access register lives
Point the register step at the system you will actually maintain, whether that is an identity governance tool, your ITSM platform or a controlled spreadsheet. Make sure the revoke branch updates the same record, otherwise the register slowly becomes a list of access that was granted rather than access that exists.
Set the recertification cadence and its owner
Replace the generic scheduled review with your own frequency and trigger, for example privileged accounts quarterly and standard roles annually, plus an out-of-cycle review on role change. Name who chases reviewers and what happens when a review deadline passes, since an unowned review is the step that quietly stops running.
Get the map approved and keep one current version
Share the chart with the approvers named in it, capture their sign-off, and link the approved version from your access control policy. Keeping the diagram under version control with a recorded approval means the process people follow and the process you show an auditor are the same one.
Frequently asked questions
What is an access request process?
It is the defined route a request for system access takes from the moment someone asks for it to the moment it is granted, recorded and later reviewed. A complete process has four parts: a request that names a defined role and a business reason, approval by someone accountable for the person and someone accountable for the system, provisioning by whoever holds the administrative rights, and a record of the entitlement with a review date. Requesting and provisioning are deliberately separate steps performed by different people, so nobody grants themselves access.
Who should approve an access request?
Two approvers cover most situations. The line manager confirms the person needs the access for their job, which is a question about the requester. The system or data owner confirms what the role actually grants and whether this person should hold it, which is a question about the system. A third approval from security is worth adding only for privileged or sensitive access, which is how this template routes it. Adding more approvers rarely improves the decision and reliably increases the time people wait, which is what drives informal workarounds such as password sharing.
What is a segregation of duties check in access management?
It tests whether the requested role, combined with access the person already holds, would let one individual complete a sensitive transaction end to end with no independent step. Common examples are creating a supplier and approving its payments, or writing code and releasing it to production. The check needs an agreed list of conflicting combinations to test against. When a conflict cannot be avoided, for example in a small team, the usual answer is a documented compensating control such as an after-the-fact review by someone else, recorded against the entitlement.
How often should user access be recertified?
Risk should set the frequency. A common pattern is quarterly for privileged and administrator accounts, annually for standard business roles, and an immediate out-of-cycle review whenever someone changes role or team. ISO/IEC 27001:2022 control A.5.18 requires access rights to be reviewed regularly but does not prescribe an interval, so the frequency is yours to justify. Note that a flowchart documents intent rather than proving compliance: the evidence an auditor asks for is the approvals and the register the process produces.