How to Document Internal Controls

Key Takeaways

ISA 315.26 requires you to document only controls relevant to the audit — those that address an assessed risk of material misstatement. Copying the client’s full control matrix without filtering for relevance is the most common inspection finding.
Every control description needs five elements: who performs it, what the action is, when it happens, what input it uses, and what evidence it produces (ISA 315.A173).
A walkthrough under ISA 315.A175 confirms the control is implemented. It is not a test of operating effectiveness — that is a separate decision under ISA 330.8.
The design effectiveness assessment per control per assertion is the gateway to deciding whether to rely on the control. A missing assessment is a gap that inspectors flag consistently.

A review partner opens your file and turns to the controls section. There’s a list of controls copied from last year. No walkthrough evidence. No link between each control and the risk it addresses. No assessment of whether the control is designed to prevent or detect the misstatement you identified in your risk assessment. The partner sends it back. You’ve spent four hours on controls documentation and none of it produced audit evidence.

To document internal controls under ISA 315 (Revised 2019), identify the controls relevant to the audit by linking each one to an assessed risk of material misstatement, describe the control with enough precision that another auditor could evaluate its design, perform and document a walkthrough to confirm the control operates as described, and record your assessment of whether the control’s design is effective at addressing the relevant assertion.

Which controls you actually need to document

ISA 315.26 requires you to identify controls relevant to the audit. Not every control the client has. Not every control in their internal control manual. Only the controls that are relevant to your risk assessment at the assertion level.

A control is relevant to the audit when it addresses a risk of material misstatement that you’ve identified during your risk assessment procedures. ISA 315.A170 clarifies that this identification requires the auditor’s judgment about which controls, individually or in combination, are relevant to the audit. The key phrase is “relevant to the audit,” not “relevant to the client’s operations.”

In practice, this means you start from your risk assessment, not from the client’s process documentation. For each significant class of transactions, account balance, and disclosure, you’ve identified the assertions at risk. The controls you document are the ones that address those assertions. If the client has 85 controls in their purchase-to-pay cycle but only four of them address the assertions where you’ve identified a risk of material misstatement, you document four controls.

Start from risks, not from client documentation

This filtering step is where most files go wrong. Teams receive the client’s control matrices or process narratives and copy them into the audit file with minimal filtering. The result is a controls section that documents everything the client does but doesn’t demonstrate which controls the auditor considered relevant, or why. ISA 230.8 requires documentation sufficient to enable an experienced auditor to understand the significant judgments made. Copying a client’s control list without linking it to your risk assessment doesn’t satisfy that standard.

How to describe a control so a reviewer can assess design

ISA 315.A173 provides guidance on the depth of understanding required. For each relevant control, the documentation needs to answer five questions. Who performs the control. What specifically happens (the action). When it happens (the frequency and timing). What information or data the control uses as input. What evidence the control produces that you can inspect.

A vague description fails the design assessment before it starts. “Management reviews revenue monthly” tells a reviewer nothing about whether the control is designed to catch a misstatement. Compare that with: “The finance manager reviews the revenue reconciliation between the billing system and the general ledger on the fifth working day of each month, investigates any line item exceeding €5,000, and signs the reconciliation as evidence of review.”

The second description lets a reviewer assess whether the control is designed to detect misstatements at the assertion level. The first one doesn’t. The difference is specificity: who does it, what input they use, what threshold triggers investigation, and what evidence they produce.

Write every control description in active voice with a named role (not “management” unless the client genuinely has only one decision-maker). Use the client’s actual thresholds and frequencies. If you don’t know them, the walkthrough will surface them, but you need to update the description afterwards with the actual details rather than leaving the generic version in the file.

Performing and documenting walkthroughs

ISA 315.A175 describes walkthroughs as a procedure where you trace a transaction from origination through to its reflection in the financial statements. The walkthrough confirms that your understanding of the control is accurate and that the control is implemented (meaning it exists and the client is using it).

