TenderCodes .eu

Guide

Buyer's Guide for IT Procurement Officers

Babar Al-Amin
builder of TenderCodes & founder of BrotCode UG
Last reviewed 2026-06-13

Guide for IT Procurement Officers

Most guides to IT procurement explain the rules. This one explains the moves: how a need turns into a notice, where the process breaks, and which classification choice quietly decides who ever sees your contract. Written for the people inside a contracting authority who run the process, not the ones selling into it.

What IT procurement is in the EU public sector

IT procurement is the regulated process a public body follows to buy software, systems, and IT services with public money. In the EU, above a set of value thresholds, that process is not optional and not local: it runs to common rules, and the contract is advertised across the single market on a shared portal.

The legal spine for classic public-sector buying is Directive 2014/24/EU, transposed into each member state's own law. It sets out the procedures (open, restricted, competitive with negotiation, competitive dialogue, and the innovation partnership for solutions that do not yet exist), the principles (equal treatment, transparency, proportionality, non-discrimination), and the point at which a contract becomes an EU-wide affair rather than a national one.

Public procurement is a large slice of the economy. The European Commission puts public procurement at roughly 14% of EU GDP across all sectors, not IT alone. IT is a fast-growing share of it: every authority now runs case-management systems, portals, payroll, identity, and the support contracts that keep them alive.

What makes IT procurement distinct from buying desks or vehicles is that the deliverable is rarely a finished object on a shelf. You are buying work, a service, a licence, or some bundle of all three, often over several years. That is why classification is harder here than almost anywhere else, and why getting it wrong is so easy.

The role of the procurement officer is to turn a real operational need into a notice a market can bid on, score the bids fairly, and award a contract that holds up if challenged. The technical reality and the regulatory reality have to meet in one document. This guide walks that path end to end.

The procurement process, end to end

The process has a shape that holds across member states, even where the local rules differ in detail.

Need. Someone inside the authority has a problem: an ageing system, a manual process, a new legal duty, a security gap. Before anything is bought, the need has to be defined well enough that a market can respond to it. A lot of procurements quietly go wrong right here, because the need is written as a solution ("buy product X") rather than an outcome.

Specification. The need becomes a statement of requirements. Functional requirements describe what the system must do; non-functional requirements cover performance, security, accessibility, and support. For complex builds, authorities often run a separate piece of analysis first, commissioning business analysis consultancy to map the problem, or an IT requirements review to pin down exactly what a system must meet before the build is scoped.

CPV classification. Every notice carries at least one Common Procurement Vocabulary code. The CPV code tells the market, in a language-neutral way, what is being bought. It is also what suppliers set their alerts on. Pick the code that matches the dominant deliverable, not the technology underneath. More on this below, because it is the step most worth getting right.

Notice on TED. Above the relevant threshold, the contract notice is published on Tenders Electronic Daily (TED), the EU's official journal supplement for public procurement. Below it, national rules and portals apply, still under the Treaty principles of transparency and equal treatment. The notice opens the bidding window: the tender.

Evaluation. Bids are scored against published award criteria. Under the directive, every award is made on the most economically advantageous tender (MEAT) basis; the authority identifies it on price or cost alone, or, far more commonly in IT, on the best price-quality ratio, which weighs quality alongside cost. The criteria and weightings have to be published up front and applied as written.

Award. The winning bid is selected, unsuccessful bidders are notified, a standstill period runs, and the contract is awarded. A contract award notice is then published, which is what feeds the historical record everyone later mines for benchmarks.

Each stage produces a document, and each document is a point where a challenge can land if the process was not followed. That is the discipline of the job.

Writing requirements and choosing the right CPV code

The single most consequential decision a procurement officer makes is the primary CPV code. It is a dropdown choice that takes ten seconds and shapes the entire competition, because it determines who is alerted, who bids, and how the contract is benchmarked afterwards.

The recurring error is classifying by stack instead of by deliverable. A custom case-handling system that happens to run in the cloud is still application software programming, not hosting. Hosting becomes the right primary code only when the contract is for running a site, which is website operation and hosting. The clean test the source data keeps coming back to: name the thing that gets signed off and paid for. If that is working software, you are in the development branch. If it is a running service, you are in the services branch.

