How to Build an Audit Program From Scratch

Key Takeaways

ISA 330.6 requires audit procedures that are responsive to assessed risks at the assertion level. A generic program that applies the same procedures to every client fails this test by design.
The audit program is an output of the risk assessment, not an input to it. Complete the ISA 315 risk assessment before writing a single procedure line.
Structure the program by assertion, not by account. Revenue has multiple assertions (occurrence, completeness, accuracy, cut-off), each with potentially different risk levels and different required responses.
ISA 330.28(b) requires bi-directional cross-referencing between the risk assessment and the audit program. Every risk needs a response, and every response needs a risk.

You’ve inherited a new client. The prior auditor left no working papers, no templates, and no transition file. The partner hands you a set of signed financial statements from last year and says “build the program.” Most first-year seniors in this situation do one of two things: copy a program from another client and change the names, or pull a generic template from the firm’s methodology library and hope it fits. Both approaches produce the same result — a program that looks complete but doesn’t respond to the client’s actual risks, which is exactly what ISA 330.6 is designed to prevent.

To build an audit program from scratch under ISA 300 and ISA 330, start with your risk assessment at the assertion level, design a specific audit procedure for each assessed risk that directly addresses the relevant assertion, determine the nature, timing, and extent of each procedure based on the risk level, and document the rationale linking each procedure to the risk it responds to.

Why generic audit programs fail ISA 330

ISA 330.6 requires audit procedures that are “responsive to the assessed risks of material misstatement at the assertion level.” The operative word is “responsive.” A generic program that applies the same procedures to every client, regardless of their risk profile, fails this test by design.

The problem isn’t that generic templates contain bad procedures. Most firm templates include reasonable steps: confirm bank balances, vouch a sample of revenue transactions, inspect fixed asset additions. The problem is that those procedures exist in the program because they’re standard, not because they respond to a specific risk identified during the ISA 315 risk assessment. ISA 330.A4 makes this explicit: the auditor’s assessment of the identified risks at the assertion level provides the basis for designing and performing further audit procedures.

A reviewer looking at your program will trace backwards. They’ll pick a procedure from your audit program and look for the corresponding risk in your ISA 315 risk assessment. Then they’ll pick a risk from your assessment and look for the procedure that addresses it. If either direction fails (a procedure with no corresponding risk, or a risk with no corresponding procedure), the program is deficient. The AFM’s inspection guidance flags this linkage gap as one of the most common findings in non-Big 4 files.

Quality over quantity

The linkage test is binary: it either works or it doesn’t. A program with 40 well-designed procedures and one risk left unaddressed has a deficiency. A program with 15 focused procedures that each map to a specific risk has none. The quality of an audit program isn’t measured by its length. It’s measured by whether every risk has a response and every response has a risk.

Start from the risk assessment, not from the prior year file

The audit program is an output of the risk assessment, not an input to it. ISA 300.7 requires the auditor to develop an audit plan that includes a description of the nature, timing, and extent of planned further audit procedures at the assertion level as determined under ISA 330. This means the risk assessment must be complete before you write a single line of the audit program.

Pull up your ISA 315 risk assessment. For each significant class of transactions, account balance, and disclosure, you’ve identified assertions at risk and assessed the level of risk (higher or not higher than default). That assessment is your starting point.

For every assertion where you’ve assessed a risk of material misstatement, you need at least one audit procedure in the program that directly addresses it. ISA 330.7 requires the design of further audit procedures whose nature, timing, and extent are responsive to the assessed risks. If you assessed the occurrence of revenue as a significant risk, the audit program must contain a procedure specifically designed to test whether recorded revenue transactions actually occurred. “Vouch a sample of revenue to supporting documentation” might work, but only if the sample size, selection method, and documentation examined are calibrated to the significance of the risk.

Where you’ve assessed a risk as a significant risk under ISA 315.28, ISA 330.15 requires substantive procedures that are specifically responsive to that risk. You can’t address a significant risk with analytical procedures alone. Tests of detail are required for significant risks, and the program should state this explicitly so the team executing it understands the requirement.

