Internal audit of technology: what it catches and what it cannot

An internal audit function reviews the organisation it belongs to. That single fact produces both its advantage and its structural weakness, and which one prevails is decided almost entirely by who the function reports to.

Everything else — methodology, tooling, the auditor’s technical depth — matters less than that reporting line, which is an uncomfortable conclusion for anyone who would rather improve the method.

The independent version of this exercise is described under it audit services; this is about when the internal one is the better instrument.

What internal catches that external does not

The things that are wrong most of the time. An external reviewer sees a fortnight, usually a prepared one. Someone inside sees the ordinary week, and ordinary weeks are where controls actually fail.

The gap between the documented process and the real one. Every organisation has both. An outsider is shown the documented one and has to work outward from it. An insider already knows which steps get skipped when a release is late.

Things nobody would think to ask about. External scope comes from a conversation. If a system was not mentioned, it is not examined. Internal scope comes from knowing the estate.

Follow-up. The single biggest failure of external reviews is that findings are never re-tested. An internal function is still there in three months, which makes re-testing a routine act rather than a new engagement.

What internal cannot do

Be credible to a third party. An investor, acquirer or enterprise buyer discounts internal findings, and they are right to. The value being purchased externally is independence, and independence is not something an internal function can assert.

Report freely on its own management. This is the structural weakness. If the function reports to the head of engineering, findings about engineering pass through the person they concern. Nobody has to behave badly for that to distort the output — it distorts what gets written before anyone has to decide anything.

Escape familiarity. Reviewing the same systems for three years produces expertise and blind spots in equal measure. The arrangement everyone has stopped questioning is the one an outsider notices in an afternoon.

The reporting line, which is the whole question

An internal function that reports to a board or audit committee can write findings about management. One that reports to management can write findings about everyone else.

If you are setting one up, that decision is the design. It is also the decision most often made by default — the function is created inside the technology organisation because that is where the expertise is, and its independence is compromised at the moment of its creation without anyone intending it.

Sequencing the two

The productive arrangement is not one or the other.

Internal runs continuously: quarterly access reviews, change sampling, restore testing, follow-up on open findings. This is the work that benefits from context and repetition, and it is uneconomic to buy externally at that cadence.

External runs periodically, on a narrow scope, and one of the things it examines is the internal function itself — whether its sampling is real, whether findings get closed on evidence, whether anything has been quietly descoped.

That last part is where the money is well spent. Reviewing the reviewer is cheaper than reviewing the estate, and it tells you whether the continuous work can be trusted.

For organisations too small for a function

Most companies under a hundred people should not create one, and the useful substitute is a named person with a checklist and a recurring calendar entry.

Quarterly: export the production access list and review it. Annually: restore a backup and record the date. Continuously: ensure changes reach production only through a path that logs them.

That is not an internal audit function. It is three controls operated on a schedule, and it covers most of what a small organisation would get from one.

The first thing a new function should do

Build the inventory, before reviewing anything. A function that starts by auditing the systems it was told about inherits the blind spots of whoever told it.

What I would not claim here

I do not run internal audit functions, so this is a view from the external side of the arrangement — what I see when reviewing organisations that have one, and what the failures look like from outside. Someone who has run one internally would have a sharper account of the day-to-day constraints, and I would defer to it.

I also cannot tell you the headcount at which a function becomes worthwhile. That depends on regulatory exposure far more than on size, and any threshold I offered would be a guess.

Related reading: audit best practices covers the practices that hold up under an internal reporting line, the audit process covers the stages either version runs, and the audit plan covers the scoping document that matters more when the reviewer is a colleague.