The Walkthrough Stops Working: IT Audit Methodology for AI Systems

IT audit methodology assumes a system can be read. AI systems cannot be, in the sense the methodology means. Three things change: design testing moves upstream to the process that produced the model, sampling gives way to full population testing, and opinions acquire a shelf life.

Published 2026-08-19 · By Shahzad Asghar

Every IT audit methodology I have worked with assumes the system can be read. You can open it, follow the logic, and satisfy yourself that the control is designed to work before you ever test whether it did. AI systems break that assumption, and the methodology has to move.

In an earlier piece I argued that AI agents are participants in the control environment rather than tools, and that this makes them auditable entities. Several people who read it asked a fair follow-up question: fine, but what actually changes in the methodology?

This is my answer. It is narrower and more technical, and it is aimed at IT audit specifically rather than internal audit generally. The short version is that three things change and one thing does not, and the profession will get into trouble if it confuses which is which.

The walkthrough stops working

Start with the walkthrough, because it is the piece of the methodology that fails first and most visibly.

A walkthrough exists to establish design effectiveness. You take one transaction, follow it through the system end to end, and confirm that the control does what the documentation says it does. It is cheap, it is fast, and it is the foundation for everything after it. If the design is not effective, you do not proceed to test operating effectiveness. You raise the finding and move on.

Now walk through a model.

You can read the code that calls it. You can read the code that handles the response. What you cannot do is read the part that makes the decision, because the decision is distributed across several billion parameters that were fitted rather than written. There is no logic to follow. Nobody wrote a rule that says a claim over this threshold with these characteristics is refused. The behaviour emerged from the training data, and the training data is usually somebody else's.

This is not the same as auditing a complex system. Complex systems are hard to read. This one cannot be read at all, in the sense the methodology means.

The instinct is to declare design effectiveness untestable and fall back on outcomes. I think that is wrong, and it gives up the most valuable thing IT audit does. Design effectiveness is still testable. The object just changes.

Design effectiveness moves upstream

If you cannot inspect the model, inspect the process that produced it. That is where design lives now.

What I would want to see, and what I would write a finding about if it did not exist:

The problem statement, in writing, from before the build. What decision is this system making, for whom, and what happens when it is wrong. Systems built without this are almost always systems where nobody can tell you what an acceptable error rate is, because nobody ever decided.

The data lineage. Where the training data came from, what the organisation is permitted to do with it, and what was excluded. In humanitarian and public sector work this is often the whole audit, because the lawful basis for the processing is the control that matters most.

The evaluation, and who signed it. Not the accuracy figure. The test set, how it was constructed, whether it resembles the population the system will actually meet, and what performance looked like across the subgroups you care about. An aggregate accuracy number on a test set drawn from the same distribution as the training data tells you almost nothing about a deployment in a different country.

The threshold decision. Somebody chose the operating point that trades false positives against false negatives. That is a policy decision wearing a technical costume, and it should have been made by someone accountable rather than defaulted to by whoever ran the notebook.

The change history. Model version, prompt version, retrieval corpus version, and what triggered each change.

None of that requires reading the model. All of it is documentary evidence of the kind IT audit already knows how to test. The methodology holds; the artefacts are different.

ISACA's Artificial Intelligence Audit Toolkit is built along these lines, as a control library organised around the AI lifecycle rather than around the model as an object. The 5th edition of ITAF, released this year, adds AI and machine learning guidance to the framework itself. That matters more than it sounds: it means an IT auditor does not have to invent a methodology, which is exactly what tends to happen when a profession meets something new and panics.

Sampling was always a workaround

Here is the part of the change I actually welcome.

We sample because testing everything was impossible. That is the only reason. Sampling is a concession to cost, dressed up over the decades as a methodology with its own literature, its own confidence intervals, and its own comfortable rituals. No auditor has ever preferred a sample to the population.