Structure by assertion, not by account

Build the program assertion by assertion, not account by account. Revenue has multiple assertions (occurrence, completeness, accuracy, cut-off). Each assertion may have a different risk level. A program structured by account (“Revenue procedures: 1, 2, 3, 4”) obscures which procedure addresses which assertion. A program structured by assertion (“Occurrence of revenue: procedure and rationale; Completeness of revenue: procedure and rationale”) makes the linkage visible and reviewable.

Choosing between tests of controls, analytics, and tests of detail

ISA 330.7 gives you four categories of further audit procedures: tests of controls, substantive analytical procedures, tests of detail, and combinations of these. Your choice depends on the assessed risk level, whether you intend to rely on internal controls, and the nature of the assertion.

Tests of controls under ISA 330.8 are appropriate when you’ve identified a control that addresses the relevant assertion, you’ve assessed its design as effective (under ISA 315.26(a)), and you intend to rely on that control to reduce the extent of your substantive testing. If you documented the client’s controls under ISA 315 and assessed them as well-designed and implemented, testing their operating effectiveness gives you a basis for reducing the amount of detail testing. If you didn’t document controls, or the controls you documented aren’t well-designed, tests of controls aren’t appropriate and the program should rely entirely on substantive procedures.

Substantive analytical procedures under ISA 520 work best for assertions where the balance is driven by predictable, measurable factors and you can develop an independent expectation with sufficient precision. Revenue for a subscription business, payroll for a stable workforce, depreciation on a fixed asset register with consistent policies. The Ciferi analytical review tool helps structure the expectation, threshold, and variance investigation for each balance. But analytical procedures alone can’t address significant risks (ISA 330.18), and they’re weaker evidence than tests of detail for assertions involving complex estimates or unusual transactions.

Tests of detail are the default for significant risks, assertions where controls are weak, and balances where analytical procedures can’t achieve sufficient precision. The nature of the detail test (inspection, observation, inquiry, confirmation, recalculation, reperformance) should match the assertion. Occurrence is best tested by selecting recorded items and tracing to supporting evidence. Completeness is best tested by selecting from an independent population (delivery notes, purchase orders, bank statements) and tracing to the accounting records. Using the wrong direction of testing for the assertion is a common error that inspectors catch.

For most non-Big 4 engagements, the program will consist primarily of substantive procedures (a mix of analytical procedures and tests of detail) because most mid-tier clients don’t have controls that are reliable enough to reduce substantive testing materially. That’s not a deficiency in your program. It’s a realistic reflection of the client’s control environment.

Setting the nature, timing, and extent of each procedure

Once you’ve selected the type of procedure, ISA 330.7(a) and (b) require you to determine the nature, timing, and extent.

Nature means the specific procedure you’ll perform. “Test revenue” isn’t a nature description. “Select a sample of recorded revenue transactions from the sales journal, obtain the corresponding signed delivery note and customer purchase order, and agree the quantity, price, and date to the journal entry” is. The program should describe the procedure with enough specificity that the team member executing it doesn’t need to make design decisions in the field.

Timing means when you’ll perform the procedure relative to the period end. ISA 330.11 permits testing at an interim date, but if you do, you need a plan for covering the remaining period. For higher-risk assertions, testing closer to (or after) the period end gives you stronger evidence. The program should state the planned timing for each procedure and the rationale for any interim testing.

Extent means the quantity: sample size, number of items inspected, scope of the analytical procedure. ISA 330.A19 links extent directly to the assessed risk: higher risk requires a larger sample or more extensive procedure. If you’re using statistical sampling, the sample size is driven by the expected and tolerable error rates and the Ciferi sampling calculator can compute the required size. If you’re using non-statistical sampling, you need a documented basis for the sample size that connects to the risk level and performance materiality.

Document all three in the audit program itself, not just in the planning memo. The program is the execution document. A team member picking it up should be able to see what to do, when to do it, how much to do, and why.

How to document the link between risk and response

