Access Request Approval Workflow: A Practical Design
A secure, fast workflow for access requests — what to ask for, who approves (the manager and the data owner), time-limited access, separation of duties, provisioning, and periodic access reviews.
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.
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.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
LLM Tool Calling for Internal Assistants: Design Choices
How to give an internal AI assistant tools — reading workspace data with the user's permissions, formatting results for the model, native function calling vs a routing step, limits on how many tools run, and answers that stay inside the data.
IT Asset Management for Small Companies: A Lightweight Approach
A practical IT asset management setup for small companies — what to track, one record per asset, lifecycle states from purchase to disposal, linking assets to people and requests, and the security reasons it matters.
Caching LLM Responses Safely: What to Cache and What Never To
Caching LLM answers saves tokens and latency — and can leak one user's data to another if done carelessly. A safe design: cache only answers that are identical for everyone, key on normalized question plus content version, expire, and lock the cache down.