Writing an audit plan that decides something

The plan is written before anything is examined, and it determines almost everything about whether the exercise is worth its cost. It is also the document most often treated as a formality — a page naming some systems and some dates.

A plan that lists systems produces a survey. A plan that lists questions produces answers. The difference is the whole document.

The version described here is what an it audit services engagement writes first, and it is short — two or three pages, not twenty.

Component one: the questions

Not “review the payments platform.” Rather: can a payment amount be altered in production without a second person seeing it, and would there be a record.

Written as questions, three things follow. The evidence needed becomes obvious. The examination has a stopping point. And the report has a shape, because each question gets an answer.

Five to ten questions is the usual range. More than that and the review is spread too thin to answer any of them properly.

Component two: the criteria

For each question, what constitutes a pass, agreed before the evidence is seen.

This is the component that prevents the argument at the end. Without criteria, findings are contested on the grounds that the standard was never stated, and that objection is fair.

Criteria do not have to be strict. “Access reviewed at least annually, with a dated record” is a low bar, and a low bar agreed in advance is far more useful than a high bar improvised afterwards.

Component three: the sample

Nobody examines every change in a year. The plan states how many will be examined and how they are chosen.

Two properties matter: the sample is selected by the reviewer, and the method is stated. A sample chosen by the team being reviewed is not a sample, and a sample whose method is unstated cannot be reasoned about.

The size matters less than people expect. Ten changes chosen randomly tell you more than fifty chosen conveniently.

Component four: what is out of scope

The component most often omitted, and the one that protects both sides.

Stating that penetration testing, code quality assessment and vendor review are excluded stops the review drifting into them. It also stops the report being read as covering ground it never touched — an unexamined area and a clean one look identical unless the document says which is which.

Component five: access and timing

What access is needed, from whom, by when. Because access is what sets the timeline rather than analysis.

Naming the people required, including the ones outside engineering, is the single most effective schedule intervention available. Licence and contract questions need finance and legal, and those requests arrive late if nobody scheduled them at the start.

What a plan does not need

A methodology section describing audit theory. A list of standards referenced for credibility. An organisational chart. Anything written to demonstrate rigour rather than to constrain the work.

Length is a reasonable proxy for quality here, inversely. A twenty-page plan usually contains two pages of decisions and eighteen of framing.

Agreeing it is the point

The plan should be agreed by both sides before stage two, and the agreement is what makes the rest work. It converts every later request into something traceable — a request that does not map to a question in the plan is a request worth challenging.

That is also the honest protection for the audited team. Scope drift is the common failure of these exercises, and a plan nobody signed provides no basis for pushing back on it.

Who should sign it

Both sides, and on the audited side it should be someone who can commit the time rather than someone who can approve the fee. Those are frequently different people, and a plan agreed only by the second produces a schedule the first has no capacity to meet.

What planning cannot anticipate

Findings that change the useful questions. Occasionally stage three turns up something that makes the original scope look beside the point — an entire system nobody listed, or a control that fails in a way that implicates several others.

The right response is to amend the plan explicitly, with both sides agreeing, rather than to quietly widen. An amended plan is a record of a decision. Silent expansion is how a two-week review becomes a six-week one with nobody able to say when that was decided.

I would also say plainly that a good plan does not guarantee a useful audit. It removes the most common way of wasting one, which is not the same thing.

Related reading: the audit process covers the five stages this plan governs, the audit experience covers how the plan protects the team being reviewed, and what an IT audit checks covers the areas the questions usually come from.