Access Request and Approval Workflow Design Guide

Most access request workflows approve almost everything, slowly, because the wrong person is asked the wrong question about an entitlement they cannot understand. The result is the worst of both outcomes: users wait days, approvers rubber-stamp, and auditors find that the approval trail proves nothing about need. Good workflow design decides what should be requestable at all, who is genuinely able to judge each request, how much scrutiny each risk level deserves, and how long access lasts. This guide covers catalogue design, approver selection, risk-tiered approval chains, service levels, rubber-stamping countermeasures, non-human identity requests and measurement. It is for IGA engineers, IAM product owners and control owners. Access reviews after the fact are covered in the Access Reviews Guide; this page is about the decision at the point of request.

Key takeaways

The approver must be able to say no. An approval only has control value when the approver has the knowledge, the information and the independence to refuse; otherwise it is a delay with a signature.
Tier approvals by risk. Low-risk access can be auto-approved or manager-approved; privileged, sensitive data and segregation of duties relevant access needs owner approval, justification and an expiry.
Design the catalogue before the workflow. Requestable items need business-readable names, descriptions, owners and risk ratings, or no approval chain will work.
Time-bound by default. Access that expires and must be extended removes most of the clean-up burden from reviews.
Measure approval quality, not just speed. Approval rate, time to decision and how often approved access is ever used reveal rubber-stamping faster than any audit.

What a request workflow must achieve

NIST SP 800-53 AC-2 requires organisations to require approvals by defined personnel for requests to create accounts, to authorise access based on a valid access authorisation and intended system usage, and to define prerequisites for group and role membership. AC-5 asks for access authorisations that support separation of duties. The NCSC's identity and access management guidance asks organisations to define who can access which systems and why, and to identify actions that should require more than one person. A workflow meets these when it produces four things for every grant:

A recorded business need: who asked, for what, why, and for how long.
An informed decision: by someone accountable for the access or the person, with the information to judge it.
Automated, accurate fulfilment: the exact entitlement approved, provisioned without manual re-keying.
An end: an expiry, a review or a lifecycle trigger that removes the access.

Designing the request catalogue

Users request what they can understand. If the catalogue lists "GRP-FIN-SAP-ZFI_AP_POST_02", both the requester and the approver are guessing.

Catalogue attribute	Purpose	Example
Business name and description	Lets requesters choose correctly and approvers judge	"Post supplier invoices in SAP (up to approval limit)"
Owner	The accountable approver for the access itself	Accounts payable manager
Risk rating	Drives the approval chain and expiry	High: financial transaction capability
Eligibility	Who may request at all	Finance department employees only
Incompatible access	Segregation of duties constraints	Cannot be held with "Create and amend supplier bank details"
Default duration	Time-bound access	365 days, extendable with approval
Bundle membership	Packages of entitlements for a job task	Part of "Accounts payable clerk" package

Request packages, not raw entitlements: bundle the groups, application roles and SaaS licences needed for a task into one requestable item. Microsoft Entra entitlement management calls these access packages; most IGA platforms have an equivalent. See the Entitlement Catalogue and Application Onboarding Guide and the Role Mining and Role Design Guide.

Birthright versus requestable: access every member of a population needs on day one (email, intranet, core collaboration) should be granted automatically by HR attributes, not requested. Requests should cover the exceptions. See the Joiner-Mover-Leaver Guide.

Choosing approvers

Approver	What they can judge	What they cannot judge	Use for
Line manager	Whether the person's job needs it; whether they are still on the team	What a technical entitlement actually allows	First stage for most requests
Resource or data owner	Whether this access to this resource is appropriate; data sensitivity	The requester's role and workload	Sensitive data, production systems, privileged roles
Security or control owner	Policy, SoD conflicts, privileged access standards	Business need	Privileged and SoD-relevant access, exceptions
Sponsor (for external users)	Whether the contract or relationship still exists	Internal entitlement detail	Contractors, partners, guests
Policy engine (auto-approve)	Rule-based eligibility, such as department and job code	Exceptions and context	Low-risk access within eligible populations

Approver design rules