ISA 330.28 requires the audit documentation to include the overall responses to the assessed risks of material misstatement and the nature, timing, and extent of the further audit procedures. ISA 330.28(b) specifically requires the documentation to show the linkage of those procedures with the assessed risks at the assertion level.

The simplest way to achieve this is a cross-reference column in the audit program. Each procedure has a reference to the specific risk in your ISA 315 risk assessment that it addresses. The risk assessment identifies the assertion at risk and the risk level. The audit program procedure shows the response. The format doesn’t matter (a column, a hyperlink, a working paper reference number). What matters is that the connection is explicit and doesn’t rely on a reader inferring it from context.

Some firms use a separate “risk response” working paper that maps risks to procedures in a matrix. Others embed the risk reference directly in the audit program. Either approach works as long as the linkage is explicit, traceable, and bi-directional. A reviewer should be able to start from any risk and find the procedure, or start from any procedure and find the risk, without relying on professional judgment or institutional memory to make the connection.

Where you’ve assessed a significant risk, the documentation of the responsive procedure should be more detailed. ISA 330.15 requires substantive procedures specifically responsive to the significant risk. “Specifically responsive” means the procedure was designed with that particular risk in mind, not that a general-purpose procedure happens to cover it. Document what makes the procedure responsive: the larger sample size, the specific population it draws from, the particular attributes examined, or the timing chosen because of the risk.

Add a rationale column

Add a “rationale” column to your audit program alongside the procedure description and the risk reference. In that column, write one sentence explaining why this procedure responds to this risk. “Sample of 25 selected because revenue accuracy is a significant risk; ISA 330.A19 requires greater extent for higher assessed risk” takes ten seconds to write and saves an hour of reviewer questioning. The rationale column converts your audit program from a list of tasks into evidence of professional judgment, which is what ISA 330.28 actually requires.

Worked example: Mulder Bouw B.V.

Client profile: Mulder Bouw B.V. is a Dutch construction company. Revenue €36M across 14 active construction projects. Percentage-of-completion method applied under IFRS 15.35(c). Performance materiality €270,000. Significant risk: accuracy of revenue (risk that the stage of completion is misstated because project cost estimates are inaccurate or manipulated).

Step 1: Extract assertions at risk from the ISA 315 risk assessment

The risk assessment identifies four assertions at risk for revenue: occurrence (not significant risk, normal risk), completeness (not significant risk, normal risk), accuracy (significant risk, as described above), and cut-off (higher risk, due to projects spanning the reporting date).

Documentation note: List each assertion, the risk level, and the ISA 315 working paper reference. This is the input to the audit program. Reference ISA 330.6.

Step 2: Design procedures for each assertion

For occurrence (normal risk): select 20 revenue entries from the sales journal and trace to signed project contracts and progress certificates. Substantive test of detail, performed at year-end.

For completeness (normal risk): obtain a listing of all active contracts from the project management system, compare to revenue entries in the general ledger, and investigate any contract with no corresponding revenue entry. Substantive test of detail, performed at year-end.

For accuracy (significant risk): for all 14 active projects, obtain the project cost budget, the actual costs incurred to date, and the projected total cost. Independently recalculate the percentage of completion for each project. Compare to the client’s recorded percentage. For any project where the recalculated percentage differs from the client’s by more than 2 percentage points, inspect the underlying cost assumptions and challenge management’s projected costs to complete. This addresses ISA 330.15 (specific response to significant risk) and ISA 330.18 (substantive procedures for significant risk include tests of detail).

For cut-off (higher risk): select the last 15 project progress certificates issued before the reporting date and the first 15 issued after it. Agree the period of work to the revenue recognised in the correct period. Sample size increased from 10 to 15 because the risk is assessed as higher.

Documentation note: For each procedure, record the assertion addressed, the procedure type, the nature, timing, extent, and the ISA 315 risk reference. For the significant risk, record why the procedure is “specifically responsive” per ISA 330.15. Reference ISA 330.7 and ISA 330.28(b).

