A Procurement Checklist for a New SaaS Tool

Signing up for a software tool has never been easier. A card, an email address and you are in. For a team, that ease hides real decisions. The tool will hold your data, your workflows and often your customers' information. It will become part of how you work, and leaving it will not be as easy as joining.

A procurement checklist is the antidote. It is a short, structured set of questions you ask before you commit, so that what you buy has been looked at properly. This guide offers one for software as a service, organised into the areas that matter most, and explains how to use it in proportion to the purchase.

Due diligence, in proportion

Due diligence is the investigation a buyer does before entering an agreement, to check facts and understand risks. The idea is old and applies to everything from buying a company to buying a subscription.

The depth should match the stakes. Ask three questions to decide.

1. How sensitive is the data? Personal data, financial data, confidential material?
2. How important is the tool to the work? Would an outage stop you?
3. How hard is it to leave? Is data portable? Does the tool integrate deeply?

If the answers are low, a light check is enough. If they are high, the full list below applies, with evidence.

Section one: the vendor

Start with who you are dealing with.

• Legal name and address. A real company you can contact.
• How long they have operated. Not a deal-breaker, but relevant to risk.
• Who owns and runs it. Public information about leadership.
• Customers and references. Can they put you in touch with similar customers?
• Financial stability. For essential tools, ask about funding, revenue trends or other signs of viability.
• Dependencies. Which major suppliers they rely on.

Look for plain, consistent answers. Vague replies or a reluctance to share basic facts deserve a pause.

Section two: security

Security questions should come from a recognised framework. The UK National Cyber Security Centre's cloud security principles are intended to help you choose a cloud provider that meets your security needs, and they apply to software as a service. They cover areas such as data in transit, asset protection, separation between customers, governance, personnel security, secure development, supply chain security, secure user management, identity and authentication, external interfaces, service administration, audit information, and secure use of the service. You do not need to read the full text to benefit: use the headings as a prompt.

Questions to ask:

• How is data protected in transit and at rest?
• How are customers' data separated from each other?
• Who at the vendor can access our data, and how is that controlled and logged?
• How do users sign in? Is single sign-on supported? Is two-step verification available or required?
• What permissions model does the tool offer? Can we limit what people see and do?
• How does the vendor develop and test software, and fix vulnerabilities?
• Has an independent party tested or certified the service? What does the report say, and when was it done?
• What is the vendor's incident process? How and how fast would we be told of a problem?
• What does the vendor depend on, and how do they manage those suppliers?

Ask for evidence: a security overview, policies, summaries of assessments. The NCSC also stresses considering what evidence has been provided to give you confidence in the statements being made. A claim without evidence is a claim.

Section three: data and privacy

If the tool will hold personal data, data protection law applies, and you remain responsible for what happens to it.

• What data will the tool hold, and can we limit it?
• Where is it stored and processed? Which countries?
• Who are the vendor's sub-processors, the other companies it uses?
• What does the data processing agreement say? The UK Information Commissioner's guidance on contracts between controllers and processors explains what such contracts should cover.
• How long is data kept, and how is it deleted?
• How can we get data out, in what format, and how fast?
• How are individuals' rights handled, such as access and deletion requests?
• Is our data used for anything else, such as training models or analytics?

Involve whoever handles data protection in your organisation.

Section four: reliability and support

A tool that is down is a tool that costs you.

• Uptime history. Is there a public status page with past incidents?
• Service levels. A service-level agreement is a commitment about the level of service a vendor provides, such as availability, with consequences if it is missed. What does this vendor commit to, and what are the remedies?
• Backups and recovery. How often? How fast can they restore?
• Performance. Does it stay quick with our volume?
• Support channels and hours. Email, chat, phone? In our time zone?
• Response times for different severities.
• Escalation. Who do we contact if it is serious?
• Roadmap and change notice. How do we hear about changes that affect us?

Test support during evaluation: send a real question and see how fast and well it is answered.

Section five: fit and integration

• Does it meet our must-have requirements? The list from your earlier work.
• Which systems does it integrate with, and how: native, API, webhook?
• Is there an API, and are its limits documented?
• Can we import our existing data? How hard is it?
• Can it scale to our team and volume?
• Is it accessible to our users, including those who use assistive technology?
• Does it support our languages and regions?

Section six: commercial terms

• Pricing model. Per user, per usage, tiered? What counts as a user?
• What is included, and what costs extra?
• How prices can change, and with what notice.
• Contract length and renewal. Does it renew automatically? When, and with what notice?
• Payment terms.
• Discounts and their conditions.
• Total cost of ownership. The full cost over time, including setup, training, integration, add-ons and the staff time to run it. Total cost of ownership is the purchase price plus the other costs of owning and operating something.
• Termination rights. Can we leave if service is poor?

Keep the prices and terms in your own records, and check them against the vendor's pricing page when you sign.

Section seven: legal

Have someone with the right skills read the contract. Look at:

• Liability and its limits.
• Indemnities.
• Intellectual property: who owns what you create.
• Confidentiality.
• Governing law and where disputes are settled.
• Changes to terms: how and when the vendor can alter them.
• Assignment: what happens if the vendor is bought.
• Suspension and termination.

This is general guidance, not legal advice. For anything significant, take professional advice.

Section eight: exit

Plan how you leave before you join.

• Can we export all our data, in an open, usable format?
• Is the export complete, including attachments, history and settings?
• How long after termination can we get the data?
• How and when is our data deleted, and do we get confirmation?
• What help is available for migration?
• Are there fees for leaving?
• What happens if the vendor closes? Is there any continuity plan?

Vendor lock-in is a situation in which a customer cannot easily move to another vendor because of costs or technical dependence. The best protection is to test the export during your trial, with real data.

Collect evidence, not promises

For each answer, note how it was provided.

• Written in the vendor's documentation.
• Provided in a document on request.
• Said in a call.
• Not answered.

Prefer the first two. Keep copies. Date everything. Vendors change, and your records protect you.

Rate and decide

Use a simple status for each item.

• Meets, with evidence.
• Partly meets, with a note.
• Does not meet.
• Unknown.

Decide in advance which items are deal-breakers. A single "does not meet" on a critical item should stop the purchase. A cluster of "unknown" should prompt more questions.

Record the decision, the date, who approved it and the conditions.

After you sign

Procurement does not end with a signature.

• Diarise the renewal and notice dates.
• Record who owns the relationship.
• Review the vendor annually, against the same checklist.
• Keep an eye on changes, such as new sub-processors or terms.
• Revisit exit readiness once a year.

A light version for small purchases

For a low-risk tool, ask five questions:

1. What data will it hold?
2. How do people sign in, and can we use two-step verification?
3. What does it cost, and how do we cancel?
4. Can we export our data?
5. How do we get help?

Write the answers in a few lines and file them.

Common mistakes

• Buying on a card without a check.
• Asking questions without asking for evidence.
• Ignoring exit.
• Missing renewal terms.
• Skipping data protection.
• Letting the vendor's sales team run the process.
• Never revisiting.

On this site

The categories and search pages help you find candidate tools, the launches page shows new vendors, and the terms and privacy pages show how a listing platform states its own rules, a useful reference for your own questions. The submit page is where vendors list their products.

The short version

Match your checks to the stakes. Ask about the vendor, security, data and privacy, reliability and support, fit and integration, commercial terms, legal terms and exit. Use recognised frameworks for security questions, ask for evidence, test support and export during the trial, decide deal-breakers in advance, record the decision and diarise renewals. A few hours of care before signing protects years afterwards.