A status label that shows where an access request sits in its lifecycle, such as submitted, assigned, in review, or closed. In identity programmes, the label only has control value when each state maps to a specific decision, owner, and evidence requirement.
What Access Request Status Tells You
Access request status is more than a workflow label. It tells readers whether a request is waiting for intake, ownership, review, approval, fulfilment, or closure, and whether the request is still actionable or already resolved.
That makes status a control surface as well as a convenience field. A label is only useful when the state is defined consistently enough that people can tell who owns the next step and what evidence should exist at that step.
How Status Supports Access Governance
In identity programmes, status helps convert a request from a generic ticket into a governed decision path. It can indicate whether the request is new, assigned, escalated, approved, rejected, completed, or cancelled, and each state should imply a different operational responsibility.
When the status model is weak, reviewers can lose sight of where a request sits in the lifecycle. That often creates ambiguity around handoffs, delays in fulfilment, and uncertainty about whether an access decision was actually made or only discussed.
Good status design is closely tied to workflow clarity. For example, a request marked as in review should point to an active decision point, while closed should mean the request reached a documented end state, not simply that a ticket was dismissed.
NHIMG’s IAM and IGA Basics provides the broader identity governance context for how request states connect to provisioning, access reviews, and entitlement control.
Common Status States and What They Mean
Although vendors name states differently, most access request systems use a small set of lifecycle labels. Submitted usually means the request has entered the queue. Assigned means an owner or approver has been attached. In review means decisioning is underway. Approved or rejected reflects the decision. Fulfilled means access has been provisioned, and closed means the request has reached its administrative end.
The important point is not the label itself but the decision model behind it. A useful status map should distinguish pending work from completed work and should not overload a single label with both operational and governance meaning.
Some organisations also use states such as on hold, escalated, or returned for more information. Those variants can be helpful when they make ownership and next action explicit, but they become noise if they do not change how the request is handled.
Status is also related to evidence and accountability. If a request reaches closure without a decision record, an approver identity, or a fulfilment trail, the status says little about the actual control outcome.
Why Status Quality Matters for Auditability
Access request status becomes valuable when it supports traceability across the full lifecycle. A stable status model lets teams answer basic questions quickly: who owns the request, what is the current decision point, what action is pending, and what proof exists that the request was handled correctly.
This is why status terminology should be aligned with workflow design rather than left to free text or ad hoc tagging. If one team uses closed for approved requests and another uses it for rejected requests, the reporting layer becomes unreliable even if the underlying tickets were processed correctly.
For auditors and reviewers, status also helps separate control execution from control intent. A request may be submitted, but unless the status transitions are tied to defined evidence and explicit decisions, the label alone does not demonstrate effective access governance.
Risk and Threat Considerations
Weak or inconsistent request status handling can hide delayed approvals, orphaned requests, and incomplete fulfilment. It can also make it easier for access to be granted, changed, or left pending without a clear owner, which reduces visibility and weakens governance over the request lifecycle.
Failure mechanism: Status labels that are not tied to explicit decision points, owners, and evidence requirements can let stale or ambiguous requests persist unnoticed, especially in high-volume access workflows.
Impact: The result can be excessive access, missed approvals, poor audit evidence, and reduced confidence that access decisions were actually controlled.
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-3 — Access Enforcement | Access request status supports controlled approval and enforcement of who gets access. |
| AU-2 — Event Logging | Request lifecycle states depend on logged transitions for auditability and review. | |
| IA-5 — Authenticator Management | Request closure and fulfilment often depend on credential or secret provisioning events. | |
| Recommendation — Tie request states to AC-3 decision points before access is granted or changed. Log each status transition so reviewers can reconstruct the access decision trail. Track credential-related fulfilment events under IA-5 when requests change access material. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Status handling is part of managing access requests under an access-control policy. |
| A.5.18 — Access rights | Access request states are used to govern granting, modifying, and revoking access rights. | |
| Recommendation — Define request state handling under A.5.15 so approvals and closures are consistent. Use A.5.18 to ensure every state transition maps to a controlled access-right action. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access requests are a core account-management workflow that needs state tracking and ownership. |
| Recommendation — Standardise request states under CIS-5 to keep account changes traceable. | ||
Practitioner Guidance
Governance implication: Treat access request status as a controlled lifecycle model, not a cosmetic field. Each state should have a clear owner, a defined exit condition, and a predictable evidence trail so that reporting and review can rely on the same meaning everywhere.
What to watch for: Statuses that accumulate without movement, repeated reassignment, or closure without fulfilment records usually signal process drift rather than healthy queue management. The most useful status models are the ones that make exceptions easy to spot and hard to ignore.