Testing Controls: Design Is Not Operating Effectiveness

A control can be well designed, installed and still fail in operation. Assurance needs to distinguish those states before deciding what reliance the evidence supports.

Design: could it address the risk?

Begin with the risk and control objective. Identify who performs the control, what information is used, what action is taken and how exceptions are resolved. Ask whether the control is capable of preventing, or detecting and correcting, the problem in time.

Consider an illustrative purchase approval. Requiring a signature is not necessarily enough. If the reviewer cannot see the order, price agreement and relevant authority, the signature may provide little evidence that the risk was addressed.

The approval also needs an appropriate boundary: which transactions, changes and exceptions are covered? A control over normal orders may leave emergency purchases or later price amendments outside its scope.

Implementation: does it exist and is it used?

Look beyond the policy. Walk through an actual transaction and inspect how the control is applied. Check whether the configured workflow, access and supporting records match the described design.

ASA 315, A175–A180 distinguishes evaluating design and determining implementation from testing operating effectiveness. Inquiry alone is insufficient for design and implementation evidence in that financial-report audit context.

A transaction can demonstrate that an approval step is in use today. That does not establish that the manual review worked at other times during the period.

Operation: did it work when it mattered?

Define the period and the extent of intended reliance. Examine evidence of performance at relevant times, how consistently the control was applied and whether the performer had the information and authority needed.

For the purchase example, evaluate whether the review was meaningful, timely and supported—not merely whether an approval mark appears. Consider exceptions, staff changes and bypass routes that could affect the conclusion.

ASA 330, paragraphs 8–12 addresses control testing, supporting dependencies and the period of reliance. These are Australian financial-report audit requirements; this learning map is not a universal audit programme.

Change the evidence with the control

Manual and automated controls need different evidence strategies. For an automated approval limit, understand the configured logic and relevant access, change and processing dependencies. A reliable automated rule may operate consistently, but that depends on the environment and changes affecting it.

ASA 315 recognises that testing relevant general IT controls can support a strategy for consistent automated operation. It is therefore too simplistic to prescribe repeated manual-style testing for every automated control.

There is no universal sample size in this map. The objective, risk, frequency, population, expected deviations and intended reliance inform the work.

Understand deviations before concluding

A missing approval may reflect a failed control, an inapplicable rule, incomplete records or a different authorized route. Obtain evidence to distinguish these explanations.

Assess whether the issue changes intended reliance or requires further procedures. The absence of detected misstatements in other testing does not, by itself, prove that the control operated effectively.

Keep the conclusion proportionate: describe which control, period and risks the work supports, and which gaps remain. Management owns correcting weaknesses; assurance work evaluates the evidence.

Keep three conclusions separate

• Design: the control is capable of addressing the stated risk.
• Implementation: it exists and the entity uses it.
• Operation: evidence supports its performance for the intended reliance.

A walkthrough can explain the control. It does not automatically prove the control worked throughout the period.