An app requisition workflow is the governed process for requesting, approving, and recording access to a software application. Its purpose is to link demand, approval, and licence assignment so that access can be reviewed later and does not become an undocumented standing entitlement.
Expanded Definition
An app requisition workflow is the controlled path for requesting, validating, approving, and assigning access to an application, licence, or entitlement. In NHI and IAM practice, it matters because the request record becomes the evidence trail that explains why access existed, who approved it, and when it should be reviewed or removed.
The term is often used alongside access request, entitlement request, and provisioning workflow, but those are not always identical. An access request may cover any permission, while an app requisition workflow is usually narrower and more operational, tying business need to application ownership, license inventory, and downstream provisioning. In maturity models, it supports joiner-mover-leaver controls, segregation of duties, and auditability. Definitions vary across vendors, especially where the workflow spans SaaS, internal apps, and AI-enabled tools that can act as agents with delegated access. For a governance baseline, NIST Cybersecurity Framework 2.0 provides a useful control vocabulary for access governance and accountability.
The most common misapplication is treating a ticket creation step as approval, which occurs when the request is logged but no policy check, owner review, or entitlement traceability is enforced.
Examples and Use Cases
Implementing app requisition workflow rigorously often introduces approval latency and licence-management overhead, requiring organisations to weigh faster access against stronger governance and later auditability.
- A new analyst requests a SaaS reporting app through a portal, and the app owner approves only the standard role while finance confirms the licence is available.
- An engineer requests access to an internal deployment tool, and the workflow routes the request to the system owner because the app also exposes privileged automation functions.
- A contractor needs a collaboration app for 30 days, and the requisition includes an expiry date so access is revoked automatically when the engagement ends.
- An AI agent is granted access to a ticketing app through a requisition that records the delegated purpose, scope, and rollback conditions before activation.
- A quarterly access recertification uses prior requisition records to confirm that app access still matches job role and business justification.
NHIMG data shows that only 5.7% of organisations have full visibility into their service accounts, which is why application access records matter even when the user is not human. The broader NHI risk picture in Ultimate Guide to NHIs reinforces that visibility and governance are inseparable from provisioning discipline. In standards language, this aligns well with request, approve, and grant steps described in identity governance models and with the access review concepts in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
App requisition workflow is not just administrative overhead. It is one of the few practical ways to prevent entitlement sprawl, prove why an application was accessed, and support later removal when a service account, API key, or agent no longer needs it. Without a governed workflow, application access often becomes a standing entitlement that survives role changes, project closure, or offboarding.
That failure mode matters in NHI security because the blast radius is rarely limited to a single user. A weak requisition process can allow overprovisioned service accounts, orphaned licences, and unreviewed delegated access to persist across environments. NHIMG reports that 97% of NHIs carry excessive privileges, which makes poor request hygiene especially dangerous when applications are tied to automation or privileged tooling. The Ultimate Guide to NHIs also notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring why access provenance must be recorded from the start.
Organisations typically encounter the consequence only after an audit finding, an access-related incident, or a failed offboarding, at which point app requisition workflow becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access requests and approvals support least-privilege and access governance. |
| NIST SP 800-63 | AAL2 | Assurance concepts inform how strongly access to apps should be controlled. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Workflow records help prevent undocumented standing access to NHIs and apps. |
Track application entitlements so access can be approved, reviewed, and revoked.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
