SaaS Procurement Checklist: 24 Questions Before You Sign

Software spend behaves differently from most categories: it renews automatically, grows with headcount, and is often bought by a department without procurement involved until the invoice arrives. This checklist is designed to be used at signature, when leverage is at its peak.

Commercial

• What is the price per unit, and what counts as a unit?
• Is the annual uplift capped, and at what percentage?
• What happens to pricing if we add seats mid-term? If we remove them?
• Are implementation and onboarding fees one-off or recurring?
• What is the payment term, and is there a discount for annual prepayment?
• Which modules are included, and which are the predictable upsell?

Scope and usage

• How many people will genuinely use this in 90 days, not in the optimistic plan?
• Are there usage limits — API calls, storage, records — and what happens at the ceiling?
• Does an existing tool already cover part of this scope?
• Who internally owns this relationship after purchase?

Security and data

• Where is our data stored, and under whose jurisdiction?
• Which subprocessors have access, and are we notified of changes?
• What security certifications exist, and when were they last audited?
• What is the breach notification commitment, in hours?
• Is our data used to train any models, and can we opt out?

Service and support

• What uptime is committed, and what is the remedy if it is missed?
• What are support response times by severity?
• Is there a named contact, or a shared queue?
• How much notice do we get for breaking changes?

Exit

• What is the notice period, and when is the first notice deadline?
• Can we export all of our data ourselves, in a documented format?
• How long is data retained post-termination, and is deletion certified?
• Are there termination fees or minimum commitments remaining?

Use it as a form, not a document

The checklist works best embedded in the software request itself, so the requester answers what they can and procurement fills the gaps. Attached to the purchase order, it becomes the opening position for the renewal conversation twelve months later — which should start 120 days before the notice deadline, not the renewal date. Contract renewal management has the sequence.

Start with the operating case, not the feature list

Context matters in SaaS procurement because the visible transaction is only the final record of several earlier decisions. Consider this operating case: A team signs a three-year analytics contract after a successful trial, then discovers minimum seat commitments, costly data export, no sandbox, and a sixty-day termination window. The useful question is not whether a form was completed. It is whether the evidence available at that moment was sufficient for a named owner to make a reversible, explainable decision. That distinction keeps the process practical: control is attached to consequence, not paperwork.

Trace one ordinary case and one awkward case from the first request to the final accounting entry. Record who knew what, which system held it, and what happened when the expected path failed. This exposes handoffs that a workshop diagram misses: the spreadsheet used to repair supplier names, the inbox where an approver asks for context, or the monthly reconciliation that makes reports believable after the fact.

Evidence to assemble before changing the process

Do not begin configuration with a blank workflow canvas. Build a small evidence pack first. It should be compact enough for the working team to challenge line by line, and representative enough that a successful pilot means something. The minimum useful pack contains the following inputs.

• Use case, user groups, data classes, integrations, and success criteria
• Complete commercial schedule including uplifts, minimums, and overages
• Security, privacy, availability, support, and data-location evidence
• Implementation, administration, renewal, and exit ownership

The decisions the workflow must make explicit

A dependable SaaS procurement process does not ask everyone to approve everything. It identifies a small set of decisions, assigns each to the person with the authority and information to make it, and records enough context to explain the result later. If two reviewers are checking the same fact, remove one. If nobody can state what would cause rejection, the step is probably ceremonial.

• Whether the product replaces, overlaps, or adds capability
• Which risks require contractual protection
• What volume commitment is defensible
• How data and workflows leave if the service is replaced

Write these decisions as testable statements. For example: approve when the budget is available and the need is valid; route to security only when company data enters the service; reject when the supplier identity cannot be verified. Testable rules make demos, implementation workshops, and post-launch audits materially more useful than labels such as finance review or procurement check.

A practical implementation sequence

Sequence matters because teams otherwise automate the cleanest diagram and discover the real exceptions after launch. Keep the first release narrow, but do not make it artificially easy. Include enough volume to observe behaviour and at least one category with meaningful exceptions. A sensible sequence is:

1. 1Validate need and active alternatives before the demo cycle
2. 2Run security and legal review against actual data use
3. 3Model three-year cost under realistic growth and contraction
4. 4Negotiate renewal and exit while switching remains credible

At each step, preserve a manual recovery path and name the person allowed to use it. Recovery is not failure; invisible recovery is. An exception handled in a private message teaches the system nothing. An exception recorded with a reason can inform the next policy or configuration change.

Failure modes worth testing before launch

Happy-path acceptance testing proves very little. Build tests from the cases that cause delay, uncontrolled commitment, duplicate work, or misleading reporting. The following failures are common enough to deserve an explicit owner and expected response before rollout.

• Buying on first-year discount while ignoring renewal uplift
• Accepting unlimited language that excludes practical limits
• Skipping export tests
• Leaving ownership with the project sponsor who changes roles

Run these as tabletop exercises with the requester, approver, finance operator, and system administrator in the same room. If the answer depends on somebody remembering an unwritten convention, document it or redesign the path. If the answer requires administrator intervention for an ordinary exception, calculate that support load before declaring the workflow scalable.

Measure the control without gaming it

A metric needs a stable denominator, a reproducible source, and an owner who can change the result. Publish the definition beside the number. Show medians with a tail percentile where time is involved, and split rates by material populations rather than averaging unlike work together.

• Active use against contracted seats or volume
• Overlapping application cost
• Incidents and support performance against agreement
• Renewals opened before the notice deadline

Review the underlying records monthly during rollout, then quarterly once behaviour stabilises. A rising exception rate can mean the process is deteriorating, but it can also mean the system has started recording exceptions that were previously invisible. Interpret the movement before rewarding or correcting anyone.

Limits and cases that need a different tool

No SaaS procurement design is universal. State exclusions before estimating benefits. That protects the business case from inflated addressable volume and tells operators where a different control, specialist system, or human judgement remains necessary.

• A checklist cannot verify every security claim
• Trials understate migration and administration effort
• Usage does not by itself prove business value
• Exit rights matter only if the company can execute an exit

Keep a decision record that survives the project

For each material choice, record the date, owner, evidence considered, option selected, rejected alternatives, and the condition that would trigger review. This is not meeting minutes. It is a compact explanation of why the company accepted a particular cost or risk. Six months later, a new operator should be able to distinguish an intentional compromise from an accidental omission without locating the original project team.

Use the record during monthly operations reviews. Compare the assumptions made at approval with actual volume, cycle time, exceptions, and supplier behaviour. When an assumption fails, change the rule or reopen the decision; do not quietly build manual work around it. That feedback loop is what turns a configured workflow into an operating system rather than a frozen implementation project.

The final design should be easier to explain than the process it replaces. If a requester cannot predict what information will be required and who will decide, complexity has merely moved behind the screen. Keep the common path short, make consequential exceptions visible, and revisit the rules when transaction patterns or organisational ownership change.