A walkthrough is not a test of operating effectiveness. It’s a confirmation that the control works as described. ISA 330.8 governs tests of operating effectiveness, which is a separate decision you make later.

For each relevant control, select one transaction and trace it through the entire process. Document what you observed at each point where a control is applied. Record the specific document or record you inspected (invoice number, date, amount, approval signature). Note any deviation from the described control. If the control description says the finance manager signs the reconciliation but the walkthrough shows the assistant accountant signed it for three of the last six months, that’s a finding that affects your risk assessment.

Pick a meaningful walkthrough transaction

The selection of the walkthrough transaction matters more than most teams realise. ISA 315.A175 doesn’t prescribe how to select it, but the transaction should be typical of the population the control addresses. Selecting a low-value, straightforward transaction when the control’s purpose is to catch misstatements in large, complex transactions produces a walkthrough that doesn’t confirm the control’s relevance. Pick a transaction that actually tests whether the control operates at the level of complexity and value where misstatements would matter.

The documentation should be granular enough that a reviewer can follow your walkthrough without asking you to explain it. Record the transaction you selected (with identifying details), the date of your walkthrough, and what you saw at each control point. A walkthrough note that says “confirmed control operating” without specifying what you inspected or which transaction you traced doesn’t satisfy ISA 315.A175.

Keep your walkthrough documentation linked to the specific control it confirms. If you document controls in a matrix or schedule, the walkthrough reference should appear in the same row as the control description, not in a separate section of the file that a reviewer has to cross-reference manually.

When you find a deviation during the walkthrough, don’t ignore it. A deviation means the control as described doesn’t match reality. You have two options: update your control description to reflect what actually happens (if what actually happens is still a control), or conclude that the control is not implemented and adjust your risk assessment accordingly. Either way, document what you found and what you did about it.

Documenting IT general controls

ISA 315.26(d) requires you to identify IT general controls (ITGCs) that address risks arising from the client’s use of IT. For most non-Big 4 engagements, this means controls over access management, change management, and IT operations for the systems that produce financial reporting data.

The documentation requirements for ITGCs follow the same five-element structure as any other control: who, what, when, input, evidence. The difference is that the “who” is often an IT administrator or system administrator rather than a finance team member, and the “evidence” is a system log, access report, or change ticket rather than a signed document.

Start by identifying which IT systems are relevant. If the client uses a single ERP system for all financial reporting (Exact, SAP, or similar), that system’s ITGCs are relevant. If the client uses separate systems for billing, purchasing, and general ledger, each system’s ITGCs need consideration. ISA 315.A128 notes that the auditor’s understanding of IT general controls focuses on the systems and applications relevant to financial reporting, not every system the client operates.

For access controls, document who has access to what level of the relevant systems, how access is granted and revoked, and how the client reviews access periodically. The documentation should record the specific access review process (quarterly review of user access list by IT manager, sign-off on the review, revocation of terminated users within five business days of termination date).

For change management, document how changes to the financial reporting systems are authorised, tested, and implemented. A common gap in non-Big 4 files is documenting that “changes are approved by management” without specifying what approval looks like, whether testing occurs in a separate environment, and whether the change log is reviewed.

For IT operations, the relevant controls typically cover backup procedures, job scheduling, and incident management for the financial reporting systems. Focus on the controls that would affect the integrity, availability, and processing accuracy of financial data.

The depth of ITGC documentation depends on the extent to which you intend to rely on automated controls in your audit strategy. If you’re planning to rely on automated three-way matching in the purchase cycle as a control that reduces your substantive testing, the ITGCs supporting that automated control need thorough documentation and testing. If you’re not relying on any automated controls and your entire substantive approach is manual detail testing, the ITGC documentation can be lighter because it’s informing your risk assessment rather than supporting a reliance strategy.

Assessing design effectiveness

Once you’ve described the control and confirmed through a walkthrough that it’s implemented, ISA 315.26(a) requires you to evaluate whether the control is suitably designed to prevent or detect material misstatements at the assertion level.

