Procurement for public organisations: how to buy a website properly

How a public body can specify, evaluate and contract a website or application within procurement rules and end up with something it owns and can maintain.

3 minread 706words last updated

The short answer

Public organisations buy websites and applications through procurement rules: thresholds decide the procedure, the procedure sets the steps, and evaluation criteria decide the winner. The rules are the frame; the outcome is decided by what goes inside it. A well-specified procurement names the non-negotiables as pass-or-fail requirements: accessibility to the referenced standard, ownership of code and data, open standards, documentation, exit terms, a security baseline, hosting in the organisation’s accounts. It evaluates on evidence rather than promises: a working sample tested for accessibility and speed, a hand-over pack from a previous client, named people, a maintenance plan with numbers. And it weights quality and five-year cost over initial price, because a bid is only lower on the lines it contains: hosting, maintenance, accessibility work and the hand-over arrive during the contract whether or not they were quoted. Check the specific rules for your organisation with your procurement and legal teams; what follows is what to put inside them.

Requirements: pass-or-fail versus evaluated

Pass-or-fail (non-negotiable)Evaluated (weighted criteria)
Accessibility to the referenced standard, audited at acceptanceQuality of the proposed approach and design
Code in the organisation’s repository; data in open formats with export on demandEvidence from previous work: samples, tests, references
Hosting and accounts in the organisation’s nameMaintenance plan: scope, cadence, response, monthly cost
Documentation to a defined standard; hand-over definedNamed team and their experience
Exit terms with cooperationFive-year total cost, not build price
Security baseline and privacy by design with an assessmentApproach to content, migration and training
Open standards for data exchange and interfacesSustainability and performance practices

Running it well

  1. Write the requirements around outcomes and non-negotiables, with pass-or-fail items separated from weighted ones.
  2. Require evidence with each bid: a sample to test, a hand-over pack, a maintenance report, named people.
  3. Test the samples yourselves: keyboard, screen reader, mobile speed, structured data.
  4. Weight five-year total cost, including maintenance, over build price.
  5. Procure maintenance in the same process with a defined scope, term and exit.
  6. Put ownership, documentation and exit in the contract as deliverables with acceptance criteria.
  7. Verify at acceptance: accessibility audit, repository transfer, documentation, accounts in your name.

After award

The contract includes what the requirements demanded: accessibility audited at acceptance, repository in the organisation’s account, documentation to the standard, accounts in the organisation’s name, maintenance with its report, exit with hand-over. The organisation verifies each at the defined moment rather than trusting the bid. A yearly check that a second supplier could take over from the documentation keeps the exit real.

What this means for you

Use the procurement rules as the frame and put the right things inside it: non-negotiables as pass-or-fail, outcomes as weighted criteria, evidence tested during evaluation, five-year cost over build price, and maintenance procured alongside. Verify ownership, accessibility and documentation at acceptance. A public website procured this way is one the organisation owns, can maintain and can hand to the next supplier, which is what the rules were written to achieve.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

How do we avoid buying the cheapest bid that turns out to be the worst?

By setting evaluation criteria that weight quality, ownership, accessibility, maintenance and five-year cost, and by requiring evidence for each: a live sample tested for accessibility and speed, a hand-over pack from a previous client, a maintenance plan with response times and monthly cost. Price alone as the criterion produces the outcome everyone complains about; the criteria are within your control.

What must the requirements include?

The non-negotiables as pass-or-fail: accessibility to the referenced standard with an audit at acceptance, code in the organisation's repository, data in open formats with export on demand, hosting in the organisation's accounts, documentation to a defined standard, exit terms with hand-over, a security baseline, privacy by design. Then the functional outcomes as evaluated criteria. Check the specific legal requirements for your organisation with your procurement and legal teams.

How do we handle the maintenance after the build?

Procure it as part of the same process, with a defined scope, cadence, response times and monthly cost, for a defined term with an exit. A website without maintenance decays and becomes non-compliant; procuring the build without the maintenance leaves the organisation with an asset nobody is contracted to keep working.

Sources

  1. European Commission: Public procurement (accessed 2026-09-12)