Step 3: Cross-reference risk to response

The audit program includes a column “Risk ref” that links each procedure row to the ISA 315 risk assessment working paper number (e.g., RA-REV-03 for revenue accuracy). The risk assessment working paper includes a column “Response ref” that links back to the audit program (e.g., AP-REV-03).

Documentation note: Verify that every risk has a response and every response has a risk. Record the cross-reference in both directions. Reference ISA 330.28(b).

A reviewer opening this file sees 14 projects tested individually for the significant risk, bi-directional cross-referencing between risk assessment and program, and a documented rationale for the procedure design that explains why 14 projects rather than a sample. The program is 16 procedure lines, not 40. But every line responds to a specific assessed risk, which is what ISA 330.6 requires.

Your audit program checklist

Complete the ISA 315 risk assessment before writing the audit program. Every procedure in the program must trace to a specific assessed risk at the assertion level (ISA 330.6).
Structure the program by assertion, not just by account. Each procedure should state which assertion it addresses and why the procedure’s design responds to the risk level for that assertion.
For significant risks, include tests of detail that are specifically responsive to the risk. Analytical procedures alone do not satisfy ISA 330.18 for significant risks.
State the nature, timing, and extent for each procedure in the program itself. Include the sample size, the population, the specific documents to inspect, and the planned timing relative to the period end (ISA 330.7).
Cross-reference every procedure to the corresponding risk in the ISA 315 risk assessment, and cross-reference every risk to the corresponding procedure. Both directions must be traceable (ISA 330.28(b)).

Common mistakes reviewers flag

Copying the prior year’s audit program without updating it for the current year’s risk assessment. The FRC’s inspection reports consistently flag “roll-forward” audit programs where procedures haven’t changed despite changes in the client’s risk profile under ISA 315.
Designing a procedure for revenue “generally” instead of for a specific assertion. “Vouch a sample of revenue transactions” doesn’t specify whether it addresses occurrence, accuracy, or cut-off. ISA 330.7 requires procedures responsive to the assessed risk at the assertion level, not at the account level.
Using the same sample size for all assertions regardless of risk level. ISA 330.A19 links extent to the assessed risk. A significant risk demands a larger sample or more extensive procedure than a normal risk on the same account.

Frequently asked questions

Why do generic audit programs fail under ISA 330?

ISA 330.6 requires audit procedures that are responsive to the assessed risks of material misstatement at the assertion level. A generic program applies the same procedures to every client regardless of their risk profile, which means procedures exist because they are standard, not because they respond to a specific identified risk. A reviewer will trace backwards from the program to the risk assessment — if a procedure has no corresponding risk, or a risk has no corresponding procedure, the program is deficient.

Should the audit program be structured by account or by assertion?

By assertion. Revenue has multiple assertions (occurrence, completeness, accuracy, cut-off), and each may have a different risk level. A program structured by account obscures which procedure addresses which assertion. A program structured by assertion makes the linkage between risk and response visible and reviewable, which is what ISA 330.28(b) requires.

Can analytical procedures alone address a significant risk?

No. ISA 330.18 requires substantive procedures for significant risks to include tests of detail. Analytical procedures alone do not satisfy the requirement for significant risks. The audit program should state this explicitly so the team executing it understands that detail testing is mandatory for any assertion assessed as a significant risk.

How do you document the link between risk and response in the audit program?

ISA 330.28(b) requires the documentation to show the linkage of procedures with the assessed risks at the assertion level. The simplest approach is a cross-reference column in the audit program where each procedure references the specific risk in your ISA 315 risk assessment. The linkage must be bi-directional: a reviewer should be able to start from any risk and find the procedure, or start from any procedure and find the risk.

How does the assessed risk level affect sample size in the audit program?

ISA 330.A19 links extent directly to the assessed risk: higher risk requires a larger sample or more extensive procedure. A significant risk demands a larger sample than a normal risk on the same account. Using the same sample size for all assertions regardless of risk level is a common error that inspectors flag. The sample size rationale should be documented in the program itself.