22.2 IT General Controls and Application Controls
Key Takeaways
- IT general controls (ITGCs) support the continued reliability of applications, data, automated controls, and system-generated reports used as audit evidence.
- Application controls operate within a single business process and address transaction completeness, accuracy, authorization, validity, cutoff, or processing integrity.
- Weak logical access or change management can undermine reliance on an otherwise well-designed automated application control.
- The auditor should connect IT controls to financial statement risks rather than testing technology controls merely because they exist.
- An IT-dependent manual control combines a human review with a system-generated report, so the auditor must also verify the report's completeness and accuracy.
Why IT Controls Matter in AUD and ISC
Modern audit evidence usually begins inside an information system. Revenue may originate in an order-management platform, payroll may run through a cloud provider, and the financial close may post through an enterprise resource planning (ERP) system. The 2026 AUD blueprint expects candidates to understand IT infrastructure, applications, processes that manage access, and program change controls when those systems affect financial reporting. The Information Systems and Controls (ISC) discipline extends the same logic into systems, processing integrity, security, availability, confidentiality, privacy, and SOC engagements.
The core distinction is structural: IT general controls (ITGCs) are the pervasive controls around the environment, while application controls are the controls embedded inside a particular process or program. ITGCs answer "can we trust that the system and its data were not improperly accessed or changed?" Application controls answer "does this transaction-level control address the assertion?"
General Controls vs. Application Controls
| Control type | Examples | Main audit question | Typical evidence |
|---|---|---|---|
| Logical access (ITGC) | User provisioning, role-based access, privileged-access review, terminated-user removal | Can unauthorized users enter, change, or approve transactions? | Access listings, tickets, approvals, review signoffs |
| Change management (ITGC) | Restricted developer access, test approval, migration approval, emergency-change review | Could unauthorized or untested code alter processing? | Change tickets, test results, approvals, deployment logs |
| IT operations (ITGC) | Job scheduling/monitoring, backup completion, incident handling, interface monitoring | Did processing run completely and accurately? | Job logs, incident tickets, batch totals, backup logs |
| Program development (ITGC) | System acquisition, configuration, user acceptance testing | Was a new or modified system built to meet control requirements? | Project approvals, test scripts, signoffs |
| Application control | Edit checks, automated calculations, three-way match, duplicate-invoice block, credit-limit hold | Does this transaction-level control address the assertion? | Configuration screens, test transactions, exception reports |
Application controls are frequently preventive: a system rejects duplicate invoice numbers, blocks sales above a credit limit, requires approval for master-data changes, or calculates depreciation using configured rates. They can also be detective, such as exception reports or automated reconciliations. An application control's strength is also its weakness, because it is programmed: it operates consistently, so it usually only needs to be tested once if ITGCs over change management are effective for the full period.
ITGCs rarely prove a specific transaction was valid. Instead, they support confidence that the application and its data were not improperly changed, accessed, or processed. If the system blocks duplicate vendor invoices, the auditor first confirms the control is configured correctly, then confirms that change-management and access ITGCs preserved that configuration all year.
The Reliance Workflow
Use this workflow whenever a scenario includes an automated control or a system-generated report:
- Identify the financial statement risk and assertion.
- Identify the application, database, report, interface, or spreadsheet that affects the risk.
- Determine whether the relevant control is manual, automated, or IT-dependent manual.
- Test the application control design through walkthrough, configuration inspection, or a test transaction.
- Identify the ITGCs supporting that application or report, especially access and change management.
- Test operating effectiveness for both the application control and the supporting ITGCs when reliance is planned.
- If ITGCs fail, reassess control reliance and increase substantive procedures.
An IT-dependent manual control is a heavily tested trap. Suppose the controller reviews a monthly sales-margin exception report. The review is manual, but the report's completeness and accuracy depend on IT. The auditor needs evidence that the report logic is correct, the source data is complete, and access or change controls prevented unauthorized modification, otherwise the human review rests on an unverified report.
Exam Scenarios and the Common Trap
If a developer can directly modify production code for the revenue application without independent approval, a year-end automated revenue-cutoff control becomes less reliable regardless of how well it appears designed. If terminated employees remain active in the ERP with posting rights, segregation of duties and authorization controls are weakened. If batch jobs fail without investigation, the completeness of processed transactions is at risk.
Do not over-test technology that has no financial-reporting link. A marketing analytics platform may matter to the business but is not automatically relevant to ICFR. The CPA answer ties the control to the system, the financial process, and the assertion. That linkage is the difference between a generic IT answer and an audit answer.
Benchmarking and End-User Computing
Two nuances recur on the exam. First, benchmarking of automated application controls: when ITGCs over program changes are effective and the control is fully automated, the auditor may carry forward prior evidence of operating effectiveness rather than retest the control each year, provided the auditor establishes that the control has not changed. The auditor still confirms, through change-management evidence, that no modification occurred since the baseline test.
Second, end-user computing, especially spreadsheets. A close process that depends on a complex spreadsheet for revenue allocation or a reserve estimate is an IT-dependent process even though no formal application is involved. The auditor evaluates access to the spreadsheet, version and formula integrity, input completeness, and whether a reviewer independently verifies the output. Spreadsheets often sit outside formal change-management ITGCs, so their reliability must be established directly.
| Risk pattern | Control gap | Audit response |
|---|---|---|
| Developer with production access | Change management weak | Reassess reliance; expand substantive work |
| Terminated users still active | Logical access weak | Test authorization and segregation directly |
| Unreconciled batch interface | IT operations weak | Test completeness of transferred data |
| Uncontrolled close spreadsheet | End-user computing | Verify formulas, inputs, and independent review |
The through-line is always the same: every IT control the auditor tests should trace back to a financial statement risk and a specific assertion, never to technology for its own sake.
Which control is the best example of an application control rather than an IT general control?
An auditor plans to rely on an automated three-way match control in the purchasing system. Which finding most directly threatens that reliance?