For automated controls in modern systems, that constraint has largely gone. If the control is a rule in an application and the population sits in a queryable store, you can test all of it. Not twenty-five items. All of it. And once you can test all of it, the sampling conversation stops being about statistics and starts being about whether you bothered.

This is the genuine methodological gain in the current moment, and it is being underplayed because it is less exciting than talking about agents. A finding that says three of twenty-five items failed is an estimate. A finding that says 1,142 of 84,000 transactions failed, and here they are, and here is what they have in common, is a different kind of object. It is harder to argue with and much easier for management to act on.

It also changes what a finding is for. When you can characterise the whole failing set, you can often tell the client *why* it failed without a separate root cause exercise, because the pattern is visible in the population.

I would push any IT audit function to move its high-volume automated control testing to full population before it does anything at all about AI. It is less glamorous and it is worth more.

Evidence now has a shelf life

The third change is the one I find hardest, and I do not think the profession has resolved it.

An IT audit opinion is conventionally point-in-time or period-based. You tested the control over the period, you concluded on it, and the conclusion stands for that period. That works because deterministic controls do not change unless somebody changes them, and changes go through change management, which you also tested.

Model behaviour changes without anyone changing anything. The input distribution shifts. The retrieval corpus grows. The vendor updates the base model underneath an API you do not control. None of that goes through your change management process, and some of it is invisible from inside your estate.

So an opinion on an AI control decays in a way that an opinion on an access control does not. Tested in March, it may not describe June.

There are only two honest responses. Either you narrow the opinion, stating explicitly the model version, prompt version and period it covers, and accept that it says nothing about the system today. Or you move to continuous monitoring and audit the monitoring rather than the model, which means your finding is about whether the organisation would notice drift, not about whether drift has occurred.

I lean towards the second, because the first produces assurance with a shorter useful life than the report takes to clear. But the second is only honest if the monitoring is real: a baseline, thresholds, an owner, and an escalation path that has been tested at least once. Monitoring that produces a dashboard nobody reads is not a control, and an auditor who accepts it as one has been sold something.

The control catalogue is the practical problem

Everything above is conceptual. The thing that actually stalls engagements is more mundane: your control catalogue does not have entries for any of this.

Most IT audit functions work from a mapped set of controls, tied to a framework, tied to a risk register. Add AI systems and you find that the risks do not map. There is no existing control for "the operating threshold was chosen by an engineer with no delegated authority to choose it." There is no existing control for "we cannot tell which of our vendors changed their model last month."

Two failure modes follow, and I have seen both.

The first is forcing the new risk into an old control, usually one about change management or vendor management, so that the mapping looks complete. The risk then disappears from view, because the control it is mapped to does not test for it.

The second is building a parallel AI control framework from scratch, disconnected from the main catalogue, which produces a document that impresses people once and is never used again.

The workable path is boring: extend the existing catalogue with a small number of genuinely new controls, map them into the framework you already use, and accept that the number is small. Most AI risk is not novel. Access control, change management, data governance, vendor assurance and logging cover the majority of it, applied to a new class of object. What is genuinely new is a short list, and the AI-specific control libraries now published by ISACA and the criteria in ISO/IEC 42001 and the NIST AI Risk Management Framework will give you most of it without drafting from scratch.

If your extended catalogue has two hundred new AI controls, somebody has been generous with the copy and paste.

What the IT auditor has to be able to read

Skills, briefly, because this is where functions either invest or quietly decide not to.

You do not need to build models. You do need to be able to read four things without help: a model card or system card, an evaluation report, a data flow diagram for a system with a retrieval step, and a log schema. If nobody in the function can look at an evaluation report and ask why the test set was constructed that way, the function cannot audit these systems, and no amount of framework adoption fixes it.

The uncomfortable follow-on is that this is a hiring and training question with a lead time measured in years, arriving at the same moment as the pressure to cover AI systems now. Most functions will resolve that with external specialists on the first few engagements. That is a reasonable answer as long as it comes with a plan for the knowledge to end up inside the function. Otherwise you have bought a report rather than built a capability, and you will buy it again next year.

