A purchase requisition is an internal request to buy goods or services before a formal purchase order is created. In SAP, it starts the procurement cycle, captures demand, and routes the request for review or approval. It is an upstream control point for spend governance and sourcing discipline.
Expanded Definition
A purchase requisition is an internal demand signal that asks an organisation to buy goods or services before a purchase order is issued. In enterprise procurement, it is the control point where need, budget, approver routing, and sourcing rules first intersect. In SAP-led environments, the requisition often triggers workflow, coding review, and policy checks before downstream commitments are made.
Its meaning is operational rather than financial: the requisition does not usually obligate the supplier, but it does create traceability for who requested what, why, and under which cost centre or project. That makes it a governance artefact as much as a procurement artefact. Definitions vary across vendors and ERPs, but the core function is consistent with internal control concepts described in NIST SP 800-53 Rev 5 Security and Privacy Controls: requests should be reviewable, authorised, and auditable before spending proceeds.
The most common misapplication is treating a requisition as a procurement approval rather than a request for review, which occurs when users bypass policy and assume entry in the system is equivalent to spend authorisation.
Examples and Use Cases
Implementing purchase requisitions rigorously often introduces approval latency, requiring organisations to weigh faster buying against stronger spend governance and sourcing discipline.
- A developer submits a requisition for a new API gateway license, and finance validates budget owner approval before procurement raises the order.
- An operations team requests replacement hardware through a requisition so sourcing can confirm contract pricing and approved vendors before commitment.
- A security team opens a requisition for a secrets management service, allowing review of data handling, vendor risk, and budget code before purchase.
- A business unit requests consulting support, and the requisition routes to the cost centre owner for justification and threshold-based approval.
- An SAP workflow uses the requisition to separate demand capture from supplier commitment, helping avoid off-contract spend and duplicate buying.
For procurement process design, the control logic mirrors the discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, where auditable authorisation matters as much as the request itself. NHI Management Group’s Ultimate Guide to NHIs is relevant here because procurement tooling often becomes the place where service-account, SaaS, and automation purchases are first justified and tracked.
Why It Matters in NHI Security
Purchase requisitions matter in NHI security because they often precede the acquisition of systems that will create, store, or depend on non-human identities. If the requisition process is weak, organisations can end up buying automation tools, CI/CD services, or cloud platforms without defined ownership for service accounts, secrets, rotation, or offboarding. That is how governance gaps become identity risks.
This is especially important because NHI Management Group reports that 79% of organisations have experienced secrets leaks, and many of those failures begin with poorly governed procurement and deployment choices rather than a single technical mistake. A requisition should therefore surface who will own the NHI lifecycle, where secrets will live, and what controls are required before the purchase is approved.
Organisations typically encounter hidden NHI sprawl only after a tool is already live, at which point purchase requisition discipline 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, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supplier and acquisition governance starts with controlled internal purchasing. |
| NIST SP 800-53 Rev 5 | SA-4 | Acquisition controls govern how systems and services are selected and approved. |
| NIST AI RMF | Governance of AI system acquisition depends on documented approvals and risk review. | |
| NIST Zero Trust (SP 800-207) | Zero Trust adoption depends on knowing what systems and identities are introduced. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | New tooling often introduces unmanaged non-human identities and secrets. |
Screen requisitions for identity impact so new services arrive with least-privilege and access boundaries defined.
