What ISSAI 3000 actually requires of an audit’s design — and how to build a matrix that governs the audit rather than merely recording that planning happened. A practitioner’s walkthrough, with a one-page template to use.
1. The problem auditors face
One problem faces most audits near the beginning: how to structure the work in a way that is logical, and clear enough for both the audit team and its reviewers to follow. The usual answer is the design matrix — a tool most auditors have filled in, and fewer have used. In many teams the matrix is a form: a document completed at the start of an audit because the methodology asks for it, filed with the planning papers, and rarely opened again. It stands as evidence that planning happened, not as the instrument that makes planning sound.
The cost of this shows up later. The questions, sub-questions and criteria in the matrix are meant to be drawn from a pilot study — the preparatory work a team carries out once the board has set a topic, before the audit is proposed. When that pilot study is thin, or when prior belief about the audited body stands in for it, the matrix rests on assumptions rather than tested knowledge. And even a sound pilot study cannot settle everything: it is in the nature of the work that some questions and criteria will shift once the audit is under way and the picture moves. Evidence the matrix assumed would be available turns out not to exist, or does not bear on the question, or cannot be measured clearly enough; questions that seemed to target the problem stop short of its cause, and have to be rewritten.
None of this is a failure of the auditor. The standards treat performance auditing as iterative; a design that survives contact with the evidence untouched is the exception, not the mark of good planning. The narrower failure is treating the matrix as a fixed artifact rather than a live one — completed once, rather than revisited as understanding improves.
A related habit compounds the problem. The reasoning that links a question to the evidence that will answer it — that the evidence will be sufficient and appropriate — is often pushed out of the matrix into a separate evidence collection plan, completed for the file reviewer. Cut off from the criteria it serves, it goes cold: a step to be signed off rather than a working tool, and the connection that most determines whether the audit can conclude is the least examined while it runs.
2. What the standards actually say
Begin with what the standards do not say. ISSAI 3000, the standard for performance auditing, does not require a document called a “design matrix,” nor does it prescribe a specific template. What it does require is the underlying reasoning that a well-designed matrix helps to capture.
That reasoning follows a clear sequence. ISSAI 3000 requires an audit to have clearly defined objectives and audit questions; suitable criteria that are reliable, objective, useful and complete; and procedures designed to obtain sufficient and appropriate evidence to answer the audit objective. GUID 3910, Central Concepts for Performance Auditing — previously issued as ISSAI 3100 — defines concepts such as audit objectives, criteria, evidence and assurance. GUID 3920, The Performance Auditing Process, describes the phases of an audit and, importantly, emphasises that the process is iterative.
So the purpose of a design matrix is to make the links between objective, questions, criteria and evidence explicit — and to test, before fieldwork, whether a well-supported conclusion on the objective is reachable.
The standards also place these requirements in a broader process, and where the matrix fits matters as much as what it contains. Under ISSAI 3000, audit topics are selected through the SAI’s strategic planning process: based on risk and problem analysis and the SAI’s mandate, the board may identify a broad area of interest — such as poverty or climate change — rather than a fully developed audit question.
GUID 3920 places the work required to turn such a topic into an auditable engagement within the planning phase, which includes topic selection, the pilot study and audit design. During it, the team and its manager build the knowledge needed to formulate the objective, questions and criteria and to judge whether the audit is feasible.
The completed design matrix is therefore not the starting point. It is the distilled result of the pilot study. It goes to the board in the audit proposal, for approval before fieldwork begins. The underlying test is one of auditability: do suitable criteria exist, and is the information needed for the audit likely to be available and obtainable without disproportionate effort?
Two points follow, and resolve much of the confusion around the tool.
The first concerns evidence. Obtaining sufficient and appropriate evidence is mandatory; documenting the plan for obtaining it in a particular format is not. ISSAI 3000 requires auditors to design procedures that will produce evidence relevant to the audit objective, but not that those procedures be recorded in a design matrix, a separate evidence-collection plan or any other prescribed document. The reasoning is compulsory; the format is left to the auditor. The standards therefore leave room to fold the evidence strategy into the matrix, alongside the criteria it supports, rather than exile it to a separate form.
The second point concerns the audit report, where the standard does impose a duty of transparency: the report must explain the audit objective, scope and methodology, the data gathered and any significant limitations, and how the auditors reached their findings and conclusions against the selected criteria. That duty applies to the published report, not to the underlying planning tool. A clear methodology section satisfies it; the matrix itself need not appear in the report. The matrix can therefore hold more than the report shows — the full evidence reasoning from planning — while the published account stays concise.
Taken together: the design matrix is a means of meeting the requirements, not a requirement in its own right. Sound reasoning makes the format secondary; a form without it satisfies nothing the standards actually ask for.
The design matrix is a means of meeting the requirements, not a requirement in its own right.
3. How to do it in practice
The work begins before the matrix does. Take the topic as the board has set it — broad by design, an area such as poverty or climate control in schools rather than a formed question — and treat the pilot study as the one preparatory phase that turns it into something auditable. There is a single pilot study, rarely time for a second, so it must do its work in one pass. Everything that later goes into the matrix should be drawn from that study: the objective, the questions, the criteria and the feasibility judgment. The discipline is not to let prior belief about the audited body stand in for knowledge the team has actually built.
Build the matrix in causal order, from the top down. Start with the main audit question — the single question the audit exists to answer. Break it into sub-questions that are mutually exclusive and that, taken together, answer the main question in full; if the sub-questions leave a gap, or overlap so that one swallows another, the logic is not yet sound. For each sub-question, set the criterion: the standard of “what should be” against which the situation will be judged. Attach the source of every criterion in the matrix itself — a law, a regulation, a policy decision, an established norm — so that when a criterion is contested during clearance, its basis is already on the page rather than reconstructed from memory.
Then comes the step that most determines whether the audit can conclude at all. Beside each criterion, work out what evidence would answer the sub-question, how it would be obtained, and — the judgment that matters — what would count as sufficient and appropriate evidence here, and what that evidence would let the team conclude. Keeping this reasoning inside the matrix, beside the criterion it serves, keeps it alive; a detached plan tends to go cold.
At that point the matrix meets its readiness test — not a checklist but an exercise of judgment. If, on the team’s current knowledge, the questions and criteria hold together and the evidence looks obtainable, the design is sound enough to propose — first to the manager, then to the board in the audit proposal. Formal approval is the board’s to give, and it may come promptly or late; a matrix built this way does not wait on it — a design sound enough to submit is already sound enough to work from. “Current knowledge” should be grounded honestly in what interviews, documents, files and regulations have actually established, not in what the team expects to find. It will almost never be complete, and need not be.
Because it will not be complete — and because there is no second pilot study to fall back on — the refining happens during the audit itself, on the matrix. Treat it as a live document, not a fixed one: when evidence assumed to exist turns out not to, or a sub-question stops short of the cause it was meant to reach, change the matrix. That is the iterative process working as intended, not a defect in the design. The matrix earns its keep precisely by being revised as fieldwork proceeds — it is the instrument that makes the planning sound, not the record that planning once occurred.
4. The tool
The template that accompanies this explainer is a single page, built to hold the reasoning above rather than merely record that it happened. It comes in an editable form (.docx and .xlsx) for working use and a PDF reference copy for filing.
A short header block sits at the top: audit title, main question, and scope boundary — enough to fix what the audit is, and is not, about. Beneath it the matrix runs in two blocks. The first is the core the board proposal draws on directly: one row per sub-question, with columns for the sub-question, the criterion, and its source. The second is the evidence block, marked planning-essential but publication-optional: the evidence required, the method or source, what that evidence would let the team conclude, and a column for notes and revisions. Each column carries a one-phrase instruction beneath its heading, and a check line reminds the team that the sub-questions must together answer the main question.
Two lines encode the principles from the explainer onto the tool itself. One is a reporting reminder: if the evidence block is left out of the published report, the methodology, the data gathered and any limitations must still be described transparently in the text. The other is the instruction that matters most — revise as you learn — a standing note that a changed row is the process working, not a planning error.
A worked row comes filled in, drawn from a real audit of climate control in schools, with the sub-question, criterion and method already in place; blank rows follow for the team’s own design.
The template is available as a free download.