Where the methodology holds

Having argued that three things change, let me be equally clear about what does not, because I think the professional instinct to treat AI as a special case does more damage than the technology.

Risk assessment still drives scope. Most AI systems in most organisations are low consequence and deserve no engagement at all.

Evidence standards are unchanged. Sufficient, appropriate, reliable. A vendor's assurance that their model is fair is not evidence. Their evaluation methodology, with results you can examine, might be.

Independence is unchanged, and will be tested more than usual, because IT audit is often the only function in the building that understands both the technology and the control environment. That makes you useful to the people building these systems, and being useful in that room is fine right up to the moment you start making design decisions you will later be asked to audit.

And professional scepticism is unchanged, though it now has to survive contact with systems that produce fluent, confident, well-formatted output. Fluency is not evidence. It has never been evidence. It is simply harder to remember when the output reads well.

The honest summary

IT audit does not need a new methodology for AI. It needs to move design testing upstream from the artefact to the process that produced it, to abandon sampling wherever full population testing is now possible, and to accept that some of its opinions expire faster than they used to.

That is a real change and it is manageable. What is not manageable is pretending the walkthrough still works, and issuing an opinion on a system nobody in the room can read.

Frequently asked questions

How does IT audit test the design of an AI control if the model cannot be inspected?

By auditing the process that produced the model rather than the model itself. That means examining the documented problem statement, data lineage and lawful basis, the evaluation methodology and its test set construction, the operating threshold decision and who held authority to make it, and the version history covering model, prompt and retrieval corpus. These are documentary artefacts that existing IT audit methodology already knows how to test.

Should IT auditors still use sampling for automated controls?

Only where the population genuinely cannot be tested in full. Sampling exists because exhaustive testing was impractical, not because it is methodologically preferable. Where an automated control operates on a queryable population, full population testing gives a stronger finding, identifies the failing items rather than estimating them, and often reveals the root cause pattern directly.

Why does an audit opinion on an AI system expire faster than a conventional one?

Because model behaviour changes without any change being made by the organisation. Input distributions shift, retrieval corpora grow, and vendors update base models behind APIs the client does not control. None of this passes through change management, so a conclusion reached in one period may not describe the system in the next.

What frameworks should an IT audit function use for AI systems?

ISACA's ITAF 5th edition adds AI and machine learning guidance to the existing IT audit framework, and its Artificial Intelligence Audit Toolkit provides a control library organised around the AI lifecycle. ISO/IEC 42001 and the NIST AI Risk Management Framework supply subject-matter criteria. Building a parallel framework from scratch is rarely necessary and usually produces a document that is never used twice.

How many new controls does an AI system actually require?

Fewer than most functions expect. Access control, change management, data governance, vendor assurance and logging already cover the majority of AI risk when applied to a new class of object. The genuinely new controls are a short list covering evaluation evidence, threshold authority, drift monitoring and model provenance. A catalogue extension running to hundreds of new AI controls usually indicates duplication rather than thoroughness.

What skills does an IT auditor need to audit AI systems?

The ability to read a model or system card, an evaluation report, a data flow diagram including a retrieval step, and a log schema, and to question each without assistance. Building models is not required. Using external specialists for early engagements is reasonable, provided there is a deliberate plan for the knowledge to transfer into the function rather than being repurchased each year.

---

*Shahzad Asghar is a senior technology, security and risk leader with more than twenty years across United Nations and humanitarian organisations, spanning country, regional and headquarters operations. He authored a country operation's first ISO 27001-aligned cybersecurity audit, has governed inter-agency data sharing agreements at scale, and currently applies the NIST AI Risk Management Framework and ISO/IEC 42001 to live AI systems. He holds CISA, CISM and CISSP, and is a member of ISACA. He writes on information technology audit in the age of AI, AI governance, AI security, and assurance for the public sector at shahzadasghar.com.*

← All articles