Category: Authorization Concepts

Access Request

Also known as: Access Request System

Simply put

An access request is the process by which a user asks for permission to use a specific resource, system, application, or set of information within an organization. It is typically the starting point for granting someone the access they need to do their job, and in most deployments the request is reviewed and approved before any access is actually provisioned.

Formal definition

An access request is a user-initiated activity within identity governance and administration (IGA) in which a principal seeks authorization to access specific resources, systems, applications, or data in an IT infrastructure. It is an administrative, lifecycle-oriented workflow, commonly routed for approval by designated stakeholders (which may include business, HR, or legal reviewers depending on the resource and organizational policy) before entitlements are provisioned, and is distinct from runtime access enforcement such as token validation or PDP/PEP evaluation. Note that the terminology overlaps with, but should not be conflated with, a data subject access request (DSAR) under privacy regimes, which is a request by an individual to obtain their own personal data rather than an entitlement to operate a system.

Why it matters

The access request is typically the entry point of the joiner-mover-leaver lifecycle within identity governance and administration (IGA). Because it is the moment where a principal formally seeks authorization to a resource, system, application, or data, it is where organizations have the opportunity to enforce policy before any entitlement is provisioned. A well-structured access request workflow creates the audit trail that later feeds access certifications, segregation-of-duties checks, and compliance reporting; a weak or informal one produces standing access that no one can later justify.

The review-before-provisioning pattern is what distinguishes a governed access request from ad hoc grants. In most deployments, requests are routed to designated stakeholders for approval, and depending on the resource and organizational policy those reviewers may include business owners, HR, or legal. For example, some institutions require that non-emergency requests to access another user's data be approved by both HR and Legal before access is granted, reflecting how sensitive resources can carry heavier approval requirements than routine application access.

A recurring point of confusion is terminological rather than technical: an access request in the IGA sense is not the same as a data subject access request (DSAR) under privacy regimes. A DSAR is an individual asking an organization for their own personal data (or, in some services, the data of a child or relative), whereas an IGA access request seeks an entitlement to operate a system. Conflating the two can misdirect workflows, ownership, and compliance obligations, so teams should keep the distinction explicit.

Who it's relevant to

IGA and Identity Governance Leads

Access requests are typically the front end of the entitlement lifecycle these teams own. They design the request-and-approval workflows, define which stakeholders review which resources, and ensure that the resulting records support downstream access reviews and certification.

IAM Engineers and Administrators

Engineers implement the access request system that manages and controls who can access data, applications, systems, or physical locations, and connect approved requests to the provisioning that grants entitlements. They must keep this administrative workflow cleanly separated from runtime enforcement components.

Compliance and Audit Officers

Because access requests capture who asked for what and who approved it, they provide the audit trail compliance teams rely on. This is especially relevant where policy mandates specific reviewers, such as HR and Legal approval before one user's data is accessed by another.

Business, HR, and Legal Reviewers

Depending on the resource and organizational policy, these stakeholders act as approvers in the workflow. Their sign-off is the control that determines whether requested access is provisioned, particularly for sensitive resources that require multi-party review.

Privacy and Data Protection Teams

These teams must distinguish an IGA access request from a data subject access request (DSAR), which is an individual asking an organization for their own personal data or that of a child or relative. Keeping the two workflows separate avoids misrouting privacy obligations into entitlement processes.

Inside Access Request

Requester and target identity

The principal (typically a user, but sometimes a service or non-human identity) for whom access is being requested, and the account or identity to which the access will be granted. In delegated scenarios the requester and the beneficiary may differ.

Requested entitlement

The specific access being sought, such as a role (in RBAC), an application account, a group membership, or an entitlement mapped to permissions. The granularity depends on how the target system models access.

Business justification

The stated reason or context for the request, used to support downstream approval and later access certification. This is an IGA lifecycle artifact, distinct from any runtime enforcement decision.

Approval workflow

The sequence of approvers or automated policy checks the request must pass, which may include manager approval, resource owner approval, and segregation-of-duties (SoD) evaluation, depending on configuration.

Policy and SoD evaluation

Checks applied against governance policy, including segregation-of-duties conflict detection, to determine whether granting the request would create a prohibited combination of access.

Fulfillment and provisioning outcome

