Testing controls and IT applications

Establish why a control needs testing

Understanding a control is different from obtaining evidence that it worked. Design asks whether the control could address the relevant risk. Implementation asks whether the entity has put it into use. Operating effectiveness asks whether it worked consistently, through the relevant period, by the appropriate person or automated process.

Test controls when the planned audit response relies on their effectiveness or when substantive procedures alone cannot provide sufficient appropriate evidence for an assertion. The second situation can arise when transaction evidence exists only within an IT system. A predominantly substantive approach may be efficient where manual controls are weak or segregation of duties is limited, but it is not an automatic solution to every evidence gap.

Concept sources: ASA 330, December 2021, paragraphs 8–11 and A18–A24 — required control testing and the distinction from understanding controls.

Connect the control to the risk it addresses

Some controls directly address an assertion, such as preventing duplicate refunds. Others support the environment in which those controls operate: management oversight, ethical expectations, access administration and change management. A broad control is useful for assertion-level reliance only where it is sufficiently precise to address that risk.

Concept sources: ASA 315, December 2023, A5–A6; ASA 330, paragraph 10(b) and A29–A32 — direct, indirect and dependent controls.

In a small entity, an owner-manager's detailed independent review may compensate for limited staff separation. However, the owner may also be able to override the system. Assess the actual precision of the review and the possibility of override. Familiar software or a reputable package is not evidence that the entity has enabled the relevant controls or restricted changes appropriately.

Design a test that can distinguish success from failure

Define the risk, the relevant assertion, the control, the period of intended reliance and what counts as a deviation. Then choose procedures that reveal how the control operated, who performed it and whether exceptions received timely attention. A deviation is a failure of the prescribed control; it need not already have produced a monetary misstatement.

Inspection is helpful when operation leaves records. Observation helps when a process leaves little documentation, but cannot establish year-long consistency by itself. Enquiry identifies how staff perform the control and handle unusual situations; it must be combined with other procedures. Reperformance provides an independent check of the control's outcome.

An electronic approval or signature establishes little about review quality on its own. Examine what the reviewer checked and how identified problems were resolved. Where no durable evidence exists, consider repeated observations, corroborating records or another audit response. Do not equate the absence of errors in substantive testing with proof that controls worked.

Concept sources: ASA 330, paragraphs 8–17 — original decision sequence for control testing and response.

Cover the period of reliance

The extent of testing depends on frequency, intended reliance, expected deviations, evidence quality and evidence from related controls. Testing an interim period requires consideration of subsequent changes and additional evidence for the remainder. If different controls operated before and after a system change, address both periods.

For an automated control, consistent processing may permit an approach centred on testing the logic and relevant IT general controls, including changes to programs and standing data. One successful test does not establish uninterrupted effectiveness when configuration, access or master-data changes remain uncontrolled. Control sampling methods and evaluation are developed together in the next topic.

Concept sources: ASA 330, paragraphs 11–12 and 16–17, A26–A31 — timing, evidence strength, deviations and automated controls.

Use computer-assisted techniques deliberately

Computer-assisted audit techniques can select items, compare fields, recalculate values and examine entire electronic populations. Spreadsheets, audit software, database tools and automated routines can all support this work. Data analytics expands pattern and exception analysis; robotic process automation can repeat well-defined tasks. Neither replaces a well-designed audit objective.

A useful control test might identify refunds approved by their preparer across the whole year. Before relying on the output, verify that the extract includes every relevant system and period, that user identifiers have been mapped correctly, and that the query implements the approval rule. Investigate exceptions: a flagged item may reflect an authorised arrangement, a data problem or a failed control.

Full-population testing removes sampling uncertainty for the tested characteristic in that population. It does not establish that the population is complete, the test logic is correct or every assertion is satisfied. Poorly structured data, missing history and unavailable access may limit what the tool can support.

Concept sources: ASA 330, A16; ASA 500, paragraph 9 — electronic testing and data reliability.

Design test data around the programmed rule

Test data consists of auditor-designed transactions with predetermined expected outcomes. Include valid transactions, invalid inputs and boundary cases. Compare actual processing with the expected acceptance, rejection, calculation or escalation. Establish that the tested program and configuration are relevant to the period under audit.

Consider an event platform that allows automatic cancellation refunds until exactly 72 hours before an event, prevents a second refund and requires supervisor approval for refunds above $800.

Concept sources: ISACA Interactive Glossary, “Test data” — concept definition; the event-platform rules, amounts and test cases above are original.

This original test design should also address missing booking identifiers and invalid field formats where those checks form part of the control. Testing only rejected cases misses the possibility that valid activity is incorrectly blocked. Resolve unexpected outputs and assess their implications for both controls and recorded amounts.

Distinguish an integrated test facility

An integrated test facility places controlled test entities and transactions within the production system, with management's permission. Test activity is processed alongside normal activity, allowing the auditor to examine the operational environment over time. A separate test-data run principally examines the programmed rules under the conditions of that run.

The distinction is therefore the processing environment and continuity of testing, not simply whether the auditor invented the inputs. For an integrated facility, plan how test records are identified, how outputs are checked and how unintended payments, customer communications or financial-report contamination are prevented and reconciled. Repeated tests can support continuity, but still need appropriate coverage and effective supporting controls.

Concept sources: ISACA Interactive Glossary, entries “Test data” and “Integrated test facilities (ITF)” — terminology; application safeguards are original practical explanations.

Sources and further reading

• ASA 330, December 2021: required control testing, nature, timing and extent, and responses to deviations.
• ASA 315, December 2023: direct and supporting controls and the IT environment.
• ASA 500, December 2022: reliability of information used in testing.
• ISACA Interactive Glossary: professional definitions of test data and integrated test facilities; the web glossary is undated.
• IAASB, Addressing Risk of Overreliance on Technology, March 2021: non-authoritative further reading on technology reliance.