IT General Controls vs. Application Controls

A well-configured application rule is only part of the assurance story. Ask what the rule checks—and what protects its continued operation and the information it uses.

Two layers, different purposes

An application control addresses a transaction or information-processing question. Examples include an approval limit, a duplicate-invoice check or a comparison of purchase order, receipt and invoice information.

General IT controls support the environment in which those rules and records operate. Relevant areas commonly include access administration, changes to programs or configurations, and IT operations.

ASA 315 distinguishes general IT controls from information-processing controls in the Australian financial-report audit context. The latter may be manual or automated. The word application should therefore not be used as a synonym for every automated control—or for the entire security environment.

Follow one business control to its dependencies

Consider an illustrative three-way match that flags invoices outside an agreed tolerance. First identify what it compares, the tolerance logic, the relevant population and the treatment of exceptions.

Then ask who can change that tolerance, override a hold or alter underlying receipt data. Understand which interfaces and processing jobs supply the information. A successful demonstration using one invoice does not answer all these dependency questions.

Draw the connection from the business risk to the specific rule, supporting data and relevant technology controls. This prevents a generic IT checklist from replacing a focused assurance response.

Access: who can affect the evidence?

Evaluate the relevant capabilities rather than job titles alone. An administrator may be able to change configurations, adjust data or disable records of activity. A business user may hold incompatible permissions even without an IT title.

For the example, inspect the relevant access, approvals and changes over the period. Determine whether monitoring or other controls address the risk of inappropriate actions. These are practical questions, not a universal access-review frequency.

Changes: what kept the rule consistent?

Trace relevant configuration or program changes to authorization, testing and implementation evidence. Include emergency changes and subsequent review where they affect the business control.

A rule that works today may have differed earlier. Tie the evidence to the period and version on which reliance is intended, and consider whether a change affected existing transactions or data.

Operations: did the information arrive intact?

Review relevant interfaces, job failures, reconciliations and exception resolution. A rule cannot match complete transactions if a feed omits a business unit or drops failed records without follow-up.

The ASA 315 Appendix 6 offers considerations for understanding general IT controls. NIST SP 800-53 Rev. 5 provides a broader, tailorable security and privacy control catalog. Its families include access, configuration and contingency topics; it is supporting context, not a substitute for audit requirements or a mandatory checklist for every organization.

Evaluate weaknesses through their effect

An ITGC deficiency requires understanding which application controls, data and periods may be affected. It is not an automatic conclusion that every system record or application control is unreliable.

Conversely, effective ITGC does not prove that the business rule is correctly designed. A perfectly controlled deployment can still install the wrong matching logic.

ASA 330 links further procedures to assessed risks. Determine whether additional evidence, compensating controls or a revised approach can address the identified exposure. Do not assume substantive work always resolves every technology-related gap.

Test the rule. Understand its dependencies. Explain what the combined evidence supports.