A walkthrough follows one transaction from start to finish to confirm you understand the process and that the control is designed to work. Testing then checks whether the control actually operated, consistently, over the period. Design effectiveness asks "would this control stop or catch an error if it ran as described?" Operating effectiveness asks "did it run as described, by a competent person, every time it should have?"
Last reviewed: 17 October 2026. Facts checked. This guide follows the published structure of PCAOB AS 2201 and standard control testing practice as described in secondary summaries. PCAOB standards are primary documents that were not opened for this guide, so check the current text. Sample sizes and testing intervals are deliberately omitted: they depend on the control's frequency, risk and the methodology in use. For the Indian sampling standard, see SA 530 and sampling.
Walkthrough first
A walkthrough is not a test of the whole year. It is one transaction, traced through the process, with the people who do the work.
How to run one
- Pick a transaction that passes through the key steps, such as a customer order that ended in cash received.
- Start where the transaction starts. Ask the person who handled it to show you, not just tell you.
- Follow it through every step, including system steps, approvals and the posting to the ledger.
- Ask probing questions. What happens if the amount is wrong? What if the approver is on leave? What do you do with exceptions?
- Collect evidence for the transaction: documents, screenshots, system logs.
- Compare what you learned with the written process and the control description.
We cover question lists in 15 essential walkthrough questions.
What a walkthrough tells you
- Whether the process documentation is accurate.
- Where errors could enter the process.
- Whether the key controls exist and are placed in the right spots.
- Whether the control is designed to address the risk.
If the walkthrough shows that the design is wrong, such as a review that checks only totals, do not go on to test operating effectiveness. A badly designed control cannot be effective however consistently it runs. Record the design deficiency and move on to evaluating it.
Design effectiveness
A control is designed effectively when, if performed as written by a competent person with the necessary authority, it would prevent or detect a material misstatement. Check:
- Precision. Does it look at the right level of detail? A review of "variance over a threshold" depends on that threshold being sensible.
- Timing. Does it run early enough to matter?
- Owner. Is it done by someone with the knowledge and independence to challenge?
- Information used. Are the reports it relies on complete and accurate? See ITGC testing.
Operating effectiveness
A control operates effectively when it was performed as designed, by the right person, at the right time, throughout the period. Testing uses four basic techniques, often combined:
| Technique | What you do | Example |
|---|---|---|
| Inquiry | Ask people | Ask the controller how bank reconciliations are reviewed. Never enough on its own. |
| Observation | Watch it being done | Watch the user access review being performed. Only shows one moment. |
| Inspection | Examine documents or records | Inspect signed reconciliations or system approval logs |
| Reperformance | Do the control again yourself | Recalculate a variance, repeat a three-way match |
Inquiry alone is not enough evidence. Combine it with inspection or reperformance.
Choosing what to test
The more risk a control addresses, and the more judgement it involves, the stronger the evidence needed. Manual controls usually need more evidence than automated ones. Automated controls can be tested more lightly, but only if the supporting ITGCs are effective.
Population and samples
Tests use a sample drawn from the full population for the period. Two points matter:
- The population must be complete. Use a system-generated list, not one given by the control owner.
- The sample must be chosen without bias and be large enough for the control's frequency and risk. Use your firm's or company's sampling approach; do not copy a table from another methodology without checking it fits. The sampling plan generator can help structure a plan.
Interim and roll-forward
Companies often test at an interim date and then extend the conclusion to year-end. The roll-forward asks: has anything changed since the test, and did the control keep operating? The length of the gap and the control's risk decide how much roll-forward work is needed.
What you record
For each control, the file should show:
- the control as described, and its owner;
- the walkthrough evidence;
- the test steps, population, sample and results;
- exceptions found and what caused them;
- the conclusion on design and operation.
When you find an exception
- Find out why. Was it a one-off or a pattern?
- Extend testing if needed.
- Look for compensating controls.
- Log it and evaluate it. See how to classify deficiencies.
Frequently Asked Questions
Is a walkthrough a test of operating effectiveness?
Not by itself. It is mainly about understanding the process and design, though it can also give some evidence about operation for that one transaction.
Can inquiry alone support a conclusion?
No. Inquiry should be combined with observation, inspection or reperformance.
What if the control is automated?
Test the automated control with a small number of checks, but only if ITGCs over the system are effective. Otherwise the test result cannot be relied on.
Who should do the testing?
Someone objective and competent. Internal audit often does it. Auditors may use that work, depending on its quality and the risk.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error