IT Department Audit: Capability and Whether Spending Fits

Finance can tell you within two minutes what the company spent on technology last year. Far fewer organisations can tell you what they got for it.

Financial statements go through independent audit every year. Production lines get periodic inspection. Occupational safety is reviewed on a schedule. The function that consumes roughly five percent of company turnover is usually measured by one mechanism only: the volume of complaints. Fewer complaints reads as good performance — which ignores the possibility that people have simply stopped bothering to complain.

Why the two axes cannot be separated

An IT audit is often assumed to be a security exercise. The questions a board actually wants answered are different, and there are two of them:

Is the team capable? Are the right people, in the right numbers, working on the right things?

Is the money going to the right place? Does the budget serve what the organisation needs now, or habits inherited from earlier years?

These look independent, but from the outside they produce the same symptom. A capable team on a starved budget and a comfortable budget spent badly are indistinguishable from the corridor: systems are slow in both, projects slip in both, and management asks the same question in both — “we spend this much, why is it still like this?” Prescribing before diagnosing usually ends with a bigger budget funding a bigger version of the problem.

Certification audits and field audits ask different questions

Standards-based reviews have real value, but they answer a narrower question. A framework such as ISO 27001 largely asks whether documentation exists and whether the process is defined. Is the policy written, is the procedure approved, are records kept.

A review conducted on field experience goes one step further and looks for evidence that the system actually works. In practice the difference looks like this:

A documentation review asks	A field review asks
Do you have a backup policy?	When was the last restore test, how long did it take, who ran it?
Do you have an access authorisation procedure?	On what date were the accounts of the last five leavers closed?
Is your asset inventory current?	What is the gap between devices in the inventory and devices on the network?
Is patch management defined?	As of today, how many servers are more than three months behind?
Do you have a disaster recovery plan?	If the server room flooded this morning, at what hour could you enter the first order?
Are supplier contracts filed?	How many contracts auto-renewed this year, and which of them go unused?

What the right-hand column has in common is that answers must come with evidence. “Yes, we do” isn’t an answer; a date, a duration, a log or a screenshot is. Any item where evidence cannot be produced enters the report as a finding rather than a statement.

There is a second advantage. The organisation doesn’t have to prepare for a standard. In a certification audit, a company spends months assembling documentation and closing gaps before the assessor arrives — and the assessment largely measures that preparation. A field audit works more like an unannounced exam, which is precisely why it reflects reality.

The capability axis: how well does the team do what it does?

Measuring capability by certificate count is misleading. There are excellent system administrators with no certifications, and there are people with a wall of them who cannot be trusted in a production environment. Measurement has to look at output.

Dependence on one person. The most revealing question in most audits is simply this: if the most critical person on the team took two weeks off, what would stop? An answer of “nothing” means either genuine maturity or a question not taken seriously — the two are easy to tell apart. A specific list means you are holding the first page of the risk map. Knowledge living in one head is not misconduct, it is a structural flaw, and it usually takes a few weeks to fix.

Reactive work versus preventive work. How much of the team’s time closes faults, and how much prevents them? A crude but useful indicator is the share of tickets recurring from the same root cause. If the same printer fails four times a month, all four may be marked resolved. None of them was.

What the headcount buys. International comparisons put IT staffing somewhere between 0.7 and 4.3 people per 100 users, with a median near 1.6. On the service desk, a common reference is one technician per 70 to 100 users. These are not targets; they exist to make deviation visible. If a 40-person company runs a three-person IT team, the question isn’t “is that too many” but “what are those three people spending their time on”.

Decision quality. Looking at the rationale behind the last three significant purchases tells you more than most technical tests. Were alternatives assessed? Did the decision rest on a needs analysis or on a vendor presentation? Was the expected benefit measured after the fact?

Who manages whom. In a healthy structure, IT manages the supplier. When it inverts, the signs are consistent: renewal dates are learned from the vendor, diagnosis is limited to what the vendor states, competing quotes are never obtained. This is rarely incompetence — usually it is a shortage of authority and time, and separating the two is the auditor’s job.

The distance between what is written and what is known. Is the network diagram current, where are the server credentials held, who has the vendor contact for the critical application? If two of those three get a “let me ask” response, the organisation’s IT knowledge lives in individuals rather than in the organisation.

The spending axis: where does the budget go?

The purpose here is not to cut costs, but to see whether spending matches what the organisation needs. Cheap infrastructure that halts production is far more expensive than costly infrastructure.

Two comparisons open the analysis:

