Internal audit documentation is the record that allows another competent reviewer to understand what the auditor planned, what work was performed, what evidence was obtained, what exceptions were identified and how the final conclusion was reached. Good documentation is not simply a collection of screenshots and spreadsheets. It is the audit trail that connects the objective of an assignment to the evidence and ultimately to the report.
Why internal audit documentation matters
ICAI's current internal-audit framework includes Compendium of Standards on Internal Audit (as on February 2026), applicable from 1 April 2026. The framework includes SIA 330 on Internal Audit Documentation, alongside standards dealing with assignment planning, evidence, review and supervision, communication and reporting. ICAI describes Standards on Internal Audit as codification of best practices intended to improve credibility, consistency, clarity and comparability of internal-audit work.
Documentation therefore serves several practical purposes. It demonstrates that the planned procedures were actually performed; supports findings and conclusions; makes supervisory review possible; helps teams follow up unresolved issues; and creates continuity when staff change between audit cycles.
What should an internal audit working paper show?
A useful working paper should answer a simple chain of questions: Why was this area tested? What procedure was performed? What evidence was examined? What did the auditor find? What conclusion follows? If a reviewer cannot reconstruct that chain without repeatedly asking the preparer for an explanation, the file is usually under-documented.
1. Objective and scope
State the specific audit objective and the process, period, location, system or population covered. Avoid vague labels such as “purchase checking.” A stronger objective would be to assess whether procurement controls prevent unauthorised purchases, duplicate vendors and unsupported payments during a defined period.
2. Risk and control being tested
Link the procedure to the underlying risk. For example, the risk may be that payments are released without valid goods receipt or approval. The expected control may be a system-enforced three-way match plus an authorised payment release. This link prevents working papers from becoming disconnected checklists.
3. Population and sample
Record where the population came from, the period covered, relevant filters, the population size where applicable, the sampling approach and the items selected. Retain enough information to identify the tested items later. A statement such as “sample checked and found okay” is weak because it does not show what was checked or how the sample was chosen.
4. Procedure actually performed
Describe the work precisely. If the procedure was to compare purchase orders, goods-receipt records and supplier invoices, say so. If system access logs were inspected, identify the relevant report or evidence. Documentation should describe actual work, not merely copy a standard audit-program instruction.
5. Evidence and result
ICAI's framework separately addresses internal audit evidence through SIA 320. The documentation should identify the evidence supporting the result and distinguish facts from explanations or assumptions. Relevant records may include contracts, invoices, reconciliations, ERP reports, approval logs, emails, minutes, external confirmations or system-generated evidence, depending on the assignment.
6. Exceptions and conclusion
For each material exception, document the condition found, the expected criterion or control, likely cause where established, risk or consequence, management response where obtained, and the auditor's conclusion. Avoid converting an unverified explanation into a fact. Where management provides an explanation, corroborate it when the issue requires evidence.
A practical working-paper structure
A repeatable internal-audit file can be organised around the following checklist:
- Header: entity, process, assignment, period, preparer, reviewer and relevant dates.
- Objective: the question the test is designed to answer.
- Risk: what can go wrong and why it matters.
- Control: the expected preventive or detective response.
- Population: source, period, filters and completeness considerations.
- Selection: sample or other testing basis.
- Procedure: exact steps performed.
- Evidence: identifiable supporting records or references.
- Exceptions: factual deviations, with supporting evidence.
- Conclusion: whether the control or process met the audit objective.
- Cross-reference: link to related findings, schedules and report paragraphs.
- Review trail: review notes, resolution and sign-off.
Worked example: vendor master review
Assume an internal auditor is reviewing vendor-master controls for a manufacturing company. The objective is to determine whether new vendors are created only after appropriate due diligence and approval.
The auditor obtains the ERP vendor-creation report for the audit period, reconciles relevant report parameters to the agreed scope, selects a documented sample and tests each selected vendor against the approved onboarding documents. For one vendor, the file contains bank details and tax information but no evidence of the required independent approval.
A defensible working paper would not simply say “approval missing.” It would identify the vendor and transaction reference, state the required control, reference the evidence inspected, record that approval evidence was unavailable, document management's response, assess whether the exception is isolated or indicates a wider control weakness, and conclude whether additional testing is required. If the issue is reported, the working paper should cross-reference the final observation.
Common documentation mistakes
- Conclusion without evidence: writing “control effective” without showing the tests supporting that conclusion.
- Evidence dump: storing hundreds of screenshots without explaining their relevance.
- No population trail: retaining a sample but not documenting the source population or filters.
- Unclear exceptions: mixing facts, management explanations and auditor assumptions in one paragraph.
- No cross-referencing: making the reviewer search multiple folders to connect testing with the reported finding.
- Silent scope changes: changing the period or procedure during fieldwork without documenting why.
- Unresolved review notes: treating review comments as administrative rather than part of quality control.
How much documentation is enough?
The goal is not maximum paperwork. The file should contain enough relevant documentation to make the work understandable and reviewable in light of the assignment's nature, risk and complexity. Higher-risk judgments and significant exceptions generally need a clearer trail than routine low-risk tests. Documentation should also avoid unnecessary personal or confidential data where it is not needed for the audit purpose, and organisations should apply their approved access, retention and information-security policies.
ICAI's Internal Audit Standards Board publications page lists the current series of SIAs, including SIA 310 on Planning the Internal Audit Assignment, SIA 320 on Internal Audit Evidence, SIA 330 on Internal Audit Documentation, SIA 350 on Review and Supervision of Audit Assignments and SIA 370 on Reporting Results. Reading documentation in that wider sequence is useful because a working paper is strongest when planning, evidence, review and reporting remain connected.
Practical takeaway
A strong internal-audit file lets a reviewer follow a clean path from objective to risk to procedure to evidence to exception to conclusion. Build working papers around that chain rather than around screenshots or checklist completion. If every significant finding can be traced to reliable evidence and every conclusion can be traced to documented work, the file becomes easier to review, defend, hand over and use for future follow-up.
