- Describe the four ITGC domains and the risks each addresses
- Identify typical key controls in each domain
- Map an IT risk to the domain and control that responds to it
- Decide when program development controls need testing
Why four domains
Practitioners group general IT controls into four domains: access to programs and data, program change, computer operations, and program development. AS 2201 uses three of these terms directly in its benchmarking guidance, which conditions benchmarking on effective "general controls over program changes, access to programs, and computer operations." AU-C 315 defines the entity's IT processes the same way: managing access, managing program changes or changes to the IT environment, and managing IT operations. Program development adds the controls over new systems and major implementations.
The domains are a filing system for risks, not a checklist to test in full. Test the controls that address the risks arising from IT you identified for in-scope applications.
Access to programs and data
Risk: people get or keep access they should not have, so they can initiate, approve or change transactions, data or settings without authority.
Typical key controls:
- New user access is requested and approved by the business owner before it is granted.
- Access is removed timely when employees leave or change roles.
- User access is reviewed periodically by someone who knows what each user should have.
- Privileged and administrator accounts are restricted and monitored.
- Password and authentication settings meet the entity's policy.
Lessons 4 and 5 cover testing.
Program change
Risk: changes to programs, configurations or interfaces are made without authorization or testing, so the system no longer processes data as intended.
Typical key controls:
- Changes are requested, approved, tested and approved for migration to production.
- Developers cannot move their own changes into production (segregation of the development and production environments).
- Emergency changes are documented and approved after the fact.
- Configuration changes (posting rules, approval limits, tolerances) follow the same path.
Lesson 6 covers testing.
Computer operations
Risk: scheduled processing fails or runs incompletely, data is lost or corrupted, or incidents go unresolved.
Typical key controls:
- Batch jobs and interfaces are scheduled, monitored and failures are resolved.
- Backups are performed and restores are tested.
- Incidents affecting financial data are logged, investigated and closed.
Lesson 7 covers testing.
Program development
Risk: a new system or major upgrade is implemented with incorrect logic or with data that did not convert completely and accurately.
Typical key controls:
- Implementation projects have approved requirements and user acceptance testing.
- Data conversion is reconciled from the old system to the new system.
- Go-live is approved by business and IT owners.
Program development controls matter in the year of an implementation. If the client implemented a new general ledger system mid-year, data conversion is a direct risk to opening balances in the new system, and the auditor tests the conversion reconciliation or performs substantive procedures over converted balances.
Mapping risks to domains
| Risk arising from IT | Domain | Control to test |
|---|---|---|
| Former employee posts entries | Access | Timely termination |
| Developer changes commission logic | Change | Approval and environment segregation |
| Nightly interface to the ledger fails silently | Operations | Job monitoring and failure follow-up |
| Opening balances misstated at conversion | Development | Conversion reconciliation |
Pervasive versus specific
Some ITGCs support every application (for example, a single sign-on directory that controls access to all systems). A deficiency there affects many automated controls at once. Others are application-specific. Note this in your risk and control matrix so the deficiency evaluation in lesson 14 starts from a clear map.
Documentation
A risk and control matrix for ITGCs should list, per application, each risk, the domain, the control, the control owner, frequency, and whether it is key. Keep the matrix aligned with the IT environment map from lesson 2.
Building the ITGC map for Wren Creek Foods
Wren Creek Foods runs an in-house order application and a packaged general ledger system. During the year it also replaced its payroll module.
The team maps risks to domains:
- Order application, change: in-house developers modify pricing logic monthly. Key controls: change ticket approval, user acceptance sign-off, and a deployment tool that only the release manager can operate.
- Order application, access: twelve users can maintain customer credit limits. Key control: quarterly access review by the credit manager.
- General ledger, access: four administrator accounts. Key control: monthly review of administrator activity logs by the controller.
- General ledger, operations: a nightly interface posts order data. Key control: the accounting supervisor reviews the interface exception report each morning.
- Payroll module, development: go-live in April. Key control: reconciliation of employee master data and year-to-date earnings from the old module to the new one, signed by the payroll manager and IT lead.
Conclusion: the team tests one development control (the April conversion reconciliation), plus change, access and operations controls for the full year. It does not test program change controls over the packaged general ledger code because the client cannot modify it, and it documents that rationale. General ledger configuration changes (posting rules, approval limits) stay in the change population.
Self-check
Answer each question before you open the answer.
Which three ITGC areas does AS 2201 name as conditions for benchmarking an automated control?
Show answer
General controls over program changes, access to programs, and computer operations (AS 2201.B29). If they are effective and continue to be tested, and the control has not changed since the baseline, the auditor may conclude the automated control remains effective without repeating the prior-year test.
When do program development controls become a key area?
Show answer
In a period with a new system or major upgrade, because data conversion and new processing logic directly affect balances and automated controls from go-live forward.
Why flag a pervasive ITGC separately from an application-specific one?
Show answer
A deficiency in a pervasive ITGC (for example, a shared directory controlling access to every application) affects many automated controls and reports at once, which changes the deficiency evaluation.
Use it on the file
- TemplateRisk and Control Matrix: IT General Controls
- TemplateSOX ITGC Test Plan
- GuideIT Audit Guide: ITGC Program, Testing Steps and Checklist for Financial Audits
Sources
- PCAOB, Auditing Standards compilation including AS 1105, AS 2110, AS 2201, AS 2601 and AS 2605
- AICPA, Statements on Auditing Standards currently effective (AU-C sections, including AU-C 315 as amended by SAS No. 145)
Standards are paraphrased from the primary sources listed above; read the source before relying on a requirement. This lesson is training material, not professional advice. Report an error