The step where an approved request results in provisioning of the entitlement to the target system, often via connectors or SCIM in many deployments. This is a lifecycle administration action, separate from runtime authorization enforcement.

Duration and scope attributes

Optional parameters such as time-bound or temporary access, and the scope of the entitlement, where the environment supports expiring or just-in-time grants.

Audit record

The recorded trail of who requested what, when, why, who approved it, and how it was fulfilled, supporting later access reviews and certification.

Common questions

Answers to the questions practitioners most commonly ask about Access Request.

Is submitting an access request the same as being granted access?

No. An access request is a formal ask for entitlements, typically routed through an approval and review workflow. It represents an intent, not an outcome. The request must still be evaluated, approved by the appropriate authorities, and provisioned before any access exists. In most IGA deployments, a request can be denied, partially fulfilled, or expire without ever resulting in granted entitlements.

Does an approved access request handle authentication when the user later signs in?

No. Access requests are an identity governance and administration (IGA) concern focused on determining and provisioning what entitlements a principal should hold. They do not authenticate the user. When the user later accesses a system, authentication (verifying who the principal is) and runtime authorization enforcement (a PDP/PEP evaluating whether the granted entitlements apply) are separate steps handled by different components. The access request only shapes the entitlements that enforcement will later reference.

How does an access request typically flow from submission to fulfillment?

In most IGA deployments, a requester (or someone acting on their behalf) selects the desired access, the request is routed to one or more approvers based on configured policy, and upon approval the entitlement is provisioned to the target system, often via connectors or SCIM. The specific stages, approval tiers, and whether provisioning is automated or manual vary by vendor and configuration.

How can segregation of duties be enforced during the access request process?

Many IGA platforms evaluate segregation of duties (SoD) policies at request time, checking whether the requested entitlement would create a toxic combination with entitlements the principal already holds or has pending. Depending on configuration, a violation may block the request, require additional approval, or record a documented exception. Enforcement effectiveness depends on how completely SoD rules and entitlement data are modeled.

What is the relationship between access requests and access certification?

They are distinct IGA activities. Access requests grant entitlements at the moment of need, while access certification (or review) periodically re-validates entitlements a principal already holds. Requests are typically the front door for granting access; certifications are the recurring control that catches accumulated or no-longer-needed access, including entitlements that may have been granted through earlier requests.

How are time-bound or just-in-time entitlements handled through access requests?

Some deployments support requests that grant access for a defined duration, after which the entitlement is automatically deprovisioned or revoked. This can align access requests with just-in-time access patterns, reducing standing privilege. Availability, expiration handling, and automatic revocation behavior depend on the platform and how the workflow is configured.

Common misconceptions

An approved access request immediately changes what a user can do at runtime.

An access request is an identity governance and administration (IGA) construct. Approval typically triggers provisioning of an entitlement, but real-time enforcement is still handled separately by runtime components such as a PDP and PEP evaluating the resulting access at the time of a request. Provisioning latency and enforcement caching can mean the two are not simultaneous.

An access request is a form of authentication or verifies who the requester is.

An access request concerns authorization and lifecycle administration, not authentication. It presumes the requester has already been identified and authenticated by a separate mechanism; the request itself governs what access may be granted, not who the principal is.

Requesting a role is the same regardless of access control model.

What an access request grants depends on the underlying model. In RBAC it maps to a role, but in ABAC or PBAC access may be determined dynamically by attributes or policy rather than by a statically provisioned entitlement, so a request-and-fulfill pattern applies differently across models.

Best practices

Require a business justification on each request and preserve it in the audit record so it can be reused during periodic access reviews and certification.

Enforce segregation-of-duties evaluation within the approval workflow to detect and prevent toxic combinations of access before fulfillment.

Prefer time-bound or just-in-time access for sensitive entitlements where the environment supports expiration, to reduce standing privilege.

Route approvals to the appropriate authority, such as resource or data owners rather than only line managers, depending on the sensitivity of the requested entitlement.

Automate provisioning through standardized connectors or SCIM where possible to reduce manual fulfillment errors, while confirming that provisioning completion is reliably reflected back into governance records.

Maintain a complete, tamper-resistant audit trail of requests, approvals, and fulfillment outcomes to support access certification and compliance reporting.