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
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.