A municipality I watched run a citizen-portal procurement put the whole thing out under website operation and hosting, because the system would live on a hosted platform and the team thought of it as "the website." The actual deliverable was a build: a bespoke portal with case-handling behind it. The development shops that would have bid had their alerts set on application software programming and never saw the notice. The competition that arrived was thin, the award went to a hosting-led bidder, and the build came in late. One dropdown value, set by analogy to "the website," cost the authority its best suppliers.

Build the requirements before you reach for the code, not the other way round. Once the statement of work names its dominant deliverable, the code usually falls out of it:

For off-the-shelf buying, the spine moves out of the 72 services branch into the 48 software-package branch. A general software-licensing deal that no narrower code names lands under IT software package, the catch-all for packaged products and renewals such as enterprise licences. A packaged tool to secure data, an encryption or threat-detection product, is data-security software package, whereas commissioning that protection as bespoke code is data-security software development in the services branch.

If you are unsure which code fits a software project, the find-my-code walkthrough at the software-project classification guide maps common project shapes to codes. For the full structure of the 72 services tree, the CPV 72000000 services guide breaks down each branch.

One practical note from the data: a high share of IT contracts bundle several activities (build, then host, then maintain, often under one multi-year award). The rule the documented codes apply consistently is to set the primary code by whichever scope dominates over the contract term, and use additional CPV codes for the rest.

EU procurement thresholds: the framework, not the figures

Thresholds decide whether a contract is advertised EU-wide on TED or handled under national rules. The framework is stable; the exact euro figures are not, so this section describes the structure and flags the numbers for verification.

Three things shape which threshold applies:

Contract type. Thresholds differ for supplies, services, and works. Works (construction) sit at a much higher threshold than supplies and services, which makes sense: a building costs more than a software licence. Most IT contracts are services or supplies, so they cross into EU-wide territory at a far lower value than a road or a hospital would.

Authority tier. Central-government authorities (national ministries and their bodies) face a lower threshold than sub-central ones (regional and local authorities). A national ministry's services contract becomes an EU-wide tender at a lower value than the same contract run by a municipality.

Periodic revision. The thresholds are revised on a regular cycle, currently every two years, to track the EU's commitments under the WTO Government Procurement Agreement. Because the figures move, a number that was right in one period is wrong in the next.

The consequence for an IT procurement officer is simple. Above the applicable threshold, you publish a contract notice on TED, run a full procedure, and observe the standstill period before awarding. Below it, you follow national rules, which are lighter but still bound by the Treaty principles of transparency, equal treatment, and proportionality. Splitting a contract to drop it under a threshold is prohibited; the rules require you to value the contract as a whole, including options and renewals.

I am deliberately not quoting the current euro figures here. They change, and a stale number in a guide is worse than no number. Check the live thresholds in the Commission's current delegated regulation, or your national transposition, at the point you classify a contract. Any specific figure in a notice should be cross-checked against the regulation in force on the date of publication.

Best practices that hold up

A handful of habits separate procurements that run clean from the ones that get challenged.

Specify the outcome, not the product. A requirement that names one supplier's product narrows the field to that supplier and invites a challenge. Describe what the system must achieve and let the market propose how.

Classify by deliverable, and check the framework first. Before opening a fresh procurement, check whether an existing framework agreement already covers the work. The award data is full of consultancy and support bought as a line within a wider framework rather than as a standalone tender. A framework call-off is faster and defensible; a needless new procedure is neither.

Separate the build from the run, on purpose. Decide early whether one supplier builds and then operates a system, or whether build, host, and maintain are split. Each has trade-offs. A bundled multi-year deal is simpler to manage but harder to exit; a split keeps suppliers honest but raises integration risk. Whatever you choose, classify by the dominant scope, so a multi-year hosting-and-support contract reads as a service even if it started with a build.

Plan the implementation as its own scope. Buying the software is not the same as standing it up. Authorities routinely commission system implementation planning or broader systems consultancy to cover the rollout, migration, and project-steering layer that turns a purchased system into a live one. For the strategy that precedes a build, information systems planning buys the roadmap, not the systems.

