How auditors test and document IT general controls over access, change management, operations, backups, and system-generated audit evidence.
IT general controls support the reliability of applications, automated controls, reports, interfaces, and data used in the audit. They are not tested as a checklist exercise. They are tested because weak access, change, or operations controls can undermine the evidence produced by financial reporting systems.
For AUD, the main task is to connect each ITGC test to control reliance. If the audit team relies on an automated three-way match, system-generated aging report, or automated revenue interface, it must consider whether the surrounding IT environment supports that reliance.
flowchart TD
A["Audit team wants to rely on application control or report"] --> B["Identify supporting ITGCs"]
B --> C["Access controls"]
B --> D["Change-management controls"]
B --> E["IT operations and backup controls"]
C --> F["Test design and operating effectiveness"]
D --> F
E --> F
F --> G{"ITGCs effective?"}
G -- "Yes" --> H["Control reliance may be supportable"]
G -- "No" --> I["Revise audit response and obtain alternate evidence"]
Access controls restrict who can enter systems, approve transactions, change data, or administer applications. The audit risk is unauthorized access that could cause or conceal a material misstatement.
| Access control | Test focus | Evidence examples |
|---|---|---|
| New-user provisioning | Access is approved before account creation and matches job responsibilities. | Access request ticket, manager approval, role assignment, and user listing. |
| Terminated-user removal | Access is removed promptly after employment ends. | HR termination report, deactivation timestamp, and access listing. |
| Role changes | Transfers and promotions do not leave excessive access. | Role-change approval, access review evidence, and before/after permissions. |
| Privileged access | Administrative rights are limited, monitored, and reviewed. | Admin listing, approval records, activity logs, and review sign-off. |
| Periodic access review | Management reviews user access for appropriateness. | Review population, reviewer evidence, exceptions, and remediation. |
| Segregation of duties | Incompatible access is prevented or monitored. | Role matrix, conflict report, compensating control evidence. |
Inquiry alone is not sufficient. The auditor normally inspects system listings, HR records, tickets, approvals, and evidence of follow-up on exceptions.
Change-management controls prevent unauthorized or untested changes from entering production systems. These controls are critical when the auditor relies on automated controls or system-generated reports.
| Change-control step | Audit concern |
|---|---|
| Change request | Was the change requested for a valid business or control purpose? |
| Approval | Did appropriate business and IT personnel approve the change? |
| Testing | Was the change tested before production release? |
| Segregation | Were developers restricted from directly migrating their own code to production? |
| Production migration | Was deployment performed by authorized personnel using controlled procedures? |
| Emergency change | Were urgent changes reviewed and approved after implementation when necessary? |
The auditor commonly selects a sample of changes and traces each one from request through approval, testing, migration, and closure. Missing evidence in any step can affect reliance on the related application.
IT operations controls support ongoing processing, job completion, incident handling, and data recoverability.
| Operations control | Why it matters |
|---|---|
| Batch job monitoring | Failed processing jobs can cause incomplete or inaccurate transaction posting. |
| Interface monitoring | Data transfers between systems can fail or duplicate transactions. |
| Incident management | Security or processing incidents may affect data integrity or availability. |
| Backup completion | Backups reduce data-loss risk but do not prove recoverability. |
| Restoration testing | Successful restore tests provide stronger evidence that backups can be used. |
| Disaster recovery planning | Recovery objectives should match financial reporting and operational needs. |
The exam trap is treating a backup schedule as enough. A backup that has never been restored may not support an availability or recoverability conclusion.
ITGC documentation should show what control was tested, why it matters to the audit, what evidence was inspected, what period was covered, what exceptions were found, and what conclusion was reached.
| Documentation element | Good audit file practice |
|---|---|
| Control objective | Link the ITGC to a financial reporting risk, application, report, or automated control. |
| Population | Define the complete population, such as all changes during the period or all terminated users. |
| Sample selection | Show how the sample was selected and why it is appropriate. |
| Evidence source | Identify system, report date, preparer, reviewer, and extraction method when relevant. |
| Test result | Document exceptions, explanations, corroboration, and remediation. |
| Conclusion | State whether the control supports reliance and how exceptions affect the audit response. |
Screenshots should be dated, traceable, and tied to the relevant system. A screenshot without context is weak evidence.
When an ITGC exception is found, the auditor evaluates severity and audit effect.
| Exception | Possible audit effect |
|---|---|
| Terminated user retained access to a financial application | Test activity after termination, evaluate unauthorized access risk, and consider expanded procedures. |
| Developer migrated code directly to production | Evaluate whether automated controls or reports may have changed without approval. |
| Missing testing evidence for a change | Consider whether the change affected financial reporting logic. |
| Backup failed without follow-up | Evaluate availability and data-loss risk for the affected period. |
| Access review performed late or without remediation | Determine whether inappropriate access existed and whether compensating controls operated. |
Not every ITGC exception causes a material misstatement, but every relevant exception should be translated into a control-reliance or substantive-testing decision.
Use this sequence for ITGC questions: