What an IT audit actually checks, item by item

The phrase covers a wide range of exercises, from a two-day look at a startup’s infrastructure to a regulated annual review with a defined standard behind it. What they share is a small number of questions, asked in different depth.

Five areas come up every time. Only one of them is about software, which surprises people who prepare by tidying their code.

The engagement that works through these is described under it audit services; this is the substance of what gets examined.

One: who has access to what, and who granted it

The first and most productive area, because the answer is nearly always worse than expected.

An auditor will ask for a list of every account with administrative access to production, and then ask who approved each one and when it was last reviewed. The common finding is not a malicious account. It is three accounts belonging to people who left, two service accounts nobody can identify, and a shared login whose password is in a document.

A weak answer sounds like “only the engineering team has access.” A strong one is a list, generated from the system rather than from memory, with a review date on it.

Two: whether changes are controlled

Not whether change is slow — whether it is traceable. Can you show, for a given change in production, who made it, who reviewed it, and when it was deployed.

This is straightforward with version control and a deployment pipeline, and it falls apart wherever someone can change production directly. The question auditors return to is whether the pathway that bypasses the process exists at all, because a control that can be skipped without a trace is not a control.

Three: whether the data can be recovered

Backups get claimed more often than they get tested. The question is not whether backups run; it is the date of the last successful restore, and who performed it.

The uncomfortable follow-up is the recovery time. Many organisations have backups that would take days to restore into a usable state and a business assumption of hours. That gap is a finding whether or not anything has ever gone wrong.

Four: whether anyone would notice

Monitoring that alerts on infrastructure but not on outcomes leaves a specific blind spot: the system stays up and stops doing its job. Orders queue, a nightly job silently fails, a feed goes stale.

The check is to ask what alert fires when a business process stops, and who receives it. Alerts routed to a channel nobody reads are a documented control and an undocumented failure.

Five: the software itself

Dependency currency, known vulnerabilities, whether secrets are in the repository, whether test coverage means anything. This is the part most teams expect to be the main event, and in most audits it is one area of five.

It matters, but a well-written application with uncontrolled production access and untested backups is in worse shape than an ordinary one with both handled.

What makes the exercise useful rather than theatre

The distinction between what was verified and what was reported. An audit that records “backups are performed nightly” because someone said so is a different artifact from one that records the date of the last restore test.

Findings should also carry a consequence. “Shared administrative account” is an observation. “Shared administrative account, so no change can be attributed to an individual, which defeats the change-control evidence in area two” is a finding, because it says what breaks.

How to prepare

Do not tidy the code. Produce three lists instead: everyone with production access, every third-party service holding your data, and the date of the last restore test.

If assembling those takes more than a day, that difficulty is itself the first finding, and you have learned it privately rather than in a report.

Where the five areas overlap

The areas are separated for clarity and they interact, which is where the more interesting findings sit.

Access control and change control are the same question asked twice: an administrative account that can alter production directly makes the change records incomplete, regardless of how good the pipeline is. Recovery and monitoring interact the same way — a backup that restores perfectly is not much use if nobody notices the corruption for six weeks and every backup in retention already contains it.

The single most useful follow-up an auditor can ask is how two controls fail together. Controls are usually designed one at a time and fail in combination.

What an audit cannot tell you

It cannot tell you whether you have been breached. It examines controls and evidence, not forensics, and a clean audit is consistent with a compromise nobody has detected. If that is the question, you want incident response rather than an audit, and the two get confused regularly.

It also cannot certify anything on its own. Where a counterparty requires a specific standard, that is a separate exercise with its own assessor.

Related reading: the audit process covers the stages and how long each takes. IT compliance audit covers the version driven by a standard rather than by curiosity. And the IT auditor’s role covers who performs these and what independence means in practice.