Design effectiveness is about whether the control, if operating as described, would catch the misstatement you’re worried about. A monthly revenue reconciliation between the billing system and the GL is well-designed to detect completeness and accuracy misstatements in revenue, because it would surface differences between what was billed and what was recorded. It is not well-designed to detect an occurrence misstatement (fictitious revenue) because both the billing system and the GL would contain the fictitious entry.

The assessment depends on understanding the misstatement pathway. For each assertion at risk, ask: what would a misstatement look like in this balance? Then ask: would this control catch it before the misstatement reaches the financial statements (preventive), or would it identify it after the fact (detective)? Preventive controls are stronger evidence because they stop the misstatement from occurring. Detective controls find it after it’s happened, which means there’s a window where the misstatement exists undetected.

Your documentation needs to state which assertion the control addresses and whether the design is effective for that assertion. A common gap in files is that the control description exists, the walkthrough exists, but there’s no recorded conclusion on design effectiveness. The reviewer sees what the control is and that it’s implemented, but not whether the engagement team assessed it as effective, partially effective, or ineffective for the relevant assertion.

Assess per control per assertion

Record the assessment per control per assertion. If one control addresses multiple assertions, assess it against each one. If the design is not effective (or only partially effective) for a particular assertion, state what compensating controls exist or what additional substantive procedures you’ve planned in response. ISA 330.7 requires you to design further audit procedures that respond to the assessed risks, and your controls assessment feeds directly into that design.

A well-documented design assessment also helps you decide whether to test operating effectiveness under ISA 330.8. If the control is well-designed and you intend to rely on it to reduce the extent of substantive testing, you’ll need to test that it operated effectively throughout the period. If the control design is weak or only partially effective, testing operating effectiveness isn’t worthwhile because even a perfectly operating control won’t give you the evidence you need. The design assessment is the gateway to that decision, and it should be documented clearly enough that the reviewer can follow your logic from design assessment to the planned audit response.

Worked example: Dijkstra Logistics B.V.

Client profile: Dijkstra Logistics B.V. is a Dutch freight forwarding company. Revenue €42M. 2,800 shipments per month across road and sea freight. Performance materiality €315,000. Significant risk identified: occurrence of revenue (risk that revenue is recorded for shipments not yet completed under IFRS 15.35(c) criteria).

Step 1: Identify the relevant control

From the client’s process documentation and inquiry with the operations director, the engagement team identifies the following control relevant to the occurrence assertion for revenue: the billing coordinator matches each sales invoice to a signed proof-of-delivery (POD) document before the invoice is released for posting. Invoices without a matched POD are held in a suspense queue and reviewed weekly by the finance manager.

Documentation note: Record the control with the five elements (who, what, when, input, evidence). Link it to the identified risk (occurrence of revenue) and the relevant assertion. Reference ISA 315.26.

Step 2: Describe the control

The billing coordinator (named role: J. Vermeer) matches each outgoing sales invoice to the corresponding signed POD within two business days of shipment completion. The matching uses the shipment reference number as the linking field between the transport management system and the billing module. Unmatched invoices are flagged automatically and reviewed by the finance manager (K. de Groot) every Friday. Evidence: the matched status field in the billing system, and the finance manager’s sign-off on the weekly unmatched items report.

Documentation note: Record this description in the controls matrix. Include the role names, frequency, system used, matching field, and the evidence produced. Reference ISA 315.A173.

Step 3: Perform the walkthrough

The engagement team selects shipment reference DL-2024-18742 (road freight, Rotterdam to Munich, completed 14 November, invoice amount €4,280). The team traces the shipment from the transport management system entry, through the signed POD (signed by the receiving warehouse on 14 November), to the matched invoice (posted 15 November), and confirms the matched status in the billing system. The POD signature, the matching timestamp, and the invoice posting date are all consistent with the described control.

Documentation note: Record the selected transaction (shipment ref, date, amount), the documents inspected (POD, invoice, system screenshot of matched status), what was observed at each control point, and the conclusion on implementation. Reference ISA 315.A175.

