Enterprise Software Procurement Is Broken and Everyone Knows It
Enterprise software procurement moves at a pace that the software it is trying to purchase has long since left behind. The average procurement cycle for a mid-market enterprise software purchase — from initial vendor identification to signed contract — runs between four and nine months. The software category the procurement team is evaluating will have shipped multiple major releases during that period. The requirements documentation that anchored the evaluation will have drifted from what the business actually needs. The vendor selected may have been acquired.
This dysfunction is not a mystery. It is the predictable output of a procurement process designed for capital expenditure on physical assets — equipment, infrastructure, real estate — that has been applied without modification to recurring software subscriptions. The risk management logic that governed buying a data center server in 2005 is still governing the purchase of a SaaS HR platform in 2026.
Why the Process Persists
Procurement processes that produce bad outcomes persist when the people who bear the cost of those outcomes are not the people who control the process. IT leaders who wait eight months for software they needed in Q1 do not control the procurement committee that mandated the eight-month process. Finance teams that designed the approval workflow around capital expenditure thresholds did not anticipate that a $200-per-seat SaaS contract would require the same approval path as a $2 million server purchase.
The organizational fix — creating separate procurement tracks for software with different approval thresholds, timelines, and risk frameworks than physical capital expenditures — requires cross-functional coordination between IT, finance, legal, and security that most organizations find genuinely difficult. The difficulty is not technical. It is political. Procurement processes represent accumulated organizational authority. Changing them requires negotiating with the stakeholders who hold that authority.
The Security Review Bottleneck
Security review has become the most significant bottleneck in enterprise software procurement at organizations that have built a formal security assessment capability. The information security team that reviews vendor security posture — SOC 2 reports, penetration test results, data handling practices, subprocessor lists — is frequently a team of two or three people evaluating an ever-growing queue of vendor assessments for an organization that is adding SaaS tools faster than the security team can process them.
The queue problem has no good solution within the current model. Organizations that have moved to tiered security review — fast-track assessment for low-data-risk tools, full assessment for tools handling sensitive data — have reduced the bottleneck without eliminating it. The fast-track tier still requires human judgment to determine which tier a tool belongs to. The full assessment tier still requires the same thoroughness as before.
What Better Procurement Looks Like
The enterprise software procurement processes that work have moved away from treating every purchase as a bespoke evaluation and toward a framework that standardizes common assessments: a vendor security questionnaire that is industry-standard and pre-completed by most major vendors, a data processing agreement template that covers standard requirements without requiring legal negotiation from scratch for each vendor, and approval authority delegated to the business unit level for purchases below a defined threshold.
The organizations that have implemented these frameworks report procurement cycles measured in weeks for standard purchases rather than months. The risk reduction compared to the previous process is marginal — the standardized assessments cover the same territory as custom ones, simply faster. The time savings are substantial. The organizational change required to implement them is the constraint that separates organizations with functional procurement from organizations with procurement processes that serve the organization’s compliance requirements more than its operational needs.
Software procurement that does not serve the business’s ability to acquire and deploy software serves nothing the business actually needs. The compliance function is real. The organizational willingness to make procurement serve operations rather than the reverse is the variable.