A budget built from quotes
In many companies the IT budget is put together like this: take last year's quotes, add the renewals, leave a little headroom. Then the emergencies arrive: a server fails, the manufacturer stops updating the firewall, a major customer asks you to demonstrate your security measures. You pay, in a hurry and at emergency prices.
The result is a budget that describes what suppliers have proposed, not what the company needs. Building it the other way round means starting from risks and objectives and getting to the quotes only at the end. This is the work of IT governance: priorities, budget and criteria for choosing suppliers.
First distinction: keeping things running versus changing them
The first step is to separate two kinds of spending that usually end up on the same line. Running costs ("run") keep what you already have working. Projects ("change") are there to change things: a new system, a migration, a piece of security work.
| Run (running costs) | Change (projects) | |
|---|---|---|
| What it covers | Licences and fees, support, connectivity, maintenance, scheduled replacements | New systems, migrations, security projects, integrations |
| How it is estimated | From current contracts and the inventory, with their expiry dates | From the project: scope, phases, internal and external hours |
| Typical risk | It grows quietly, one subscription at a time | It is the first to be cut, even when it reduces a serious risk |
Separating them shows how much of the budget goes on simply staying where you are. If running costs absorb everything, projects slip and systems age.
Every system has an expiry date
PCs, servers, firewalls, operating systems and applications have an end-of-support date, after which the manufacturer stops releasing fixes. That date is known in advance, often years ahead. Recording it in the inventory and planning the replacements turns an emergency purchase into a planned expense. The risks of an end-of-life system are explained in the guide on patch management.
The total cost of ownership (TCO) also matters: the purchase price is only the beginning. A system also costs money in installation, licences, support, training, internal hours and, at the end, decommissioning and data migration. Two offers at the same price can have very different total costs.
Then there are cloud subscriptions, which creep in one department at a time: sales activate one tool, marketing another, someone leaves and the licence stays. An annual review, with the people who use them and the people who pay for them, usually turns up something to cancel.
Technical debt, explained to a finance director
Every time an update is postponed, a temporary fix is chosen or an old system is kept alive "because it works", you save today and take on a debt. Like a loan, technical debt accrues interest: every year it costs more in support, lost time and exposure to attacks, and the postponed migration becomes more expensive. You do not need to clear it completely, but you do need to know what it is and pay it down with a plan, before a failure makes it all fall due at once.
How to build it, step by step
- Start with the inventory: systems, contracts, licences and subscriptions, with expiry and end-of-support dates.
- List risks and objectives with senior management: what must not happen (the ERP going down during month-end close) and where the company wants to go (a new site, e-commerce).
- Separate run and change, and estimate running costs from the actual contracts, not from the previous year.
- Prioritise the projects with a risk/value matrix. Obligations come first: if you fall under NIS2, risk management measures are not optional and the management bodies are accountable for them (see the guide on NIS2 for SMEs). Next, whatever reduces a serious risk, such as backups that have never been tested. Then whatever brings value.
- Draw up a three-year roadmap: the first year in detail, the second and third in broad outline, with replacements already scheduled. A move to the cloud, for example, often spans more than one financial year.
- Set aside a contingency and label it as such.
- Review it every quarter: what has been done, what has changed, what has shifted in priority.
How to present it to management
A request written in technical terms ("we need a next-generation firewall") struggles to compete with the other budget lines. The same request, written in terms of risk, becomes a decision that management knows how to make: which process it protects, what happens if it is not done, how much an outage would cost. For the last question you can start with the downtime cost simulator, using your company's own figures.
Be wary of comparisons with what "companies like yours" would spend: they are averages that know nothing about your sector or the risks you have already reduced. The budget is justified by your risks, not by other people's.
The most common mistakes
- Renewing everything out of inertia, without asking whether it is still needed.
- Cutting security first, because it produces nothing visible until something happens.
- No contingency for unforeseen costs, which arrive anyway and override the agreed priorities.
- A roadmap written once and never reopened, which is already out of date after six months.
In short
An IT budget built on last year's quotes describes the suppliers, not the company. You start from the inventory, risks and objectives, separate running costs from projects and plan replacements around end-of-support dates. The three-year roadmap is reviewed every quarter and presented to management in terms of risk and the cost of downtime.