What Should IT Cost? Using Benchmarks Without Being Misled by Them

"What should we be spending on IT?" is asked at every budget cycle, and the usual answer is a benchmark: a percentage of revenue, or a figure per employee.

Both are useful as a sanity check and misleading as a target, because the variance within any industry is larger than the difference between industries.

Why the benchmarks vary so much

A professional services firm where every employee has a laptop, a phone and a cloud application portfolio has a fundamentally different cost structure from a manufacturer where most employees never touch a computer but the factory runs on industrial systems.

Percentage of revenue is especially unstable. A low-margin distributor with high revenue per employee shows a low IT percentage and may be spending generously per person. A consultancy with high margins shows a high percentage while spending modestly per head.

Per-employee figures are more comparable but still swing by a factor of several depending on:

• how many employees actually use technology
• whether software is a cost of goods sold or an IT cost
• whether telecoms, printing and facilities-adjacent spend are counted
• whether IT salaries are included
• capital versus subscription, and where it lands in the accounts

Before comparing to any benchmark, find out what it includes. Most disagreements about whether a business overspends are disagreements about scope.

Build the number from the bottom

More useful than any benchmark is a build-up from your own situation. Four categories:

1. Run — per user. What it costs to have one person working:

• device, amortised over its life
• productivity and collaboration licences
• line-of-business application licences
• support, whether internal or a provider
• telephony and mobile
• security tooling per seat

Multiply by headcount, segmented by user type. Not everyone needs the same, and pretending they do overstates the total and hides the optimisation.

2. Run — fixed. Costs that do not scale with headcount:

• connectivity per site
• network equipment, amortised
• servers and hosting
• backup and disaster recovery
• compliance and audit activity
• IT management and administration

3. Change. Projects: migrations, refreshes, new systems, the compliance programme. This is the line that gets cut first and causes the most cumulative damage, because deferred refresh becomes higher run cost and higher risk.

4. Risk reduction. Security controls, insurance, testing. Easiest to defer and most expensive to have deferred.

A healthy split puts roughly two-thirds to three-quarters in run and the remainder in change and risk. An organisation spending 95% on run is standing still and accumulating debt — that ratio is a better diagnostic than the absolute number.

The questions worth more than a benchmark

Is spending growing faster than headcount? If so, find out why. Per-seat subscriptions compound quietly, and licence sprawl is the usual cause.

What proportion is contractually committed? High commitment means low flexibility when circumstances change.

What is the refresh position? Deferring hardware refresh reduces this year's number and increases next year's — plus support cost and risk. A fleet where the average age keeps rising has a bill arriving.

What would an outage cost? If a day of downtime costs more than your annual resilience spend, the spend is too low. This calculation changes conversations faster than any benchmark.

What are you paying for that nobody uses? Licence audits routinely find a meaningful percentage of spend on software nobody opens.

Using benchmarks properly

As a check, not a target. If your number is far from a credible benchmark for your sector and size, that is a prompt to understand why — not evidence you are wrong.

Being well below might mean efficiency, or it might mean deferred refresh, thin security and a team that cannot keep up. Being well above might mean waste, or it might mean you are mid-migration, or in a regulated sector with genuine obligations.

The number alone does not distinguish these. The build-up does.

Presenting it to people who control budgets

What works, in our experience:

Separate run from change. "This is what it costs to keep operating; this is what we are proposing to invest in" is a far better conversation than one total.

Express risk in business terms. Not "we need endpoint detection" but "a ransomware incident would stop operations for several days; here is what reduces that and what it costs".

Show the consequence of deferral. If refresh is pushed out a year, say what that means for support cost, failure rate and risk. Decisions made with that visible are usually better.

Give options, not a single ask. Three levels with explicit trade-offs lets the decision be made by the people whose job it is, rather than being a yes or no on your number.

The honest summary

There is no correct figure. There is a defensible one, built from your user population, your sites, your obligations and your risk tolerance — and the ability to explain what each part buys.

A benchmark will not tell you whether you are spending the right amount. It will tell you whether you are unusual, which is worth knowing, and then the work of explaining why begins either way.