No self-approval: requesters must never approve their own access. Microsoft's entitlement management, for example, prevents approvers from approving their own requests.
Fallbacks for missing managers: manager data is often wrong or empty; configure fallback approvers who receive the request when no manager is found, rather than letting it stall or auto-route to a generic queue. See the Identity Data Quality and Authoritative Sources Guide.
Groups, not individuals, for owner approval: one named owner on holiday blocks everyone; a small owner group with a rule that any one member approves keeps the decision informed.
Independence: for privileged access, the approver should not be in the same reporting line as the requester only, and should not be the person who will benefit from the work.

Risk-tiered approval chains

Risk tier	Examples	Approval	Justification	Duration
Low	Team sites, standard SaaS for the department	Auto-approve for eligible population, or manager	Optional	Until role change
Medium	Business application roles, shared drives with internal data	Manager	Required	12 months, extendable
High	Confidential data, finance transaction roles, production read	Manager then resource owner	Required, with ticket or project reference	6 to 12 months
Privileged	Admin roles, production write, security tooling admin	Manager, resource owner, then security; activate just in time	Required; approver justification also required	Eligibility time-bound; activation in hours
Non-human identity	New service account, API client, agent permissions	Requesting owner, platform owner, security for privileged scopes	Purpose, systems reached, credential type	Bound to project or workload lifetime

Multi-stage mechanics: Microsoft's entitlement management supports single-stage approval (any one listed approver decides) or multi-stage approval with first, second and third approvers, each stage with its own decision timeout and optional approver justification. If no decision is made in time, the request is denied and must be resubmitted. Alternate approvers can receive a request after a set number of days; Microsoft requires the stage timeout to be at least four days to use this. Other IGA platforms offer similar controls under different names.

Privileged access belongs in two decisions: approve eligibility for a role (who may hold it, for how long), then approve or self-activate each use just in time. See the JIT Access Guide and the Privileged Identity Management (PIM) Guide.

Segregation of duties at request time: block conflicting requests before approval rather than detecting them in a review. Microsoft's incompatible access packages and groups block requests from people who already hold the conflicting access, but the rule is one-way (configure both directions) and existing holders are not removed. See the Segregation of Duties Guide.

Service levels and expiry

Set decision targets per tier: for example, one working day for low and medium, three for high and privileged. Slow approvals drive people to shared accounts and out-of-band grants.
Escalate before expiring: forward to alternate approvers (such as a second-level manager) halfway through the timeout, then deny. A request that silently sits for weeks teaches users to go to the help desk instead.
Do not auto-approve on timeout: timing out to approval turns inattention into consent. Time out to denial with a clear message.
Default expiry: Microsoft's lifecycle settings allow assignments to expire on a date, after 0 to 3,660 days or a number of hours, or never; users can be allowed to extend, with reminder emails 14 days and 1 day before expiry, and extensions can require approval. Choose "never" only for birthright-like access.
Re-approval on change: a mover event should trigger review or removal of requested access tied to the previous role.

Defeating rubber-stamping

Rubber-stamping happens when approvers lack information, time or accountability. Fix the causes:

Show context in the approval: what the access allows in plain language, its risk rating, whether peers in the same role have it, whether it creates an SoD conflict, and the requester's justification.
Reduce volume: auto-approve low-risk access for eligible populations so approvers see only decisions that matter.
Require approver justification for high risk: a short reason changes behaviour and gives auditors evidence.
Route to the right owner: a line manager approving a database admin role is not a meaningful control; add the resource owner.
Feed usage back: report to each approver how much of the access they approved was used in the following 90 days.
Sample and challenge: control owners periodically sample approvals for high-risk items and follow up on any that cannot be justified.

Requests for non-human identities

Service accounts, API clients and AI agents are often created by ticket with no structured request at all. Treat them as requestable items with their own form: owner and backup owner, purpose, systems and scopes required, credential type (prefer federation or managed identities over secrets), environment, expiry or review date and data classification. Microsoft's request policies can now include service principals and agents as eligible requesters through Microsoft Entra Agent ID, which shows the direction of travel: NHI access is joining the same governance process. See the NHI Ownership Guide and the Service Account Security Guide.

Implementation roadmap

