Access Request Approval Workflow: A Practical Design

A good access request approval workflow captures what is needed, why and for how long; routes approval to the person who owns the data (and the requester's manager when the role changes); grants the least privilege that does the job, ideally time-limited; keeps the approver and the requester separate; and records everything so access can be reviewed and removed later. Standard access that every person in a role gets shouldn't need approval at all — it belongs in the role's onboarding template.

Why access requests need a workflow

Access requests are frequent, sensitive and easy to get wrong in both directions:

Too slow — people wait days for a shared folder, and work stops.
Too loose — access is granted on a chat message, never reviewed, and accumulates for years.

A workflow fixes both: routine requests move fast because the path is known, and sensitive ones get the right approver with an audit trail.

Step 1: capture the right information

The request form should ask for exactly what an approver needs to decide:

What — the system, folder or application, and the level (read, edit, admin).
Why — one line: "I'm taking over the Q4 budget from Priya."
For how long — permanent (while in this role) or until a date.
For whom — usually the requester; if someone requests for another person, capture both.

Pick-lists for common systems prevent "access to the thing Sam uses". Access to anything unusual can be free text.

Step 2: route to the right approver

Two approvers commonly matter:

The data or system owner — the person accountable for who can see the finance drive or the customer database. They know whether the access is appropriate.
The requester's manager — for access that expands someone's role, or where the owner doesn't know the requester.

Routing rules:

Access	Approver
In the requester's role template	None — granted automatically at onboarding
Read access to a team resource	Resource owner
Edit access to sensitive data (finance, HR, customer data)	Resource owner + requester's manager
Admin or privileged access	Resource owner + manager + security or IT lead

Keep approvals to one or two people. Each additional approver adds delay and diffuses responsibility.

An access request form you can copy

The fields above as a template for a form, a spreadsheet row or a request desk category. The decision and provisioning lines are filled in by other people than the requester, which is the point:

ACCESS REQUEST
Requester:          <name>             For (if someone else): <name>
System or resource: <pick-list>        Access level: read / edit / admin
Why:                <one line: the task or project>
Needed until:       <date>  or  "while in this role"

APPROVAL (filled in by the system or the approver)
Approvers needed:   resource owner
                    + requester's manager, if sensitive data
                    + security or IT lead, if admin or privileged
Decision:           approved / declined / more information needed
Decided by:         <name>             On: <date>

PROVISIONING (filled in by IT)
Granted by:         <name>             On: <date>
Expires:            <date>             Next review: <date>

Step 3: separation of duties

The person who benefits from access shouldn't approve it, and ideally the person who approves shouldn't be the one who provisions it. Separation of duties is a long-standing control principle: no single person should be able to both request and grant sensitive access. In practice:

Nobody approves their own request — enforce it in the system, not by policy.
Admins requesting admin access still need a second approver.
Provisioning is recorded separately from approval.

LetRelay applies the same principle to leave: nobody can approve their own leave, enforced in the database. The same enforcement technique — checking the approver against the requester at write time — works for access requests. See role-based access for internal tools.

Step 4: least privilege, preferably temporary

Grant the minimum that does the job. NIST defines least privilege as granting only the access needed to perform assigned tasks. Practical forms:

Read before edit. Most "I need access" requests are satisfied by read access.
Group-based access. Add the person to a group that has the right permissions, rather than granting permissions to them individually — removal is then one step.
Time-limited access. For projects, cover, and privileged access, set an end date at grant time. Access that expires automatically never needs remembering.

Step 5: provision and confirm

After approval:

Provision — add to the group, assign the licence, share the folder.
Confirm with the requester that it works.
Record on the request what was granted, when, by whom, and when it expires.

Where your identity provider or SaaS tools support automated provisioning, approved requests can trigger it directly. Where they don't, a checklist on the request keeps manual steps consistent.

Step 6: review periodically

Access accumulates. Periodic access reviews ask each resource owner: "These people have access to your system — do they still need it?" Microsoft's documentation on access reviews describes the purpose: ensuring only the right people have continued access. For a small company:

Quarterly for sensitive systems (finance, HR, admin roles).
Yearly for everything else.
On every role change — a move between teams should remove old access as well as add new. See the offboarding checklist.

Record the review outcome. Access nobody confirms is removed.

Targets and speed

Access requests often block work, so give them a clear target — for example, one business day for standard access and three when an owner's approval is needed. Show the approver's pending requests prominently and remind them once before the target. Measure where time goes: waiting for approval, or waiting for provisioning. The SLA tracking guide covers targets; the waiting-on-another-team problem is covered in SLA vs OLA vs KPI.

Common mistakes

Approval by chat message. It can't be audited and nobody can find it later. Approvals happen on the request.
"Same as Sam". Copying another person's access copies years of accumulated exceptions. Grant from the role template plus specific, approved additions.
Permanent project access. Every project ends; set the end date when you grant.
Approvers who don't know the data. A manager approving database access they don't understand is a rubber stamp. The data owner must be in the loop for sensitive systems.
No path for urgent access. Without a defined emergency route (a named approver on call, time-limited access, review the next day), people will find an undefined one.

A worked example

Priya in marketing needs edit access to the brand assets folder for a campaign ending 31 December.

She files an Access request: "Brand assets folder — edit — campaign work — until 31 Dec."
The folder's owner, the design lead, gets the approval; Priya's manager is informed but not asked, because it's within her team's normal work.
The design lead approves in one click. IT adds Priya to the "brand-assets-editors" group with an expiry of 31 December.
Priya confirms it works. Total time: three hours.
On 1 January the membership expires automatically. The quarterly review of the folder shows no stray access.

FAQ

Who should approve access requests?

The owner of the data or system, plus the requester's manager when the access expands their role. Privileged access typically also needs IT or security approval.

What should an access request include?

The system and access level, the business reason, the duration, and who the access is for.

How do you prevent people approving their own access?

Enforce it in the system: reject any approval where the approver is the requester, and require a second approver for privileged access.

How often should access be reviewed?

Quarterly for sensitive systems, yearly for others, and whenever someone changes role or leaves.

Is there an approval workflow template for access requests?

Yes: the form above is the whole template. Four things to capture (what, why, for how long, for whom), an approver chosen by the routing table, a recorded decision, and a provisioning line with an expiry and a review date. Use it as a request desk category, a form or a spreadsheet; what matters is that approval happens on the request, not in a chat message.

How long should an access request take to approve?

Set a clear target because access requests usually block work: for example one business day for standard access and up to three when an owner's approval is needed. Remind the approver once before the target, and measure whether time goes to approval or to provisioning.