What is the software procurement process, step by step?

What is the software procurement process?

The software procurement process is the set of steps an organisation follows to buy software: confirm that the need is real, check licences it already owns, choose a product and supplier, review security, privacy and legal terms, place the order, then manage use and renewals until the software is retired.

It follows the general procurement process, with extra checks. Software, and above all software as a service (SaaS), differs from most purchases in four ways. It often stores or reads the organisation’s data. It is usually a subscription that renews unless someone gives notice. It is priced by a licence metric, such as named users, devices or usage. And it must connect to other systems, such as sign-in, the ERP or the HR system.

Take an invented case. A marketing team finds a survey tool and wants to pay for it by card. The tool will hold customer email addresses, connect to the customer database and renew every year. Bought as a simple card purchase, nobody checks where the data is stored, who can access it or how to get it back. The software procurement process exists to ask those questions before the data is inside.

Two notes on scope. The IT procurement process covers software and hardware; this page focuses on software, but the same steps apply to laptops or servers, with fewer data checks and more delivery checks. And this page is about how to buy any software; how to choose software for the procurement team itself is covered in the procurement software guide.

What are the steps of the software procurement process?

Most organisations follow the same nine steps, even when they name them differently. Low-risk purchases pass through some steps in minutes; high-risk ones spend weeks in the review steps.

1. Request. The requester describes the problem, the users, the data involved, the budget and the date the software is needed. A short form is enough; it should name a business owner who will stay responsible after the purchase.
2. Check what you already own. Procurement and IT check whether a licensed tool already does the job, or whether an existing contract covers it. A list of current software and its users, built from invoices, card spend and sign-in data, answers this quickly. The software spend analysis guide explains how such a list is built.
3. Sort by risk. Classify the purchase by the data it will hold, how far it connects to other systems, its value and its users. The class decides which reviews come next (see the next section).
4. Choose the route to market. For a small, low-risk tool, a quote from the supplier or a reseller may be enough. For larger needs, compare offers with an RFQ, or run an RFP when requirements and service matter more than price. The RFP process guide sets out the stages.
5. Review security, privacy and accessibility. Collect the supplier’s security evidence, check where data is stored and who processes it, and check accessibility where the law or policy requires it.
6. Agree licence and contract terms. Negotiate the licence metric, price and price changes, term, renewal and notice period, service levels, data protection terms and exit. Legal reviews the supplier’s terms or proposes the organisation’s own.
7. Approve and order. The budget holder approves, and procurement issues a purchase order or, for small purchases allowed by policy, the requester pays by purchasing card.
8. Set up. IT connects the software to sign-in, assigns licences and records the contract, the owner, the renewal date and the notice deadline in the contract register.
9. Manage use, renewal and exit. Review use before each renewal, remove unused licences, renegotiate or replace, and when the software is retired, take the data out and confirm its deletion.

The University of California, Irvine published an example of this flow in a 2020 training deck. A requester fills in a software questionnaire; a unit procurement contact checks for existing agreements and sends the university’s contract templates and data security appendix to the supplier; the security team reviews the supplier’s security plan, a third-party security report and a sector questionnaire; procurement then negotiates and issues the order. The deck estimated the old process at three to eight weeks and the redesigned one at one day to four weeks, depending on the review needed.

How do you match the review effort to the risk?

Not every purchase needs every check. Sorting requests into a few risk classes at the start keeps small purchases fast and gives reviewers time for the ones that matter. The classes below are an example to adapt; each organisation sets its own thresholds.

Price still matters for the route to market, because thresholds in the procurement policy usually decide when quotes or a tender are required. A cheap tool can carry a high risk, and an expensive one a low risk, so both tests apply.

What does a security, privacy and accessibility review ask for?

A review asks the supplier for evidence, not promises. Independent reports carry more weight than self-assessments, and the scope of each report must cover the product being bought. The table lists common evidence; which items apply depends on the risk class, the country and the sector.

A self-assessment and an audit are not the same thing. The US Section 508 programme makes the point for accessibility: the vendor’s report is a claim, and agencies are told to test the product rather than rely on the report alone. The same logic applies to security questionnaires. For suppliers with high-risk access, the checks continue after the purchase, as described in vendor risk management.

In the EU, the privacy review follows Article 28 of the GDPR. The controller may use only processors that give “sufficient guarantees” of appropriate technical and organisational measures, and the contract must cover, among other points, documented instructions, confidentiality, security, the use of sub-processors, help with data subjects’ requests, deletion or return of data at the end, and audits.

Which licence and SaaS contract terms matter most?

Most of the cost of software is decided by terms that look minor at signature. The list below covers the terms reviewers check first; legal and procurement agree the rest as for any contract.

