Access request process flowchart

What the access request process is

An access request process is how someone gets the access they need to do their job without the organisation losing track of who can do what. It starts with a request for a defined role rather than a shopping list of individual permissions, passes through approval by the person accountable for the requester and the person accountable for the system, and ends with an entitlement recorded in a register that carries a date for its next review.

The steps most often skipped are the ones that turn into audit findings later. A segregation of duties check stops one person holding two roles that were never meant to sit together, such as creating a supplier and paying it. A separate security review keeps administrator and sensitive-data access off the same approval path as a read-only report. And recertification is the only reason the register stays true: without a scheduled review, access accumulates every time someone changes team, and nothing is ever removed.

This template maps the full request-to-recertification flow across five lanes, namely Requester, Line manager, System or data owner, IT service desk and Security. It includes the two branch points teams argue about most, which are what happens when a requested role conflicts with access the person already holds, and which requests need security review before provisioning. It closes the loop with a scheduled review that either reconfirms the access or revokes it. The structure follows the pattern set by ISO/IEC 27001:2022 Annex A controls on access control (A.5.15), identity management (A.5.16) and access rights (A.5.18).

What this flowchart covers

In this template

• Request in the Requester lane: raise an access request, then select a defined role from the access catalogue with a business justification and an end date where the access is temporary.
• Two approval gates before any technical check: the line manager approves or rejects, then the system or data owner reviews the entitlements the role actually grants and approves or rejects. Both rejection branches end at a single "Request declined and closed" node.
• A "Segregation of duties conflict?" decision in the IT service desk lane, with a conflict branch that returns the request to the system owner to amend scope or add a mitigating control, then re-checks rather than waving it through.
• A "Privileged or sensitive access?" decision that routes administrator and high-risk requests to a separate security approval, while ordinary requests continue straight to provisioning.
• Provisioning and record keeping: provision with least privilege, confirm the access to the requester, have the requester acknowledge acceptable use terms, and record the entitlement in the access register.
• The recertification loop in the final column: Security starts a scheduled review, the system owner decides whether the access is still required, and the "No" branch revokes access in the target system and updates the register.

When to use this template

• Writing or reviewing an access control procedure for ISO 27001, SOC 2 or an internal audit, where you need one agreed picture of who approves what and what gets recorded.
• Configuring a request workflow in a service desk or identity governance tool, so the tool encodes a process people have agreed rather than inventing one during implementation.
• Answering an auditor or a customer security questionnaire asking how access is requested, approved, provisioned and reviewed.
• Briefing new approvers, particularly line managers and system owners who need to know what they are actually signing for and what happens if they sit on it.
• Tackling access creep after a review turned up accounts holding entitlements nobody could explain or attribute to an approval.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.