How to Document Internal Controls

Q: 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.

Q: 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.

Q: 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 mid-tier 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.

Most control documentation files describe what the control does and stop there. The file never explains what data feeds the control, who reviews exceptions, or what happens when the control fails. An experienced auditor with no prior connection to the engagement should be able to read the file and understand what was done and why. The file should tell a story.

A review partner opens your file and turns to the controls section. There is a list of controls copied from last year. No walkthrough evidence. No link between each control and the risk it addresses. No assessment of design effectiveness, and no connection to the planned audit response. The partner sends it back. You have spent four hours on controls documentation and none of it produced audit evidence.

To document internal controls under ISA 315 (Revised 2019), link each control to an assessed risk, describe it precisely enough for design evaluation, perform a walkthrough to confirm it operates as described, and record your design effectiveness assessment per assertion.

Key takeaways

How to identify which controls are relevant to the audit under ISA 315.26 , so you document what matters instead of copying the client’s full control environment
How to describe a control so the documentation satisfies ISA 315 .A170 and a reviewer can evaluate design effectiveness from the working paper alone
How to perform and document a walkthrough that produces audit evidence under ISA 315 .A175
What the AFM and FRC consistently flag in controls documentation, and the specific fixes

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.

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.

The ciferi internal controls documentation glossary entry covers the ISA 315 terminology distinctions between entity-level controls, transaction-level controls, and IT general controls.

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. The walkthrough sits in the risk assessment phase under ISA 315 . The ciferi glossary entry on tests of controls covers the distinction between walkthroughs and operating effectiveness testing in more detail.

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.

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 mid-tier engagements, this means controls over access management and change management for the systems that produce financial reporting data, plus the IT operations controls around batch processing and backup.

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 runs separate systems for billing, purchasing, inventory, 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 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 in a separate environment, approved, and migrated to production. A common gap in mid-tier 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, batch processing monitoring, and incident management for the financial reporting systems. You don’t need to document the full IT operations framework. Focus on the controls that would affect the integrity and processing accuracy of financial data. If the client’s nightly batch job that posts journal entries fails and nobody notices for a week, that’s a financial reporting risk. The control that monitors batch job completion and alerts the IT team to failures is the relevant one to document.

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.

The ciferi ISA 315 risk assessment glossary entry covers how ITGC weaknesses feed into your overall risk assessment and what that means for your planned substantive response.

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 is no recorded conclusion on design effectiveness. The reviewer sees what the control is and that it is implemented, but not whether the engagement team assessed it as effective or ineffective for the relevant assertion. Reviewers open the file, look for the IPE column, and if it is blank, the review notes write themselves.

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.

The link between controls and your ISA 330 risk response is where inspectors spend most of their review time. A design assessment with no visible connection to the subsequent audit plan is a reliable way to generate an inspection finding.

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. PM €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, the invoice posting date, and the system-recorded matched status 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 .

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, what you observed at each control point, and any deviations from the described process ( 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

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.

Internal controls (glossary) covers entity-level versus transaction-level controls, IT general controls, and the ISA 315 framework for understanding the control environment.
ISA 570 Going Concern Calculator helps structure the quantitative side of the going concern assessment if you’re documenting controls over that process.
How to design risk responses under ISA 330 is the direct next step after controls documentation, where your design assessments translate into the audit plan.

Related guides:

Put audit concepts into practice with these free tools:

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 document 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 mid-tier 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.