• Licence metric. Named users, concurrent users, devices, processor cores or usage. The metric must match how the organisation will use the software; a per-user price for a tool that every employee opens once a year is expensive.
• Price and price changes. The first-year price, discounts, and how much the price may rise at each renewal. A cap on renewal increases is easier to win before signature than at renewal.
• Term, renewal and notice. The length of the subscription, whether it renews automatically, and how many days before the end notice must be given. With an annual term that renews automatically, missing the notice deadline means paying for one more year.
• Minimums and true-ups. Minimum user counts, and whether extra users are billed at the end of the year (a true-up) or as they are added.
• Audit rights. For installed software, the supplier’s right to audit use, how often and with how much notice.
• Service levels. Availability, support hours, response times and service credits when targets are missed.
• Data and exit. Who owns the data, in which format it can be exported, how long it stays available after the end, and how its deletion is confirmed.
• Liability and changes. Limits of liability, and whether the supplier can change its terms or remove features during the term.

In the EU, the Data Act now sets minimum exit rights for cloud and SaaS services. The contract must give a notice period for switching of no more than two months, a transition of at most 30 calendar days in most cases, and at least 30 days to retrieve data. From 12 January 2027, providers may not charge for switching, with exceptions such as services largely custom-built for one customer. These rules apply to EU customers; elsewhere, the exit terms are whatever the contract says.

How do you manage software renewals?

Renewals are where software spend grows without a decision. Each subscription renews on its own date, often on the supplier’s terms, and the person who bought it may have left. Managing renewals means knowing every renewal date and notice deadline, and reviewing each one early enough to act.

1. Keep one register. Record every subscription with its owner, licence metric, quantity, price, renewal date and notice deadline. A contract register or a SaaS management platform can hold it.
2. Start before the notice deadline. Count back from the last day to give notice, not from the renewal date. For large contracts, starting several months before that deadline leaves time to compare alternatives.
3. Check use. Compare licences paid with licences used in the last months. Remove or reassign unused ones.
4. Look for duplicates. Check whether another team pays for a tool that does the same job, and whether one contract could cover both.
5. Decide. Renew, renegotiate, reduce, replace or end. Each option needs time; replacing a system takes far longer than one notice period.

Gartner calls the tools built for this job SaaS management platforms: software that helps organisations discover, manage, optimise and automate the SaaS application life cycle, including discovery and cost optimisation. They help most where many teams buy their own tools.

Who takes part in buying software?

Software purchases need more people than most purchases, because each reviewer owns a different risk. Naming them in the policy, with a deadline for each review, prevents requests from waiting in inboxes.

How is software bought in the public sector?

Public buyers follow the same steps, with procurement law on top. Above legal thresholds they must compete the purchase or use a framework that was competed for them. Frameworks for software and cloud services exist in many countries; three examples show the range.

• United Kingdom. G-Cloud is the online catalogue public sector organisations and charities use to buy cloud hosting, software and support. G-Cloud 14 expired on 28 October 2026 and buyers are now directed to G-Cloud 15. Crown Commercial Service, which runs it, became the Government Commercial Agency on 1 April 2026.
• United States, federal level. FedRAMP is the federal programme that assesses the security of cloud services used by agencies. On 30 October 2026 its marketplace listed 551 certified services. Under Section 508, agencies must buy technology that meets the federal accessibility standards when such products exist.
• European Union. EN 301 549, produced by CEN, CENELEC and ETSI at the European Commission’s request, sets accessibility requirements for ICT products and services, in particular for public buyers. The GDPR and the Data Act apply to public and private buyers alike.

Other countries, states and funders have their own rules, thresholds and frameworks, so check the ones that apply to your organisation. More on public buying in general is in the government procurement guide.

What are software procurement best practices?

Software procurement best practices are the habits that keep software purchases fast, safe and good value. They come down to knowing what you own, reviewing in proportion to risk, and keeping control of renewals and data.

• Publish one short route for software requests, so teams do not buy around it. Make the low-risk route fast enough that nobody needs a shortcut.
• Check existing licences and contracts before any new purchase. Many requests are answered by a tool already paid for.
• Classify every request by data, integration and value before choosing the checks.
• Ask for independent security evidence and check that its scope covers the product being bought.
• Agree the licence metric, renewal price cap, notice period and data exit terms before signature, when you still have a choice.
• Name a business owner for every subscription, and record the renewal date and notice deadline on the day of signature.
• Review use before each renewal and remove unused licences.
• Limit card purchases of software to classes the policy allows, and route the rest through procurement, so data and contracts are not taken on without review. The purchasing card guide covers card controls.
• Measure the process itself: time from request to order, share of software spend under contract, and renewals reviewed before their notice deadline.