How auditors connect IT general controls, application controls, system-generated information, and cybersecurity risks to financial statement audit work.
IT auditing matters on AUD because financial statement information often comes from systems, interfaces, automated calculations, and system-generated reports. The auditor does not audit technology for its own sake. The auditor evaluates technology when it affects risk assessment, evidence reliability, control reliance, or reporting.
The key distinction is between general controls that support the overall IT environment and application controls that operate inside a specific business process. Weak general controls can make otherwise strong application controls unreliable.
flowchart TD
A["Financial statement account or disclosure"] --> B["Significant transaction flow"]
B --> C["Application and reports used by finance"]
C --> D["Application controls"]
C --> E["System-generated information"]
D --> F["Reliance depends on IT general controls"]
E --> F
F --> G["Access, change management, operations, and backup controls"]
G --> H["Audit response: rely, test more, use specialists, or perform substantive procedures"]
Technology affects the audit when it changes how transactions are initiated, authorized, processed, recorded, summarized, or reported.
| IT condition | Audit consequence |
|---|---|
| Revenue transactions are processed automatically | Auditor evaluates automated controls and system logic. |
| Management uses system-generated aging reports | Auditor tests report completeness and accuracy before relying on the report. |
| Users can change master data without approval | Unauthorized changes can create misstatement risk. |
| Interfaces move data between systems | Completeness and accuracy of transfers become audit concerns. |
| Privileged users can modify production code | Application controls may be unreliable if change controls are weak. |
| Backups are not tested | Availability and recoverability issues can affect evidence and operations. |
The audit question is not “Is the system modern?” It is “Can this system produce reliable audit evidence and support the controls management says are operating?”
IT general controls, or ITGCs, are broad controls that support the reliability of systems and applications. They do not usually validate one transaction directly, but they help determine whether application controls and system-generated information can be trusted.
| ITGC area | What the auditor tests | Why it matters |
|---|---|---|
| Access management | Provisioning, termination, periodic access reviews, privileged access, and segregation of duties. | Unauthorized users may enter, approve, change, or conceal transactions. |
| Change management | Request, approval, testing, migration, and emergency-change controls. | Unauthorized or untested changes can break reports, calculations, or controls. |
| IT operations | Job monitoring, incident handling, batch processing, backups, and recovery. | Failed jobs or unrecoverable data can affect completeness and availability. |
| Program development | Development methodology, testing, approval, and implementation controls. | New systems can introduce defects if development controls are weak. |
| Security monitoring | Logging, alert review, vulnerability response, and incident escalation. | Security events can affect data integrity or evidence reliability. |
When ITGCs are ineffective, the auditor may need to reduce reliance on automated controls, expand substantive testing, use specialists, or obtain more direct evidence.
Application controls operate within a specific application or transaction cycle. They are closer to the financial statement assertions than ITGCs.
| Application control | Assertion supported |
|---|---|
| Valid customer number required before sale is accepted | Occurrence and accuracy. |
| Three-way match before vendor payment | Occurrence, accuracy, and authorization. |
| Automated price calculation from approved price table | Accuracy. |
| Sequential invoice numbering and exception reports | Completeness. |
| Credit-limit block on customer orders | Valuation and collectibility risk response. |
| Automated depreciation calculation | Accuracy and allocation. |
Application controls can be powerful because they operate consistently, but only if the system logic, input data, and supporting ITGCs are reliable.
Auditors often use reports generated from the client’s systems, such as aging reports, inventory listings, fixed asset registers, exception reports, access listings, or sales summaries. Before relying on them, the auditor considers whether the report is complete and accurate.
| Report risk | Audit procedure |
|---|---|
| Report excludes some locations or entities | Reconcile report population to the general ledger or source system. |
| Parameters were changed by management | Inspect report criteria, filters, and screenshots or rerun evidence. |
| Data extraction is incomplete | Compare record counts, control totals, or hash totals where available. |
| Calculated fields are wrong | Recalculate selected items or test report logic. |
| User access listing omits privileged accounts | Reconcile to directory or identity-management records. |
The exam trap is relying on a report because it “came from the system.” System origin does not prove reliability.
Auditors gather IT evidence through inquiry, inspection, observation, reperformance, and data testing. Inquiry alone is rarely enough for control reliance.
| Evidence type | Example |
|---|---|
| Configuration evidence | Password settings, role permissions, workflow rules, or automated tolerance limits. |
| Log evidence | User access logs, change logs, batch job logs, or security event logs. |
| Ticket evidence | Access requests, terminated-user tickets, change approvals, and incident tickets. |
| Reperformance | Recalculating an automated control or rerunning a report with agreed parameters. |
| SOC reports | Service organization reports for outsourced systems or cloud providers. |
| Specialist work | IT audit specialist testing complex access, change, cybersecurity, or analytics areas. |
Specialists help with technical procedures, but the audit team still needs to understand how the work affects audit risk and conclusions.
Not every system needs the same level of IT audit work. The auditor scopes systems based on financial relevance and risk.
| Scoping question | Why it matters |
|---|---|
| Does the system process material transactions? | Material cycles usually require more attention. |
| Does the system generate reports used as audit evidence? | Report reliability must be tested before use. |
| Does the system host key controls? | Control reliance may depend on ITGCs. |
| Is the system outsourced? | SOC reports or service-provider controls may be relevant. |
| Has the system changed recently? | New implementations and upgrades increase risk. |
| Are privileged users or developers able to change production data? | Segregation and change controls become critical. |
The auditor should link each IT procedure to an audit risk. Testing technology without a financial statement connection can waste audit effort.
Use this sequence for IT audit fundamentals questions: