A procurement process is the sequence of steps you run for a given purchase. A procurement strategy is what decides how those steps get run, every time, across every category. Without one, each purchase starts from zero: new criteria, new documentation habits, new negotiation approach, reinvented by whoever happens to own the project.
What a Strategy Actually Sets
A working procurement strategy answers a short list of questions before a specific purchase ever comes up: What criteria do we use to evaluate a vendor? What has to be documented and who has to approve it? How do we assess risk before signing? Who gets notified when something goes wrong, and who's accountable for fixing it? Answering these once, as policy, is faster than answering them under deadline pressure every time a contract needs replacing. In practice, most organizations write this down as a short internal policy document, not a lengthy governance manual, covering criteria, approval thresholds, and escalation paths in a page or two per category.
Vendor Selection Criteria
Financial stability, track record in the relevant category, and domain-specific expertise all matter more than a polished pitch. A strategy should specify which of these carry the most weight for which category, since the right criteria for a cloud platform aren't the same as the right criteria for a carrier or an MSSP. A cloud platform decision weighs architecture fit and data portability heavily; a carrier decision weighs rate structure and SLA remedies; an MSSP decision weighs response time commitments and staffing depth. Customer references and case studies from similar-sized organizations are worth more than a generic reference list, and are worth requesting before, not after, a vendor is shortlisted.
Standard Procedures That Prevent Repeat Mistakes
Four things are worth standardizing once rather than improvising each time:
- Documentation. A clear, consistent record of what was evaluated, why a vendor was chosen, and what was promised, so the rationale survives past the person who ran the deal.
- Approvals. Defined sign-off points by deal size or risk level, so nothing large moves without the right people seeing it first.
- Risk assessment. A standard set of questions asked of every vendor, covering financial exposure, security posture, and operational dependency, before a contract is signed.
- Contingency planning. What happens if the vendor underperforms or the relationship ends early. Better to have answered this before signing than while managing a failing implementation.
Governance by Deal Size
Not every purchase needs sign-off from the same people. A workable strategy sets thresholds: a renewal under a certain dollar amount with no material term changes might only need a department head's approval. A multi-year platform commitment or anything touching data residency or security posture should require IT, Finance, and Procurement sign-off, formally documented, before a signature. Setting these thresholds in advance, as policy, avoids the alternative, which is negotiating approval authority in the middle of a deal under time pressure.
Where Negotiation Fits
Negotiation isn't a phase that happens after the strategy; it's a discipline the strategy should shape in advance. That means walking into a negotiation already knowing which terms are non-negotiable (data ownership, SLA remedies), which have room (pricing, payment schedule), and what the fallback position is if the preferred vendor won't move. Vendor relationship management continues past signature: performance gets tracked against agreed KPIs, issues get raised early, and the relationship either earns renewal on its merits or doesn't.
Frequently Asked Questions
How often should a procurement strategy be updated? Annually at minimum, and whenever the business changes materially, an acquisition, a new compliance requirement, or a shift in how a major category is being bought. A strategy that hasn't been revisited in three years is usually out of step with how the business actually operates now.
Who owns the procurement strategy? Ownership typically sits with whoever holds Procurement or Finance accountability, but the strategy itself should be built with IT at the table, since technical requirements shape what's negotiable in the first place. A strategy written by one function alone tends to miss what the others need.
What's the difference between a strategy and a policy? In practice the terms overlap. A strategy tends to describe priorities and criteria (what matters and why); a policy tends to describe rules and thresholds (who approves what, at what size). Most working documents blend both.
Where to Go Next
For the checklist version of this discipline, see IT Procurement Best Practices. For how criteria and priorities shift by spend category, see IT Category Expertise.
