What an IT auditor does, and what independence requires

The job is widely misunderstood, including by people who commission it. An IT auditor is not a senior engineer who reviews code, and treating the role that way produces a review that reads like a critique and settles nothing.

The work is establishing what can be evidenced. Not what is true in the abstract — what can be demonstrated, to someone who was not there, from records that existed before anyone asked.

That distinction is the whole discipline, and it is why an it audit services engagement spends more time on records than on architecture.

What the work actually consists of

Defining the criteria. Before anything is examined, what constitutes a pass. Without this, an audit is one person’s opinion of a system, and opinions are not findings.

Collecting evidence. Access lists exported from the system rather than described. Deployment logs. The date of a restore test. Screenshots with timestamps. The distinguishing feature of evidence is that it was produced by the system rather than by a person answering a question.

Sampling. Nobody examines every change in a year. The auditor picks a sample, and how that sample was selected matters as much as what it showed. A sample chosen by the team being audited is not a sample.

Reporting. Findings, each with what was checked, what was found, and what the consequence is. Marked verified or reported, never blended.

Internal and external

Internal auditors work for the organisation, usually reporting to a board or audit committee rather than to management. Their advantage is context — they know which systems matter and where the awkward parts are. Their constraint is that they are reviewing colleagues, and their reporting line is what protects them from that.

External auditors come in without context and without that pressure. They cost more, take longer to become useful, and their findings carry more weight externally for exactly the reason that they have less to lose by making them.

Neither is better. Where a finding needs to be credible to a third party — investor, regulator, customer — external independence is not a preference, it is the thing being purchased.

Where independence quietly breaks

It rarely fails dramatically. It erodes.

The auditor who also implemented the fix. Reviewing your own remediation is not independent, and it is a common arrangement because the person who found the problem is the obvious person to solve it.

The auditor who reports to the person being audited. If findings pass through the head of engineering before reaching the board, the reporting line has removed the reason for the exercise.

The scope negotiated after the findings. Where areas are removed from scope once it becomes clear what they contain, the report describes what was convenient rather than what was in scope.

Fee dependence. A reviewer whose income depends on being invited back has an interest, and the honest response is to state it rather than pretend it away.

Certifications, and what they mean

CISA is the common credential for this work, and it signals familiarity with audit method and standards rather than technical depth. Security-focused credentials such as CISSP signal something different again.

None of them tells you whether the person can read your codebase. For a technology audit of a software product, ask what they will actually do — whether they will build the system, read the tests, check the dependency licences — rather than which letters follow their name. The answer separates people who examine systems from people who examine documents about systems.

What to ask before hiring one

Three questions separate people who examine systems from people who examine documents about systems.

What will you actually run? Whether they will build the system from source, read the tests, restore a backup. If the answer is that they will review documentation and interview the team, that is a legitimate exercise and a much weaker one.

How will you sample, and who chooses the sample? A sample selected by the team being reviewed is not a sample. The answer should describe a method.

What proportion of your findings will be marked verified rather than reported? Anyone who has not thought about that distinction is not going to apply it, and the distinction is most of what the report is worth.

The conflict I cannot design away

I write software and I perform reviews, which is precisely the combination that creates the first failure above. My position on it: I do not audit systems I built, and where a review finds work I could do, the recommendation says so and you are free to have someone else do it.

That is a policy rather than a structural guarantee. A genuinely structural answer means a reviewer with no delivery arm, and where independence is the product rather than the judgement, that is the right thing to buy.

Related reading: what an IT audit checks covers the five areas the role examines, the audit experience covers the same exercise from the side of the team being reviewed, and IT compliance audit covers the version where an external standard supplies the criteria.