How should organisations govern software buying when procurement is decentralised?

Why decentralised buying needs a governance model, not just a policy

When purchasing is pushed into business units, the main failure is not that people ignore procurement altogether, it is that they create parallel approval paths that no one can see end to end. Governance has to define who can approve what, which thresholds trigger review, and which exceptions require central sign-off. Without that structure, “faster buying” turns into fragmented contracts, duplicated tools and weak negotiating leverage.

The practical design choice is to separate convenience from authority. Local teams can identify need, but the organisation should centralise the rules for risk review, vendor qualification and spend visibility. That keeps decentralised demand from becoming decentralised control, which is where shadow buying usually starts.

How intake and decision rights should work in practice

A shared intake process is the control point that makes decentralised buying governable. Every purchase request should enter the same path, even if the requester, budget holder or approver sits in a different function. Procurement handles commercial terms, finance checks budget and commitment, IT checks integration and supportability, and legal checks contract and data clauses. The point is not to slow every purchase, but to make the same decision logic apply everywhere.

Decision rights should be explicit enough that teams do not negotiate them case by case. Common patterns include spend limits, pre-approved catalogues, mandatory review triggers for software that touches corporate data, and escalation paths for exceptions. If those rights are vague, people route around them, and the governance model degrades into email-based approval theatre.

Why SAM needs an accountable seat in the buying process

Software asset management works best when it is treated as part of governance, not as a reporting afterthought. If SAM is only informed after the fact, it can count licences and chase renewals, but it cannot prevent duplicate purchases, unmanaged renewals or orphaned subscriptions. A governed intake lets SAM validate whether the purchase already exists, whether a cheaper entitlement is available, and whether the software should be added to the approved portfolio.

That accountability matters because decentralised buying often creates a hidden inventory problem before it becomes a security or cost problem. Tools bought outside the main process may never be captured in configuration records, support models or vendor risk tracking. Over time, the organisation loses both spend control and the ability to answer basic questions about ownership, renewal dates and business justification.

Risk and Threat Considerations

Decentralised software buying increases the chance of shadow IT, duplicated contracts, unreviewed data access and software that survives because nobody owns the renewal decision. The risk is less about the purchase event itself and more about the permanent control gap that forms when procurement is bypassed and later records never catch up.

Failure mechanism: A business unit buys software outside the shared intake, the tool is deployed without security, legal or architecture review, and the organisation inherits the contract, data exposure and renewal liability after adoption is already entrenched.

Impact: That pattern can create unmanaged vendor risk, inconsistent licensing, hidden data transfer paths, and avoidable cost growth, while making it much harder to retire the tool later.

Practitioner Guidance

What to prioritise: Start with a single intake entry point and a decision-right matrix, then define which purchases can be auto-approved and which must be reviewed. If the organisation cannot describe the threshold for escalation, it does not yet have governance, only preference.

What to verify: Check that every software request has an accountable owner, a named approver, and a record of the commercial, security and legal checks performed. The useful test is whether finance, IT and legal can all reconstruct the same purchase from one record set.

Common mistake: Treating decentralised buying as a procurement-only problem. In practice, it is a portfolio-control problem, and the control fails when local speed is rewarded without a mandatory path back into enterprise records.

Practitioner takeaway: Decentralisation can be acceptable, but only if the organisation centralises the rules, the intake and the audit trail; otherwise buying becomes durable sprawl that is expensive to govern after the fact.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?