Share of turnover. Sector averages put IT spending somewhere between roughly 2% and 10% of revenue, with an overall average near 5.7%. Capital-intensive sectors such as manufacturing sit at the lower end (2–5%), financial services at the upper end (7–10%). Smaller organisations naturally show higher ratios, because fixed costs are spread across fewer users.

Run, grow, transform. How much of the budget keeps the existing estate alive, how much adds capacity, how much builds new capability? A common reference is around 70/20/10. Once the run line passes 80%, the organisation is funding a maintenance cost rather than an investment — and raising the budget won’t fix that, only enlarge it.

The same places give up money in audit after audit:

Item	Typical finding	Reference data
Subscription software	A significant share of purchased seats never gets used	Industry measurements put unused licences at 36–46%
Cloud resources	Oversized instances, resources nobody switched off	2026 measurements classify 29% of cloud spend as waste
Auto-renewing contracts	Services paid for another year because the cancellation window was missed	—
Overlapping tools	Two, sometimes three products doing the same job	—
Software bought outside IT	Departmental subscriptions that never reach the inventory	75% of employees are expected to acquire technology outside IT’s visibility by 2027
Dormant lines and hardware	Uncancelled circuits, maintenance contracts on unused equipment	—

None of these come from bad intent. They accumulate. Someone leaves and their licence isn’t cancelled. A project ends and the test server stays up. A department buys its own tool and nobody hears about it. The value of an audit sits exactly here: doing once the work that is nobody’s job.

One caution belongs alongside this. The first lines cut under a savings programme are usually backups, monitoring and training — because cutting all three produces no visible effect the next day. The effect arrives six months later, on a bad day. A spending review should defend those lines as seriously as it prunes the wasteful ones.

How the audit runs

A working corporate review generally fits into a week of fieldwork.

1. The request list. Documents are requested before anyone arrives: asset inventory, contract list, twelve months of IT expenditure, org chart, ticket records. How much of that list arrives, and in how many days, is the first finding.
2. Interviews. Not only with IT. Three or four people each from production, sales, finance and procurement — the picture doesn’t complete without them. Two accounts of the same incident often become the most valuable part of the report.
3. Evidence sampling. Every claim gets tested against a few randomly chosen examples. You cannot verify that every backup restores; you pick three and try them.
4. Measurement and comparison. Figures are compared against sector bands and against the organisation’s own history.
5. Report and closing meeting. Findings are ranked by money and risk, each with a proposed owner and date.

Report length is not a quality signal. A two-hundred-page document generally goes unread. A table of fifteen findings ordered largest to smallest, each with an estimated amount, a recommended action and a timeframe, is what actually gets used in a board meeting.

The human side

The fragile part of this work isn’t technical. An IT team reads an audit as an investigation and moves to defend itself, and collecting evidence from a defensive team becomes very hard.

A few rules help in the field. State from the outset that the audit measures the system, not the person. Give the team the first chance to write its own assessment — most teams already know half the problems, they just haven’t found the language to put them to management. Share findings with the team before the closing meeting with the board, not after. And don’t let the report become a list of criticisms without remedies.

In practice the most common outcome of an audit is not the IT team being replaced. It is the budget they have been requesting for years finally getting approved. That tends to be the most tangible benefit an independent report gives the team.

Frequently asked questions

We already outsource our IT. Is an audit still meaningful? Very much so. Under an outsourced model the focus shifts from team capability to contract and service quality: does the service delivered match what is invoiced, do response times meet the commitment, and are administrator credentials and records held by the organisation itself. That last point becomes decisive the day you need to change provider.

How long does it take, and will it disrupt the business? Fieldwork in a mid-sized organisation typically runs three to five days. The disruptive part is interviews, at half an hour to an hour per person. Systems are not touched, so operations are unaffected.

Is the cost known up front? No, because scope varies enormously. A single-site operation and a five-branch group running two separate ERP systems are not the same job. The sequence that works: take the request, clarify depth and scope in a short preliminary conversation, then issue a quote.

Couldn’t our own IT manager run this? Asking someone to measure their own work makes the outcome predictable. That is the value of independence — and an outsider also brings comparison from what they have seen elsewhere. A self-assessment prepared by the internal team works well as an input to an independent audit, not as a substitute for one.

Should whoever writes the report also do the remediation? Keeping them separate is healthier. An auditor recommending the solution they intend to sell undermines the credibility of the report. Implementation should be treated as a separate decision, and the report written so it can be acted on with more than one provider.

How often should it be repeated? A follow-up a year after the first audit, then every two years, is usually enough. Between cycles, the thing to track internally isn’t the report — it’s the closure rate of the items in it.

If you would like your IT function reviewed independently along these two axes, you can send a request through the contact form and we will scope depth and duration before quoting.