Testing and Documenting IT General Controls for Access, Change, and Operations Reliance

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

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

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 and Backups

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.

Documentation Quality

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.

Testing Exceptions

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.

Exam Traps

  • ITGCs support reliance on automated controls and system-generated information; they do not directly prove account balances.
  • Developer access to production is a change-management and segregation-of-duties risk.
  • Periodic access reviews are useful only if the population is complete and exceptions are resolved.
  • Backup completion logs are weaker than restoration-test evidence.
  • Flowcharts help documentation, but they do not prove operating effectiveness by themselves.
  • Inquiry alone rarely supports operating effectiveness.
  • ITGC exceptions require an audit response, not just an IT observation.

Quick Review

Use this sequence for ITGC questions:

  1. Identify the application, report, or automated control the audit team wants to rely on.
  2. Determine which ITGCs support that reliance.
  3. Test access provisioning, termination, privileged access, and access reviews.
  4. Test change requests, approvals, testing, and production migration.
  5. Test operations controls such as job monitoring, interfaces, incidents, backups, and restoration.
  6. Document population, sample, evidence, exceptions, and conclusion.
  7. Translate exceptions into revised control reliance or additional substantive procedures.

Review Questions

### What is the main audit purpose of testing IT general controls? - [ ] To prove every account balance directly. - [x] To evaluate whether applications, automated controls, and system-generated information can be relied on. - [ ] To replace all substantive audit procedures. - [ ] To prepare the client's cybersecurity policy. > **Explanation:** ITGCs support reliability of systems and controls used in the financial statement audit. ### Which evidence is most relevant when testing terminated-user access? - [ ] A list of office equipment. - [x] HR termination records compared with system deactivation records. - [ ] The client's website terms of use. - [ ] A narrative written before the audit period. > **Explanation:** Termination testing compares actual employee termination dates with access removal evidence. ### Which control best prevents developers from deploying unapproved code to production? - [ ] A backup retention policy alone. - [x] Segregation of duties with controlled approval and migration procedures. - [ ] A larger hard drive. - [ ] Annual cybersecurity training only. > **Explanation:** Developers should not be able to move their own unapproved changes into production. ### What should the auditor inspect in a sample of program changes? - [ ] Only the final version number. - [x] Request, approval, testing evidence, migration evidence, and closure. - [ ] Only the developer's verbal explanation. - [ ] Only the user manual. > **Explanation:** Change testing traces the change through the controlled lifecycle. ### Why is a restoration test important? - [ ] It proves passwords are complex. - [x] It provides evidence that backed-up data can actually be recovered. - [ ] It replaces access reviews. - [ ] It proves all reports are complete. > **Explanation:** A backup schedule does not prove recoverability; restoration testing is stronger evidence. ### What should an auditor do when an access review shows exceptions that were not remediated? - [ ] Ignore the exceptions because a review occurred. - [x] Evaluate whether inappropriate access existed and whether audit reliance or further procedures are affected. - [ ] Automatically issue an adverse opinion. - [ ] Delete the access review from the file. > **Explanation:** Unresolved exceptions may indicate access risk that affects reliance. ### What makes a screenshot stronger audit evidence? - [ ] It has bright colors. - [ ] It is cropped to remove context. - [x] It shows source, date, relevant settings, and connection to the test performed. - [ ] It is pasted without explanation. > **Explanation:** Screenshots need context and traceability to support audit conclusions. ### Which ITGC exception most directly threatens an automated revenue control? - [ ] A typo in a user training deck. - [x] An unapproved production change to the revenue application during the audit period. - [ ] A printer jam in the mailroom. - [ ] A new laptop purchase for HR. > **Explanation:** Unauthorized changes to the revenue application may alter automated control logic. ### What should ITGC documentation include? - [ ] Only management's assertion that controls work. - [x] Control objective, population, sample, evidence, exceptions, and conclusion. - [ ] Only a list of software names. - [ ] Only screenshots with no testing notes. > **Explanation:** Documentation should connect the testing performed to the audit objective and conclusion. ### True or false: IT general controls can matter for small entities if they rely on systems for financial reporting. - [x] True. - [ ] False. > **Explanation:** ITGC relevance depends on system reliance and audit risk, not only entity size.
Revised on Monday, June 15, 2026