A request for an IT audit rarely arrives at random. It goes with a particular moment: an acquisition, a change of leadership, a supplier whose value has become hard to measure, or a failing flagged by a third party.
That context determines what the audit has to produce. In every one of those cases, somebody has to decide something quickly, on a subject they do not command.
What a structured framework covers
- infrastructure, workstations, network
- business applications and how well they fit actual use
- data, backups, and whether a restore has actually been tested
- security, access management and what happens when people leave
- contracts, suppliers, service commitments
- regulatory compliance and data processing
- costs, licences, dormant subscriptions
- in-house skills and dependency on individuals
- continuity: what happens if it stops
The number of checkpoints matters less than the discipline of going through all of them. An audit’s blind spots are not the hard subjects: they are the ones skipped because nobody flagged them.
Interviews beat questionnaires
An inventory describes what the system is meant to do. Interviews with the people in post reveal what teams actually do: the shadow spreadsheets, the supplier called directly, the procedure worked around for two years because it never worked.
The most instructive gap in any audit is between what the system is meant to do and what teams actually do.
That gap is not a fault to be corrected: it is information. A workaround that lasts almost always signals a badly chosen tool or a badly designed process.
Who the report is for
This is the question that decides whether any of the work is useful. A report written for the IT department will be read by it, commented on by it, and go no further — when it is assessing precisely that department’s remit.
The report has to be readable by whoever signs off the budget. That means ranking findings, costing them, and turning each one into a concrete consequence rather than a version number.
What an audit does not do
The question of the audience covers an older one: two distinct exercises are sold under the same name, and people often commission one while expecting the other.
A report is worth nothing if it leads to no arbitration. That is exactly what a roadmap with three costed scenarios is for.
It does not decide in the owner’s place, and it does not replace the technical expertise of those who run the system. It puts the two in a position to talk to each other: clearly stated requirements on one side, answers that can be assessed on the other.
Common questions
How do you write an IT audit report that supports decisions?
By writing it for whoever decides the budget, not for the IT function. It ranks the findings, prices them, and turns each into a concrete consequence for the business rather than a version number. A report only an IT specialist can read enables no decision.
What does a complete IT audit cover?
Nine areas: infrastructure and devices, business applications, data and tested backups, security and access management, contracts and suppliers, compliance, costs and licences, in-house skills, and business continuity. The discipline of covering them all matters more than the number of points.
Why use interviews rather than a questionnaire in an audit?
Because a questionnaire captures what people think they do, while an interview reveals what they actually do: parallel spreadsheets, a supplier called directly, a bypassed procedure. That gap is the most useful information an audit produces.