An Access Request is a formal request for a user, service, or machine identity to gain a specific permission or entitlement. Attackers abuse weak approval workflows to obtain excessive access, while defenders use it to enforce least privilege. Reviewers should check business need, duration, and role fit before approval.
What an access request actually does
An access request is the formal control point between a need for access and an approved entitlement. It records who is asking, what permission is being requested, why it is needed, and whether the request fits policy before access is granted.
That makes the request more than a ticket. It is the point where an organisation can separate legitimate business need from convenience, and where approval quality starts to shape the security posture of the whole access model.
Why access requests matter in identity governance
Access requests sit inside the broader identity lifecycle, because they often precede provisioning, role assignment, or exception approval. A well-run request process helps keep entitlements aligned to job function, application need, and time-bound access rather than leaving permissions to accumulate.
For that reason, access request handling is closely tied to entitlement management and access reviews. IAM and IGA Basics is a useful reference for the surrounding governance model, especially where requests must be checked against roles, SoD rules, and least-privilege policy.
What makes a request valid or invalid
Not every request should be approved just because it comes from a real user or team. Reviewers need to confirm the business purpose, the specific entitlement being asked for, the expected duration, and whether the request aligns with the requester’s role or delegated responsibility.
Valid requests are usually narrow, explainable, and traceable to a task or control objective. Invalid ones tend to be overbroad, open-ended, or detached from the requester’s function. The difference matters because access review quality depends on the quality of the request that created the permission in the first place.
Where the request involves regulated personal data workflows, the approval process may also need stronger identity checks and careful handling of evidence. DSAR Guide: Handling Data Subject Requests shows how request handling becomes more sensitive when access to records, logs, or case data is involved.
How access requests reduce privilege creep
Access requests help prevent privilege creep when they are paired with role design, expiry dates, and periodic recertification. They also provide an audit trail that explains why a permission exists, which is essential when organisations later need to question whether an entitlement is still justified.
Request workflows are often the place where machine and service access should be treated with the same discipline as human access. The entitlement may be technical rather than personal, but the control objective is the same: grant only the minimum access needed, for the shortest necessary time, with a reviewer who can challenge the default path.
Risk and Threat Considerations
Access requests become risky when approval is treated as a formality, because weak review can turn a routine request into excessive privilege, persistent overreach, or an easy path to lateral movement. Attackers often target request and approval workflows because they can look legitimate while bypassing stronger direct controls.
Failure mechanism: Inadequate validation of business need, role fit, or expiry allows a request to be approved with more access than the requester should receive, or to remain active long after the need has passed.
Impact: Excessive or stale access can expose sensitive systems and data, increase the blast radius of compromise, and make later remediation slower because the approval trail appears legitimate even when the entitlement is not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Access requests grant entitlements, so least privilege directly governs approval scope. |
| AC-2 — Account Management | Access requests are part of creating, changing, and removing account access. | |
| AC-3 — Access Enforcement | Requested permissions must be enforced consistently after approval. | |
| Recommendation — Approve only the minimum entitlement needed for the task. Tie approvals to account lifecycle events and remove access when it is no longer justified. Enforce the approved entitlement exactly as granted, without informal expansion. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access requests support controlled account and entitlement assignment. |
| Recommendation — Use standardized approval workflows for account and entitlement changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access requests are a core access-control process under Annex A. |
| Recommendation — Define and operate a formal process for requesting and approving access. | ||
Practitioner Guidance
Governance implication: Treat access requests as a governed decision, not an administrative queue. The approver should be able to justify the permission in business terms, and the workflow should preserve enough context to explain why the access was granted.
What to watch for: Requests with vague justification, broad entitlements, repeated exceptions, or no expiry are the usual warning signs that the request process is drifting away from least privilege. If those patterns appear often, the issue is usually in the approval model, not just the ticketing tool.