Manual, Automated and IT-Dependent Manual Controls

A control's label is the starting point for testing, not the conclusion on its reliability. Follow how the activity operates, what it depends on and how an exception is resolved.

Controls can involve manual and automated aspects. “IT-dependent manual” is a useful practical label for a human activity that relies on system information; it is not presented here as a separate formal category defined by ASA 315. ASA 315, Appendix 3

Manual: examine what the person actually does

An illustrative supervisor approval may be manual when the decision depends on the supervisor's examination of supporting records. A signature shows that a sign-off occurred, but leaves questions about the review itself.

What criteria were applied? What discrepancy should trigger action? Can the reviewer explain an identified exception and show how it was resolved? The evidence should connect the action to the stated risk, rather than merely confirm that a document carries a name.

Automated: examine the rule and its dependencies

An illustrative system rule may block a transaction when required conditions are not met. The assurance question moves toward configuration, input handling, override paths and changes affecting the rule.

Automation can support consistent execution, but that expectation depends on the application and relevant data not changing in an uncontrolled way. Relevant general IT controls may support continued operation; the response depends on the identified risks and reliance strategy. ASA 330, A29–A32

An image of a setting is not the same as evidence that the rule dealt with the relevant transactions throughout the intended period.

IT-dependent manual: test both links

Consider an illustrative manager reviewing a system-generated exception report and investigating unusual items. The human action and the information supply can fail separately.

A careful reviewer may miss an issue if the report omits it. A reliable report may still be ineffective if the reviewer uses vague criteria or leaves exceptions unresolved.

When entity-produced information is used as audit evidence, evaluate its reliability, including accuracy and completeness as needed, and whether its detail is suitable for the purpose. ASA 500, paragraph 9

Describe the failure path before choosing the test

Use six practical prompts:

• Executor: who or what performs the activity?
• Rule: which condition identifies an error or prevents an action?
• Information: which inputs, reports or parameters does it rely on?
• Dependency: which access, change or other supporting controls matter?
• Exception: who investigates, resolves and escalates the issue?
• Evidence: what shows that these steps operated when required?

These are design questions, not a prescribed universal testing checklist. A spreadsheet can contain manual decisions, automated calculations and imported system information in the same activity. Describe each part instead of forcing the entire process into one box.

Separate a demonstration from period coverage

Seeing a control operate once may help understand implementation. It does not automatically establish effective operation over the full period of reliance. Tests need to fit the intended timing and extent of reliance. ASA 330, A33

Do not infer a fixed sample size from the label “manual” or “automated.” The risk, frequency, evidence and intended reliance shape the testing approach.

Keep the business objective visible

The objective is not to collect a screenshot, a signature and a report. It is to determine whether the control addresses the defined risk, with evidence that supports the conclusion.

This educational comparison uses Australian auditing standards as references. Entity-specific testing requires the actual process and applicable engagement requirements.

Test the action, the information and the dependencies.