Step 4: Assess design effectiveness

The POD-matching control is designed to prevent revenue from being recorded for incomplete shipments (occurrence assertion) because the invoice cannot be posted until a signed POD confirms physical delivery. The control is assessed as effectively designed for the occurrence assertion. It does not address the completeness assertion (shipments completed but not invoiced), because the control only triggers when an invoice is generated, not when a shipment is completed without invoicing.

Documentation note: Record the design assessment per assertion. State which assertions the control is effective for and which it is not. For the completeness gap, document the compensating control or additional substantive procedure planned. Reference ISA 315.26(a) and ISA 330.7.

The file now shows a clear chain: identified risk, relevant control, description with five elements, walkthrough on a specific transaction, and design assessment per assertion with a documented gap and response.

Your controls documentation checklist

Start from your risk assessment, not the client’s control list. For each assertion where you’ve identified a risk of material misstatement, identify which controls (if any) address that risk (ISA 315.26).
Describe each relevant control with the five elements: who performs it, what the action is, when and how often, what data it uses, and what evidence it produces (ISA 315.A173).
Perform a walkthrough on one transaction per relevant control. Record the transaction details, the documents inspected, and what you observed at each control point (ISA 315.A175).
Record your design effectiveness assessment per control per assertion. State whether the control is effectively designed to prevent or detect misstatement for each assertion it addresses (ISA 315.26(a)).
Link the controls assessment to your ISA 330 response. Where a control is not effectively designed, document the compensating control or additional substantive procedure in your audit plan.

Common mistakes reviewers flag

Copying the client’s full control matrix into the audit file without filtering for relevance to the audit. The AFM’s inspection guidance consistently flags files where the auditor documented every control the client has but didn’t identify which ones are relevant to the assessed risks under ISA 315.26.
Documenting “management review” as a control without specifying who, what threshold, what input, and what evidence of review. ISA 315.A173 requires a level of understanding that allows the auditor to assess design effectiveness. A vague description prevents that assessment.

Frequently asked questions

Which internal controls must be documented in an audit file under ISA 315?

ISA 315.26 requires you to identify and document controls relevant to the audit. A control is relevant when it addresses a risk of material misstatement identified during the risk assessment. You do not need to document every control the client has — only the controls that address the assertions where you have identified a risk. Start from your risk assessment, not from the client’s control manual.

What five elements should a control description include?

ISA 315.A173 requires the documentation to answer five questions: who performs the control (a named role, not just “management”), what specifically happens (the action), when it happens (frequency and timing), what information or data the control uses as input, and what evidence the control produces that can be inspected. A vague description like “management reviews revenue monthly” prevents a design effectiveness assessment.

What is the difference between a walkthrough and a test of operating effectiveness?

A walkthrough under ISA 315.A175 confirms that a control is implemented — that it exists and the client is using it as described. It involves tracing one transaction through the entire process. A test of operating effectiveness under ISA 330.8 evaluates whether the control operated consistently throughout the period and involves testing multiple instances. The walkthrough sits in the risk assessment phase; operating effectiveness testing is a separate decision made later when you intend to rely on the control to reduce substantive testing.

How do you assess design effectiveness of an internal control?

Design effectiveness asks whether the control, if operating as described, would catch the misstatement you are concerned about. Assess it per control per assertion. For each assertion at risk, determine what a misstatement would look like and whether this control would prevent it (preventive) or detect it after the fact (detective). Record your conclusion and, if the design is not effective for a particular assertion, document compensating controls or additional substantive procedures planned in response.

Do you need to document IT general controls under ISA 315?

Yes. ISA 315.26(d) requires identification of IT general controls that address risks arising from the client’s use of IT. For most non-Big 4 engagements, this means controls over access management, change management, and IT operations for the systems that produce financial reporting data. The depth of documentation depends on whether you intend to rely on automated controls — if you are relying on automated controls, the ITGCs supporting them need thorough documentation and testing.