Baseline (month 1): measure today's request volumes, approval rates, time to decision and how often requests are fulfilled outside the workflow (direct group adds, help desk tickets).
Catalogue the top 50 (months 1 to 3): rename, describe, risk-rate and assign owners to the most requested and highest-risk entitlements; build packages for common job tasks.
Configure tiers (months 2 to 4): implement the approval chains, timeouts, fallbacks and expiry per tier in the IGA or entitlement management platform. Pilot with one department.
Close side doors (months 3 to 6): alert on direct group and role changes made outside the workflow, and route help desk access requests into the catalogue. Keep an emergency path that is logged and reviewed.
Extend (months 6 to 12): onboard more applications, add NHI request forms and connect SoD rules.

Rollback: keep the previous workflow active for in-flight requests and switch only new requests to the new policies, so a misconfigured chain can be reverted without losing pending approvals. Small organisations may not need an IGA platform: a ticketing form with mandatory fields, manager plus owner approval for high-risk items and scripted provisioning can meet the same principles. Large organisations should standardise tier definitions centrally and let application owners choose only within them.

Detection and measurement

Out-of-band changes: group membership and role assignments made directly rather than by the workflow engine; Microsoft provides an "Application role assignment activity" workbook to show app role changes not made by entitlement management.
Self-approval attempts and approver-requester relationships that breach independence rules.
Help desk grants: access or MFA changes made by support staff on a phone call or chat, without a matching workflow request. Report these weekly to the control owner, check each against the caller verification record, and treat any privileged grant made this way as a potential incident until it is confirmed. See the Help Desk Social Engineering Incident Playbook.

Metric	Healthy signal	Warning sign
Approval rate by tier	Lower for high and privileged tiers	Close to 100% everywhere
Median time to decision	Within tier service level	Very fast decisions on high-risk items (seconds)
Approved access unused after 90 days	Low and falling	High, showing access granted "just in case"
Access granted outside the workflow	Near zero, all emergency and reviewed	Regular direct grants by admins
Requested access with an expiry date	All medium and above	Most set to never
Requests stalled for lack of an approver	Near zero	Frequent, pointing to bad manager data

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 (approval of account requests, authorisation by need), AC-2(1) Automated System Account Management	Approval and automated fulfilment
NIST SP 800-53 Rev 5	AC-5 Separation of Duties; AC-6 Least Privilege	SoD checks and least privilege at request
NIST CSF 2.0	PR.AA-05	Access permissions defined, managed, enforced and reviewed
CIS Controls v8.1	6.1 Establish an Access Granting Process; 6.8 Define and Maintain Role-Based Access Control	Process and roles
ISO/IEC 27001:2022 Annex A	A.5.15 Access control; A.5.18 Access rights; A.5.3 Segregation of duties	Policy, provisioning and SoD

Common failure patterns

Manager-only approval for everything: managers approve technical entitlements they cannot evaluate.
Timeout to approve: requests auto-approve when nobody answers, so silence becomes consent.
Entitlement names nobody understands: requesters ask for whatever a colleague has, approvers approve it.
Permanent requested access: no expiry, so access accumulates across moves and reviews become unmanageable.
Workflow with side doors: admins add people to groups directly "to save time", leaving the workflow as an audit artefact only.
NHIs outside the process: service accounts and API keys created by email or chat with no owner or expiry.

Lessons from incidents

Workflows are only as strong as their exceptions. In the MGM Resorts breach, the attackers' own account is that a phone call to the help desk got them into the identity platform. Any route that grants access or resets authentication outside the approved workflow, however urgent the caller sounds, needs the same identity verification and logging as the workflow itself.

Practitioner checklist

Give every requestable item a business name, description, owner, risk rating and default duration.
Bundle common job tasks into packages; grant birthright access automatically.
Define approval chains per risk tier, with resource owner approval for high and privileged access.
Block self-approval and configure fallback approvers for missing managers.
Time out to denial, with escalation to alternate approvers before the deadline.
Apply expiry to all medium-risk and higher access, with approval required to extend.
Check SoD conflicts at request time, in both directions.
Route NHI creation through a structured request with owner, scope and credential type.
Alert on access granted outside the workflow.
Report approval rate, time to decision and unused approved access to control owners monthly.

Access Request and Approval Workflow Design Guide: approvals that actually check something