Access request process map

A swimlane map of a user access request from submission to provisioning and periodic recertification, across the requester, the line manager, the system or data owner, the IT service desk and security. Its structure is built around one rule: nobody both approves and grants their own access.

Open this map in the editor

Opens a copy in the editor and saves it in this browser. No account, nothing sent anywhere.

What is in this map

20 steps across 5 swimlanes and 5 phases, with 6 decision points.

Swimlanes (who does the work): Requester, Line manager, System or data owner, IT service desk and Security
Phases (left to right): Request, Approval, Checks and review, Provisioning and Recertification

Why map this process

Access requests are the most-run process in most IT departments and the least documented, because each individual request is small. The consequence shows up years later as accumulated rights nobody can justify: the person who moved teams three times and kept every permission. That accumulation is not caused by bad provisioning; it is caused by there being no mapped step that ever takes access away.

So the map is drawn to include recertification as part of the same process rather than as a separate annual project. Once the review sits on the same page as the grant, it becomes obvious that they are two halves of one lifecycle, and that a process which only ever adds is not a process at all.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

Every step in the Access request process (user access provisioning) process map, in the order the editor numbers them.
#	Step	Shape	Swimlane	Phase	Goes to
1	Raise access request	Start	Requester	Request	2
2	Select role and state justification	Process	Requester	Request	3
3	Line manager reviews the request	Process	Line manager	Approval	4
4	Line manager approves?	Decision	Line manager	Approval	5 (Approved), 6 (Rejected)
5	System owner reviews entitlements	Process	System or data owner	Approval	7
6	Request declined and closed	Reject	Requester	Approval	End
7	System owner approves access?	Decision	System or data owner	Approval	8 (Approved), 6 (Rejected)
8	Segregation of duties conflict?	Decision	IT service desk	Checks and review	9 (Conflict), 10 (None)
9	Amend scope or add mitigating control	Process	System or data owner	Checks and review	8 (Re-check)
10	Privileged or sensitive access?	Decision	IT service desk	Checks and review	11 (Yes), 12 (No)
11	Security approves privileged access?	Decision	Security	Checks and review	12 (Approved), 6 (Rejected)
12	Provision access with least privilege	Process	IT service desk	Provisioning	13
13	Confirm access to the requester	Process	IT service desk	Provisioning	14
14	Acknowledge acceptable use terms	Process	Requester	Provisioning	15
15	Record entitlement in the access register	Registry	IT service desk	Provisioning	16
16	Start scheduled access recertification	Timer	Security	Recertification	17
17	Access still required?	Decision	System or data owner	Recertification	18 (Yes), 19 (No)
18	Access reconfirmed for next period	Success	System or data owner	Recertification	End
19	Revoke access in the target system	Process	IT service desk	Recertification	20
20	Access removed and register updated	End	IT service desk	Recertification	End

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

4. Line manager **approves?**

Owned by Line manager · Approval
- Approved → step 5
- Rejected → step 6
7. System owner **approves access?**

Owned by System or data owner · Approval
- Approved → step 8
- Rejected → step 6
8. *Segregation of duties* conflict?

Owned by IT service desk · Checks and review
- Conflict → step 9
- None → step 10
10. **Privileged or sensitive** access?

Owned by IT service desk · Checks and review
- Yes → step 11
- No → step 12
11. Security **approves privileged access?**

Owned by Security · Checks and review
- Approved → step 12
- Rejected → step 6
17. Access still required?

Owned by System or data owner · Recertification
- Yes → step 18
- No → step 19

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

2. Select role and state justification: Request a defined role from the access catalogue, not a list of individual permissions. Capture the system, the role, the business reason and an end date if the access is temporary.
8. *Segregation of duties* conflict?: Test the requested role against the combinations the organisation has agreed no one person may hold, for example raising a supplier and paying it, or writing code and releasing it to production.
15. Record entitlement in the access register: One row per entitlement: user, system, role, who approved it, the date granted, any expiry and the next review date. This register is what a reviewer or auditor actually asks to see.
16. Start scheduled access recertification: Set the cadence by risk rather than reviewing everything at once, for example privileged accounts quarterly and standard roles annually. Reviews with no deadline and no escalation get rubber-stamped.

Making it yours

Keep business approval and technical provisioning in different lanes. That separation is the control, and it survives every adaptation. Beyond that, the branch to watch is privileged access: add a decision before provisioning that routes admin and production access through the security lane for an extra approval, and put the validity period in the Notes column on that branch rather than in a policy.

What to watch out for

A request for access to a system that has no named owner has nowhere to go on this map, which is a finding rather than a modelling problem: the map is telling you the owner list is incomplete.
Do not draw provisioning as a single step if access is granted in several systems by several teams. Either give each a row or accept that the map cannot show which system is late.
Removal on role change is the branch everyone omits. An internal move should adjust access, not add to it, and that only happens if there is a step that explicitly removes the old rights.

Frequently asked questions

Who should approve an access request, the manager or the system owner?

Both, for different reasons. The line manager confirms the person needs it for their job; the system or data owner decides whether that justification is sufficient for their system. This map keeps them as two steps in two lanes because collapsing them means one person is deciding both, which is exactly what segregation of duties is meant to prevent.

How often should the recertification step run?

The map does not prescribe an interval; it prescribes that there is one and that it is written down. Most organisations review privileged access quarterly and standard access annually. Put your own figure in the Notes column on the recertification step so the map states your rule rather than a generic one.

How does this relate to onboarding and offboarding?

Onboarding creates the first access request and offboarding triggers the removal, so this map is the middle of a lifecycle those two bracket. Drawing it separately keeps it usable for the far more common case (an existing employee needing access to one more system), which is not an onboarding event at all.

Open the map and start editing

The editor loads this chart with the spreadsheet underneath it. Change a cell and the diagram redraws — no drawing, no signup.

Open this map in the editor