Get the support model right at the notice stage. Day-two support is where IT contracts live or die, and it is also where classification gets muddy. A user-facing service desk is helpdesk services; keeping a specific application healthy is software support services; changing and patching the code over time is software maintenance and repair; and broad technical upkeep of the whole computing environment is technical computer support services. Naming the wrong one means the wrong suppliers see the contract.

Treat data and security as first-class scope. Where a system holds data, contracts for data storage services (holding it safely) and data transmission services (moving it between systems) are distinct codes with distinct supplier pools. Pulling them apart at the notice stage gets you bids from suppliers who actually do that work.

Publish criteria you can defend. Use MEAT for anything where quality matters, weight the criteria before bids open, and score against the published weightings without improvising. The standstill period exists so unsuccessful bidders can review the decision; a clean, written rationale is your best protection.

What the award record shows

The historical data backs the bundling pattern up. Under software maintenance and repair, the busiest software-services code, 7,896 awards carry the code from 2009 to 2026 at a mean of about €1.4M across awards with disclosed values, with France, Spain, and Poland placing the most. The volume follows from a simple fact: every deployed system needs maintaining, so these contracts recur on fixed cycles. Higher-value advisory work runs heavier still: systems consultancy shows 390 awards at a mean near €8.7M, inflated by framework agreements that bundle advice with named specialists rather than scoping a single study. (Both figures: TED award records, 2009-2026.)

What is IT procurement?
It is the regulated process a public body uses to buy IT software, systems, and services with public money. In the EU, above set thresholds it follows the common rules in Directive 2014/24/EU and the contract is advertised EU-wide on TED.

What is the IT procurement process, step by step?
Need, specification, CPV classification, contract notice on TED, evaluation against published criteria, and award. Each stage produces a document, and each document is where a challenge can land if the process was not followed.

How do I choose the right CPV code for an IT contract?
Classify by the dominant deliverable, not the technology stack. If the thing that gets signed off is working software, you are in the development codes; if it is a running service, you are in the services codes. For multi-activity contracts, set the primary code by whichever scope dominates the contract term.

What are the EU procurement thresholds for IT?
Thresholds decide whether a contract goes on TED EU-wide or stays under national rules. They differ by contract type (services and supplies are lower than works) and by authority tier (central is lower than sub-central), and they are revised every two years to track the WTO Government Procurement Agreement. Check the figures in force on your publication date rather than relying on a number from a guide.

Do contracts below the threshold escape the rules?
No. Below-threshold contracts follow lighter national rules but are still bound by the Treaty principles of transparency, equal treatment, and proportionality. Splitting a contract to stay under a threshold is prohibited.

Commonly confused codes

The codes that trip procurement officers most often are the ones whose titles sound interchangeable but split on a real line.

If the deliverable is Use Not A custom application built for the authority application software programming programming of systems and user software (the OS/utility layer underneath) Bespoke build scoped as a service software development services application software programming (the act of programming) Running and hosting a live website website operation and hosting web site design services (building a new one) Renting a hosted application application service provision website operation and hosting (running your own site) A user-facing service desk helpdesk services software support services (support tied to one product) Patching and upgrading existing code software maintenance and repair software support services (answering questions, resolving incidents) Technical upkeep of the whole estate technical computer support services software support services (one application) The business problem, before any IT business analysis consultancy IT requirements review (the system requirements that follow) A packaged security product data-security software package data-security software development (bespoke security code) General software licences IT software package a narrower communications or system code Holding data safely data storage services data transmission services (moving it between systems)

For the wider picture of how IT contracts run across the single market, the complete EU IT tenders guide is the hub. Suppliers reading from the other side of the table will find the supplier's guide to winning EU public IT contracts useful for understanding how your notices land.

About this guide

Written by Babar Al-Amin, who builds TenderCodes and runs the Berlin Rails consultancy BrotCode (on LinkedIn). The classification calls here come from reading the actual award records behind each code, not from restating the official titles. More on who writes this and how it is reviewed on the About page.

Last reviewed

2026-06-13.

Want to know when a contract lands under a code you watch? Find your code and set a per-code alert from its page, so you can skip the daily TED trawl.