Every automated control you rely on, every system report you accept as evidence, and every segregation-of-duties (SoD) conflict the ERP is supposed to block rests on four things most financial auditors have never tested: who can get into the system, who can change it, how it was built or bought, and whether it runs and recovers as intended. Those are the IT general controls (ITGCs). When they fail, the failure is silent: a developer alters a posting rule without approval, or a terminated payroll clerk’s account keeps working for six weeks. Material weakness disclosures keep returning to the same sentence, “we did not maintain effective controls over user access and program change.” The vocabulary is unfamiliar to non-IT auditors; the work is populations, samples, and evidence, exactly like testing a bank reconciliation.
This guide was rewritten in September 2026 to reflect the Global Internal Audit Standards, NIST SP 800-63B-4, and current practice for SaaS and pipeline-based change control. It gives you a 24-row test matrix (domain, objective, control, test with population and sample, evidence), a sample-size ladder, an evidence request (PBC) list, a 20-question interview script with what a good answer sounds like, a worked change-management test on 214 changes with one exception evaluated end to end, a deficiency decision table, and a findings table with root causes and remediation. It assumes you have settled scope with the SOX ITGC scoping guide and can explain why application controls depend on ITGCs.
In this guide
- What ITGCs are and what depends on them
- Scoping the review: systems, layers, and period
- The ITGC test matrix: 24 controls with populations, samples, and evidence
- Evidence request list for an ITGC review
- Interviewing IT owners: 20 questions and what a good answer sounds like
- Worked example: testing change management on 214 changes
- Evaluating ITGC deficiencies and reporting them
- Common ITGC findings, root causes, and remediation
- Mistakes non-IT auditors make in ITGC reviews
- Adapting the approach: SaaS, cloud, pipelines, small teams, acquisitions
What ITGCs are and what depends on them
ITGCs are the controls over the environment in which applications run: who can reach programs and data, how programs are changed, how systems are built or bought, and how processing runs day to day. COSO’s 2013 framework places them under Principle 11 (“the organization selects and develops general control activities over technology to support the achievement of objectives”); the COSO 17 principles guide shows how it is evidenced. Practitioners and external auditors use four domains: access to programs and data, program changes, program development (including acquisition), and computer operations. PCAOB AS 2201 uses the same split in its benchmarking paragraphs (B28 to B33), so the four-domain model is the one to use for ICFR even where IT organizes itself around COBIT 2019 or the 93 Annex A controls of ISO/IEC 27001:2022.
A financial auditor cannot hand this area to someone else because of the dependency chain. An automated three-way match, a system-enforced approval limit, an aging report, and a SoD ruleset are only as reliable as the environment around them. AS 2201.B29 lets an auditor stop re-testing an automated control each year (benchmarking) only if general controls over program changes, access, and operations are effective and the control has not changed since the baseline. Lose change management and you lose benchmarking, and a changed posting map or pay rule goes unnoticed. Lose access control and every system-generated report you used as evidence becomes information whose completeness and accuracy you have not established, the problem the IPE testing guide exists to solve. Lose operations and interfaces drop records silently; lose development controls and a new system’s opening balances are unproven.
Each domain applies at more than one layer. An ERP sits on a database, on an operating system, reached through a directory (Active Directory or Entra ID in most companies). A DBA who can run an update statement against the invoice table bypasses every application control you tested; a server administrator who can copy the database file bypasses the DBA. So the database and operating system layers come into scope wherever direct access could alter financial records, and the access tests below are repeated per layer. A privileged access audit is therefore the highest-yield ITGC work there is: small population, total exposure, unambiguous exceptions.
An ITGC review for financial reporting is deliberately narrow: not a cybersecurity assessment, a penetration test, or a review of IT strategy. If scope extends into security monitoring, vulnerability management, or incident response, the IIA’s Cybersecurity Topical Requirement (effective 5 February 2026) applies; the cybersecurity program audit guide and the topical requirements guide cover what that adds, with NIST CSF 2.0’s six functions as the structure. GIAS Standard 3.1 (Competency) still requires that the team collectively has the knowledge: pair a financial auditor with an IT auditor or co-source specialist for the database and operating system layers, and keep populations, sampling, evidence, and deficiency evaluation with the financial auditor.
Scoping the review: systems, layers, and period
Scoping starts from the financial statements, never from the IT asset inventory: significant accounts, the processes behind them, the applications those processes run on, the automated controls and key reports inside each, and the stack under each one. The SOX scoping guide covers the account-to-process step; for the ITGC layer the questions are which applications hold or transform financial data, which layers beneath them can change that data, and which shared IT processes govern them all. Record the answer in a scoping memo (the planning memo template works); scope is the first thing the external auditor challenges when relying on your work under GIAS Standard 9.5 (Coordination and Reliance).
- List the applications. Per significant process: application, automated controls, key reports, interfaces, master data. A spreadsheet is an end-user computing tool, not an application.
- Map the stack. Database, operating system, directory, scheduler, middleware, and the administrator of each; verify the diagram against the DBA’s server list.
- Identify shared processes. Provisioning, change, and backup usually run once for the company; test the process once and the configuration per system.
- Decide the layers. Application always; database and operating system where direct access could alter financial records; scheduler and interfaces where you rely on them for completeness.
- Place the third parties. Obtain the SOC 1 Type 2 report, check its period and subservice organizations, map the complementary user entity controls (CUECs) to your tests, get a bridge letter to year-end.
- Fix the period. The fiscal year for ICFR, tested at interim and rolled forward; program development controls only for systems implemented or materially upgraded in the year.
Table 1 shows the result for MidState Beverage, the three-state distributor used as the running example on this site: a 2013-vintage ERP with a route-accounting module, spreadsheets at 12 depots, an outsourced payroll SaaS, and two acquired distributors not yet on the ERP. Its fiscal year ends June 30. The six-person internal audit function tested FY26 ITGCs (July 1, 2025 to June 30, 2026) in July and August 2026 under the ICFR support engagement on its FY27 plan.
| System | Financial relevance | Layers in scope | ITGC processes tested | Coverage decision |
|---|---|---|---|---|
| ERP (general ledger, AP, inventory, route accounting) | All significant accounts; posting maps, three-way match, settlement thresholds; 14 key reports | Application, SQL Server, Windows Server, Active Directory | Access, change, operations; no implementation in FY26 | Full testing at the reliance tier; the external auditor relies on the access and change work |
| Handheld route settlement system and sync middleware | About 37,400 settlements and the deposit listings a year | Application, sync interface job, device administration accounts | Access, change, operations (sync-failure monitoring) | Full testing; sync failures already a finding in report FY27-01 |
| Payroll SaaS | Payroll expense and accruals, about 1,400 employees | Vendor stack via SOC 1 Type 2 (calendar 2025) plus bridge letter to June 30, 2026 | User administration and pay-rule changes; seven CUECs | SOC reliance plus direct CUEC tests |
| Depot spreadsheets (12 depots) | Deposit listings re-keyed at 7 depots; count sheets | Not an ITGC item | End-user computing controls | Tested in the route cash and inventory engagements |
| Legacy systems at the two acquired distributors | Below the ICFR coverage threshold; monthly journal upload | Out of scope for FY26 | Journal upload and IPE controls at corporate | Monitor; scope in for the FY27 migration |
Three scoping errors recur. Scoping by IT’s view of importance: the scheduler that runs the nightly posting is rarely on IT’s critical list but is on yours. Assuming a shared process behaves the same at every layer: MidState’s application provisioning was ticketed and approved, while local administrator accounts on the database server were created with no ticket, unnoticed because nobody had asked for that population. Ignoring period coverage: an ITGC fixed in March cannot support reliance on an automated control for January and February.
The ITGC test matrix: 24 controls with populations, samples, and evidence
Table 3 rests on one discipline: every test names the population, its source, the sample, and the evidence that the control operated rather than that a document exists. Populations come from the system, not from the people who operate the control: terminations from HR, changes from the deployment or transport log, privileged users from a role extract you watched being generated. Each extract is itself information produced by the entity, so record the system, report name, parameters, run date, record count, and who ran it, and keep a screenshot of the parameter screen; the audit evidence guide sets the standard. GIAS Standard 13.4 requires named criteria: the company’s IT policies and the RCM control descriptions, with ISO/IEC 27001:2022 Annex A used only where policy is silent.
Sample sizes follow the frequency ladder in Table 2, which mirrors the site’s 25/40/60 sampling guide. Use the higher tier when the external auditor will rely on your work, when the control failed last year, or when the population contains privileged or financially sensitive activity. Select randomly and keep the seed; the free mySampler tool records the parameters. Manual controls such as the access review are tested on occurrences, so a quarterly review yields a population of four and a sample of two. Table 3 then reads as a work program: the work program guide turns its rows into steps, the workpaper example shows the evidence layout, the free RCM Workbench holds the control descriptions, and the exceptions each row typically produces are in Table 8.
| Control frequency | Population in a year | Sample, lower risk | Sample, higher risk or reliance | ITGC examples |
|---|---|---|---|---|
| Annual | 1 | 1 | 1 | Restore test; privileged access recertification; post-implementation review |
| Quarterly | 4 | 2 | 2 | User access review; bridge letter review |
| Monthly | 12 | 2 | 3 to 5 | Patch cycle approval; batch failure review |
| Weekly | 52 | 5 | 10 to 15 | Backup verification; change advisory board |
| Daily | About 250 business days | 20 | 30 to 40 | Backup completion; interface control totals; job monitoring |
| Multiple times a day or recurring | Hundreds to thousands | 25 | 40 to 60 | Provisioning; terminations; change tickets; incidents |
| # | Domain | Control objective | Control example | Test (population and sample) | Evidence to retain |
|---|---|---|---|---|---|
| A1 | Access | Access is authorized before it is granted | Manager and application owner approve; service desk provisions only the requested role | Population: accounts created and role changes from the user master, reconciled to tickets. Sample 25; 40 for reliance | Extract with parameters; ticket; dated approval; role assigned |
| A2 | Access | Access is removed on leaving | Deactivation within one business day of HR termination; contractor end dates | Population: all leavers from HR, never IT. Compare 100 percent to account status and last logon per layer | HR extract; account listing with last logon; comparison |
| A3 | Access | Access is adjusted on transfer | Role set reviewed on department change | Population: HR transfers. Sample 25; compare roles before and after | Transfer list; role history; approval |
| A4 | Access | Access stays appropriate | Quarterly review by business owners; removals within ten business days | Population: four reviews; sample 2. Reconcile the listing to an independent extract at the review date; check reviewers, decisions, removals | Review workbook; extract with count; sign-offs; removal tickets |
| A5 | Access | Privileged access is restricted | Admin roles limited to named IT staff; separate admin accounts | 100 percent of privileged users per layer (application admin, sysadmin, local administrators, Domain Admins) matched to role and approval | Role extracts per layer; job descriptions; approvals |
| A6 | Access | Shared and service accounts are controlled | Inventory with owners; vaulted passwords; no interactive service logon | 100 percent of generic and service accounts per layer; inspect vault and check-out log | Inventory; vault configuration; check-out log; last logon |
| A7 | Access | Authentication enforces policy | Length, lockout, MFA per policy; MFA for remote and privileged access | Inspect live configuration per layer at interim and year-end against policy and NIST SP 800-63B-4 | Screenshots with system, environment, date, user |
| A8 | Access | No unrecorded direct data changes | Database write access limited to the DBA; auditing on; direct changes ticketed and reviewed | 100 percent of database write accounts; logged direct changes, sample 25 to tickets | Database roles; audit log; review evidence; tickets |
| A9 | Access | Conflicting duties are prevented or mitigated | SoD ruleset in provisioning and review; conflicts mitigated | Run the conflict analysis; 100 percent of conflicts; verify each mitigation operated | Ruleset; conflict report; mitigation evidence |
| A10 | Access | Physical server access is restricted | Badge list for the server room reviewed quarterly | 100 percent of badge holders against the list; inspect one review | Badge extract; authorized list; review |
| C1 | Change | Changes are authorized before deployment | IT manager and, for financial changes, finance system owner approve first | Population: deployments from the deployment or transport log, reconciled both ways to tickets. Sample 25; 40 for reliance | Log extract; ticket; dated approval |
| C2 | Change | Changes are tested and accepted | Test results retained; business sign-off before deployment | Same sample; compare test and sign-off dates to the deployment date | Test results; dated sign-off |
| C3 | Change | Developers cannot deploy their own work | Release role held by a release manager; branch protection blocks self-approval | 100 percent of deployment rights against the developer list; inspect branch protection and the bypass list | Role extract; developer list; repository settings |
| C4 | Change | Emergency changes are controlled after the fact | Verbal approval, documented approval within two business days, post-implementation review | Population: emergency-flagged changes; 100 percent if under 40, otherwise 25 | Tickets; approval timestamps; review notes |
| C5 | Change | The change record is complete | Deployments logged automatically; configuration audit on | Observe log generation; reconcile log to tickets both ways (25 each); confirm production is closed to direct configuration | Log extract; reconciliation; configuration audit setting |
| C6 | Change | Vendor patches are tested first | Patches to the test environment first with regression evidence | Population: vendor patches; sample 25, or 100 percent if fewer | Patch notes; test evidence; approval |
| D1 | Development | New systems are approved and built to requirements | Steering committee approval; process owner signs requirements and design | Population: implementations and major upgrades; 100 percent | Charter; sign-offs; design documents |
| D2 | Development | Migrated data is complete and accurate | Counts, control totals, and balance reconciliation signed by finance before go-live | Per migration: re-foot, trace differences, tie opening balances to the legacy trial balance | Conversion reconciliations; sign-offs; open items |
| D3 | Development | Go-live is a decision | Go-live approval against test criteria; post-implementation review within 90 days | 100 percent; compare approval dates to go-live | Go-live approval; test report; review |
| O1 | Operations | Critical jobs complete or are fixed | Critical job list; failures alert to the service desk and are fixed the same day | Build the critical list; population: failures from the scheduler log; 100 percent if under 40, otherwise 25 | Scheduler extract; tickets; rerun evidence |
| O2 | Operations | Backups run and failures are resolved | Daily backups of in-scope databases; failures ticketed | Population: daily backup jobs; sample 25 days, 40 for reliance; all failures traced | Backup console report; tickets; retention setting |
| O3 | Operations | Data can be restored | Annual restore test per database with timing | 100 percent; inspect scope, date, duration, outcome | Restore record; screenshots |
| O4 | Operations | Incidents affecting data are assessed | Priority 1 and 2 incidents with root cause and a finance data assessment | Population: incidents on in-scope systems; 100 percent of priority 1 and 2 | Incident tickets; root cause; finance sign-off |
| O5 | Operations | Interfaces are complete | Control totals reconciled per run; rejects worked within two days | Population: interface runs; sample 25; inspect error queue aging | Control total reports; error queue extract |
Evidence request list for an ITGC review
The evidence request list decides whether fieldwork takes three weeks or eight. Vague requests (“user listing for the ERP”) produce vague evidence; precise requests name the system, environment, period, fields, and extraction method, and ask for a screenshot of the parameter screen at extraction. Ask for populations first and samples second. Table 4 is the list MidState’s team issued on July 20, 2026; the last column is the ten-minute completeness check that catches most bad extracts before a sample is drawn. Pair it with the walkthrough documentation template for the design walkthrough that precedes testing.
| # | Request | Format and parameters | What you check first |
|---|---|---|---|
| 1 | IT policies (access, change, backup, incidents) with version dates | Current and prior versions in force during the period | Approval date and owner; matches the walkthrough |
| 2 | Application inventory and architecture diagram | Diagram plus the console server list | Each in-scope application shows its database and operating system |
| 3 | User listings per application and for the directory, with roles or groups, status, creation date, last logon | Exports at one stated date; parameter screenshots; counts | Counts agree to screen; generic and service accounts included; Domain Admins visible |
| 4 | Database and operating system privileged accounts | Export per server: sysadmin members, local administrators | Service and vendor accounts have owners |
| 5 | HR hires, transfers, terminations, contractor end dates | HR export with dates and worker type | Contractors present; termination dates populated |
| 6 | Access request tickets and workflow configuration; user access review packages | Ticket export with requester, approver, dates, role; review listings, sign-offs, removal tickets | Ticket count against new accounts; review listing count against the user listing at the review date |
| 7 | Password, lockout, MFA configuration per layer | Live screenshots with system, environment, date, user | Production, not test |
| 8 | Vault configuration, check-out log, shared account inventory | Vault export; inventory with owners | Every shared account from items 3 and 4 is vaulted |
| 9 | Database audit log of direct changes, with monthly review evidence | Export for the period; sign-offs | Auditing on all period; no date gaps |
| 10 | SoD ruleset and latest conflict analysis | Ruleset; report with run date | Covers in-scope processes; mitigation owners named |
| 11 | Production deployment or transport log; change ticket export | Log export with date, object, deployer, ticket, parameter screenshot; ticket export with type, approver, dates, status | Counts; deployer populated; entries without tickets; reconciles both ways |
| 12 | Deployment or transport rights; branch protection; configuration audit setting and log | Role extract; repository screenshots; setting screenshot; log export | Names against the developer list; whether production accepts direct configuration changes |
| 13 | Project documentation for implementations or upgrades | Charter, approvals, test completion, conversion reconciliations, go-live approval | Go-live date against approval dates |
| 14 | Critical job list and scheduler failure log | Export with job, date, status, ticket | Interfaces and posting runs on the list |
| 15 | Backup schedule, job log, retention, storage location, restore test records | Console report; storage diagram; restore record with date, scope, duration, outcome | Off-site or immutable copy; failures ticketed; a database was restored, not a file |
| 16 | Incident and problem tickets | Export with priority, dates, root cause, data impact | Priority 1 and 2 during close |
| 17 | SOC 1 Type 2 reports, bridge letters, CUEC mapping | Reports covering the period; review memo | Period, carve-outs, exceptions, whether anyone read it |
Interviewing IT owners: 20 questions and what a good answer sounds like
Interview the people who do the work, not the CIO: the application administrator, the DBA, the infrastructure lead, the service desk lead, and whoever moves changes to production. Run every interview as a walkthrough with screen sharing and ask them to show rather than tell; a good IT owner opens the console and the answer appears with a date on it. GIAS Standard 14.1 requires information that is sufficient, reliable, relevant, and useful, and inquiry alone rarely is, so every “yes” has to be followed by the extract or screenshot that proves it. The IAM audit guide extends questions 3 to 9 into a full identity and access engagement.
| # | Question | What a good answer sounds like | Red flag |
|---|---|---|---|
| 1 | Which systems hold or transform financial data, and where does each run? | A named list with hosting, database, and owner, matching the diagram | Cannot name the database |
| 2 | Who administers the application, database, server, and directory? | Named people per layer; DBA and application administrator differ | One person “does everything”; a shared admin account |
| 3 | Walk me through a new hire’s ERP access, from HR to first login. | HR trigger, two approvals, service desk provisions, dates in the ticket | “The manager emails me”; access before approval |
| 4 | How do you learn someone has left, and how fast is access removed? | Same-day HR notice, a 24-hour standard, a monthly leaver reconciliation | “HR tells us eventually”; contractors left to managers |
| 5 | Show me the last user access review. | System-generated listing with a date; process owners reviewing; removals ticketed | Nothing removed; names without roles; self-review |
| 6 | Who holds administrator rights at each layer, and why? | Short list with a reason each; no developers; separate admin accounts | Developers with production admin; service desk in Domain Admins |
| 7 | Which accounts are shared, and how are passwords controlled? | Inventory with owners; vault with check-out logging; no interactive service logons | Password on the whiteboard; vendor login shared |
| 8 | Can anyone change data directly in the database, and would you know? | Only the DBA, by ticket, with auditing on and a monthly review | “We fix data in SQL,” with no log |
| 9 | What are the password and MFA settings? Show me. | Shown live; MFA for remote and privileged access; aligned to NIST SP 800-63B-4 | Cannot be shown; a rotation rule the ERP does not enforce |
| 10 | Show me the record of everything moved to production this year. | A system-produced deployment log reconciled to tickets | “Every change has a ticket,” with no system log |
| 11 | Who can move a change into production? Can a developer? | A named release role held by non-developers; branch protection on | Developers deploy their own work |
| 12 | How is a change tested, and who says it is ready? | Test results and business sign-off dated before deployment | “The developer tests it”; sign-off after go-live |
| 13 | How do emergency changes work, and how many this year? | Defined path, approval within a window, post-implementation review, a count in the low tens | A third of changes flagged emergency; approvals weeks later |
| 14 | Who can change production configuration without a ticket? | Same process as code; configuration audit log on and reviewed | “Configuration isn’t a change” |
| 15 | Which jobs would cause a financial problem if they failed, and how would you know? | Named critical list; alerts to a monitored queue; failures ticketed the same day | Alerts to an unread mailbox; failures found by the depots |
| 16 | When did you last restore a database, and how long did it take? | A dated restore per system within 12 months, with duration | Never restored |
| 17 | Where are the backups, and could ransomware reach them? | Off-site or immutable copy under separate credentials | Same server or credentials as production |
| 18 | What incidents affected the ERP, and did any affect data? | Incident list with severity, root cause, and a finance data assessment | Outage during close with no assessment |
| 19 | Which vendors run systems for you, and what assurance do you get? | SOC 1 Type 2 read; exceptions and CUECs mapped; bridge letters | “They’re a big company”; report never opened |
| 20 | What changed since last year, and what changes next year? | Upgrades, migrations, integrations, staff changes, with dates | A migration finance heard about from the auditor |
Worked example: testing change management on 214 changes
MidState’s risk and control matrix describes the ERP change control as follows: changes to code, reports, and configuration are requested in the service desk tool, approved by the IT manager and, where they affect financial processing, by the finance system owner, tested with business sign-off, and moved to production by the release manager. Emergency changes may be deployed on the IT manager’s verbal approval and must receive documented approval and a post-implementation review within two business days. The external auditor planned to rely on the work, so the reliance tier applied; the design walkthrough came first, on July 22, 2026 (the design versus operating effectiveness guide explains why that order matters).
Population and sample
The population came from the ERP’s deployment log, a system table the DBA exported on August 3, 2026 with an auditor watching the parameters (environment PROD, July 1, 2025 to June 30, 2026): 214 production deployments. The team reconciled the log to the service desk both ways (Table 5), then drew a random sample of 25 with mySampler and recorded the seed; Table 6 shows the results. The sample held 18 standard changes, 5 vendor patches, and 2 emergency changes. Six attributes were tested: (A) request documented with justification; (B) approval before deployment, or within two business days for emergency changes; (C) test evidence and business sign-off before deployment; (D) deployed by the release role, not the developer; (E) log date agrees with the ticket; (F) finance system owner sign-off for changes affecting financial processing.
| Population source | Count | Reconciliation step | Result |
|---|---|---|---|
| ERP deployment log, production, FY26 | 214 deployments | Each deployment matched to a ticket by the reference in the log | 214 matched to 211 tickets; one quarterly vendor patch ticket covered four deployments |
| Service desk change tickets closed as deployed in FY26 | 211 tickets | Reverse check: every deployed ticket matched to a log entry | 211 of 211 matched; no ticket without a deployment |
| Composition by change type | 152 standard, 45 vendor patch, 17 emergency | Emergency flag in the log validated against the ticket type | 17 emergency deployments, 8 percent of the population |
| Attribute | Items tested | No deviation | Deviation | Note |
|---|---|---|---|---|
| A. Request documented with justification | 25 | 25 | 0 | Two vendor patch tickets carried the vendor’s release notes as justification, accepted |
| B. Approval before deployment, or within two business days for emergency changes | 25 | 24 | 1 | CHG-2026-0141: documented approval 11 business days after deployment |
| C. Test evidence and business sign-off before deployment | 25 | 24 | 1 | CHG-2026-0141: developer’s own test notes only |
| D. Deployed by the release role | 25 | 24 | 1 | CHG-2026-0141: deployed by the developer |
| E. Log date agrees with the ticket | 25 | 25 | 0 | None |
| F. Finance system owner sign-off (financial-processing changes only) | 9 | 8 | 1 | CHG-2026-0141: no finance sign-off |
The exception
CHG-2026-0141 was an emergency change deployed at 7:40 p.m. on Thursday, February 12, 2026, to correct a month-end posting error in the GL posting map for inventory adjustment reason codes. The developer who wrote the fix also deployed it: the release manager was on leave, and the developer had been granted the release role on February 9 “for coverage”; it was still assigned on April 30, eleven weeks later. The IT manager approved verbally that evening; the documented approval is dated February 27, eleven business days later against a two-day requirement. The only test evidence was the developer’s notes; there was no finance sign-off and no post-implementation review. The change touched an automated control the inventory process relies on (reason code to GL account mapping), which also feeds the monthly inventory roll-forward, a key report.
How the exception was evaluated
Is it a deviation or a documentation lapse? A deviation: independent approval within the window and independent testing did not happen; the evidence was not merely mislaid. One deviation in a sample of 25 means the planned conclusion (zero deviations, 90 percent confidence, 10 percent tolerable rate) is no longer supported; the upper deviation limit rises to roughly 15 percent, and the sampling guide’s honest options are to investigate, to expand to a size planned for one deviation only if the investigation shows an isolated error, or to conclude that the control failed. The team investigated first, because the deviation sat in an identifiable subpopulation (the emergency path) and coincided with an access condition (a developer holding deployment rights for eleven weeks), both testable directly.
Testing was extended toward the risk rather than by adding a few random items. All 17 emergency changes were examined: 14 had documented approval within two business days and 3 were late (11, 6, and 4 business days); 16 had test evidence and business sign-off; only CHG-2026-0141 was deployed by its developer; 12 had a post-implementation review. Every deployment under the developer’s account between February 9 and April 30 was pulled from the log: six, of which five were standard changes approved and tested beforehand. The random sample of standard and vendor changes was extended from 23 to 40, the reliance-tier size for that stratum, with no further deviations. So the standard path operated, the emergency path did not operate within its own rules, and developer-deployer segregation lapsed for eleven weeks and was used outside the process once.
Because an untested change had touched an automated control, benchmarking for that control was lost from February 12 onward, so the dependent control was retested directly: the posting map configuration export as of August 3, 2026 was compared to the approved design (all nine reason-code mappings agreed), and one adjustment per reason code posted after February 12 was traced to the GL account it reached (nine postings, all correct). The monthly inventory subledger-to-GL reconciliation for February through June showed no unexplained differences above the $25,000 investigation threshold. No misstatement was identified. The decision table in the next section then gave a deficiency, not a significant deficiency: the dependent control had not failed, a detective control with adequate precision operated, and the condition was confined to 17 of 214 changes and one access assignment. The internal audit report rated it Medium with two action items and a 90-day due date, because the same pattern in a year with a real posting error would have been a significant deficiency, and because the release-role assignment was an access failure in its own right. Written to the 5 Cs structure, the finding read as follows.
Condition. Of 17 emergency changes deployed to the ERP in FY26, 3 (18 percent) received documented approval 4 to 11 business days after deployment and 5 had no post-implementation review. One of the three, CHG-2026-0141 (February 12, 2026), altered the GL posting map for inventory adjustments, was deployed by the developer who wrote it, and carried no independent test evidence or finance sign-off. The developer held the release role from February 9 to April 30, 2026. Standard and vendor changes (40 of 40 tested) complied.
Criteria. IT Change Management Policy sections 6.2 (documented approval and post-implementation review within two business days of an emergency deployment) and 4.1 (developers do not deploy their own changes); ICFR control CM-03 (finance system owner sign-off for changes affecting financial processing).
Cause. The workflow does not enforce the two-day window or escalate; the release role was assigned for leave coverage with no end date and no review; no list of financially relevant objects triggers the finance sign-off.
Consequence. For eleven weeks a developer could change ERP logic without independent approval or testing, and did so once for a control that determines which GL accounts inventory adjustments reach. Direct retesting and the February to June inventory reconciliations found no misstatement; the exposure was to the reliability of an automated control and a key report. Evaluated as a deficiency for ICFR purposes.
Corrective action. (1) The workflow will require documented approval and a post-implementation review before an emergency ticket can close and will escalate after two business days; the release role will be limited to the release manager and IT manager, with any temporary assignment carrying an end date and a ticket (owner: IT manager, due November 30, 2026). (2) Finance and IT will maintain a list of financially relevant ERP objects requiring finance sign-off, and the finance system owner will review the monthly deployment log against tickets (owner: controller, due November 30, 2026). Internal audit will validate both in Q3 FY27.
Evaluating ITGC deficiencies and reporting them
ITGC deficiencies do not cause misstatements by themselves; they remove the assurance other controls provide, so they are evaluated by tracing them to the controls that depend on them. AS 2201.63 makes severity a function of the reasonable possibility that controls will fail to prevent or detect a misstatement and of the magnitude of the potential misstatement; the SEC’s 2007 interpretive guidance for management (Release 33-8810) uses the same two dimensions. For an ITGC the question becomes: which automated controls, key reports, SoD enforcements, and data does it protect, did any actually fail, and is there a compensating control precise enough to catch the resulting error. The control deficiency evaluation guide covers the general method and aggregation; Table 7 is the ITGC-specific sequence, and the external auditor will re-perform it under SOX 404.
| Step | Question | If yes | If no |
|---|---|---|---|
| 1 | Did the deficient ITGC actually touch a financially relevant object, user, or period, or was the exposure unused? | Continue with the specific objects, users, dates, and accounts written down | Exposure-only deficiency; report it with the exposure period |
| 2 | Did a dependent automated control, key report, or SoD enforcement fail? Test directly; benchmarking is gone once change control lapsed | Evaluate the dependent control’s failure on its own magnitude, with the ITGC as root cause | The ITGC deficiency stands alone; go to step 3 |
| 3 | Is there a compensating control precise enough for the magnitude at issue (thresholded reconciliation, independent log review, leaver reconciliation)? | Likelihood reduced; document the precision and test that it operated | Likelihood is what the gap implies; magnitude is the volume through the system |
| 4 | Is it pervasive: several domains, several systems, most of the period, no monitoring? | Consider significant deficiency or material weakness; aggregate with other ITGC deficiencies on the system | Isolated; deficiency or significant deficiency by magnitude |
| 5 | Did management find it first? | Positive control environment factor; record who and when | Add “monitoring did not detect” to the cause; consider the entity-level implication |
| 6 | Remediated, and has the fix operated long enough to test? | Year-end conclusion may differ; test the remediated control (one occurrence for quarterly, 25 items for recurring) | The deficiency exists at year-end; the plan goes in the management response |
Rating the internal audit finding is separate from the ICFR classification, and the report should reconcile the two so nobody reads “Medium” as “deficiency” or “High” as “material weakness”; the finding severity ratings guide sets out a scale that works. Two patterns produce significant deficiencies more than any other: developers with unrestricted production access for most of the year and no monitoring of what they changed, and change populations that cannot be shown to be complete. Both destroy benchmarking and IPE reliance across the whole system. The committee needs to hear that in business terms.
What we found. For eleven weeks this spring, one developer could change how the ERP posts inventory adjustments without anyone else approving or testing the change, and used that ability once to fix a month-end error. Three of the year’s 17 emergency changes were approved later than policy allows.
What it means for the numbers. We retested the affected posting logic and the February to June inventory reconciliations and found no error. The exposure was to the reliability of a control we and the external auditor rely on, not to a known misstatement; we classify it as a deficiency, not a significant deficiency.
What changes. Management is closing the workflow gap and restricting who can deploy changes by November 30; internal audit will validate both actions in the third quarter.
Common ITGC findings, root causes, and remediation
The same dozen findings account for most ITGC reports. The remediation column in Table 8 lists what has held up on re-validation: a fix that depends on people remembering fails within two quarters, while one that changes a system setting or a workflow gate stays fixed. Severity assumes the condition is isolated; combine it with Table 7 and, for the access items, the user access review guide and the ERP SoD analysis guide before rating. Track every item in the issue log with the exposure period recorded; the exposure period, not the fix date, is what the year-end evaluation turns on.
| Finding | Typical root cause | Remediation that holds | Usual severity when isolated |
|---|---|---|---|
| Terminated employees or contractors with active accounts | Manual HR-to-IT notification; contractors outside HR | Automated HR feed; weekly leaver reconciliation owned by IT security; contractor end dates in HR | Deficiency; significant if logons after termination or privileged accounts |
| Developers with production deployment or admin rights | Small team; leave coverage; roles never removed | Separate release role; break-glass with logging and next-day review; quarterly privileged review | Deficiency to significant deficiency by activity in the period |
| User access review incomplete or rubber-stamped | Reviewer builds the list; roles not shown; no consequence for lateness | System-generated listing with roles and last logon; process owners review; removals ticketed | Deficiency; significant if it is the only detective access control |
| Shared administrator and vendor support accounts | Legacy practice; vendor requirements; no vault | Vault with check-out and session recording; named accounts; vendor access enabled per ticket | Deficiency; higher where the account changed financial data |
| Changes deployed without documented approval or testing | Workflow allows closure without attachments; emergency path abused | Approval and test fields as workflow gates; monthly log-to-ticket review outside development | Deficiency; significant if financially relevant logic changed |
| Incomplete change population (deployments without tickets) | Configuration treated as “not a change”; hotfix scripts; open production | Configuration audit on; every production change ticketed; monthly reconciliation | Significant deficiency where it prevents reliance on automated controls |
| Direct database changes not logged or reviewed | Auditing off for performance; DBA fixes data on request | Auditing on for financial tables; fixes by ticket with finance approval; monthly log review | Deficiency to significant deficiency |
| Authentication weaker than policy; no MFA for administrators or remote access | Legacy application limits; policy written for another system | Enforce at the directory; MFA for VPN and administrators; policy per NIST SP 800-63B-4 (length, blocklist, no forced rotation) | Deficiency for ICFR; higher for cybersecurity |
| Failed jobs and interface errors not investigated | Unmonitored alert mailbox; no critical list; no tickets | Named critical list; alerts into the service desk; daily check; error queue aging to finance | Deficiency; significant if completeness depended on the job |
| Backups never restored; reachable with production credentials | Restore tests seen as disruptive; storage design | Annual full restore per database with timing; immutable or off-site copy, separate credentials | Deficiency for ICFR; high operational risk |
| SOC 1 report not read; CUECs unmapped; period gap | Vendor management in procurement; no report owner | Named owner; annual SOC review memo: exceptions, CUECs, subservice organizations, bridge letter | Deficiency; higher if the report carried access or change exceptions |
| Data migration not reconciled at go-live | Project pressure; conversion by the integrator | Counts, control totals, balance reconciliation signed by finance before go-live; open items log | Significant deficiency where opening balances are unproven |
Mistakes non-IT auditors make in ITGC reviews
The findings above are management’s failures; Table 9 lists the auditor’s. Each has appeared in an external quality assessment or an external auditor’s reliance review, and the common thread is accepting what the control operator hands you as if it were independent evidence.
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Accepting the ticket list as the change population | Sample drawn from the service desk export; every item approved | Changes made outside the process never have tickets | Population from the deployment log, reconciled both ways to tickets |
| Taking IT’s terminated-user list as the population | IT provides “accounts disabled this year” | Proves only that disabled accounts were disabled | Population from HR, including contractors, compared to active accounts and last logon |
| Testing the application layer only | Database and server untouched | A DBA with write access bypasses every application control | Repeat access tests per layer; 100 percent of privileged accounts |
| Screenshots without context | A policy screen with no system, environment, date, or user | Cannot be tied to production or the period | Capture system, environment, date, user; observe generation |
| Rating without tracing to dependent controls | “Unapproved change” rated High with no analysis of what changed | Overstatement costs credibility; understatement misleads the committee | Identify the object, retest the dependent control, then rate |
| Walkthrough in place of operating tests | Interview notes and a flowchart; no samples; configuration checked once | Design says what should happen; the log says what did; settings drift | Follow with the sampled tests in Table 3; test at interim and roll forward |
| Findings in IT vocabulary | “SoD conflict between DEV and PRD transport roles” | The committee cannot judge the exposure | State the object, the account, the exposure period, and the compensating control |
Adapting the approach: SaaS, cloud, pipelines, small teams, acquisitions
SaaS systems and SOC 1 reliance
When the ERP or payroll runs in the vendor’s cloud, the ITGCs still exist; they operate at the vendor, and the SOC 1 Type 2 report is your evidence for them. Read it in a fixed order: the opinion and period; the boundary of the system description (is your module inside it); the subservice organizations and whether they are carved out, in which case you need their reports too; the exceptions and management’s responses; and the complementary user entity controls. Map every CUEC to a control on your side and test it, because that is where SaaS deficiencies live: user administration, approval of configuration changes such as pay rules and tax tables, and review of the vendor’s exception reports. Bridge the gap to year-end with a bridge letter and, beyond about three months, your own inquiry. MidState’s payroll SOC 1 carried seven CUECs; all 11 pay-rule changes in FY26 were approved by the payroll manager, the evidence the vendor’s opinion assumed. The Third-Party Topical Requirement guide covers what the IIA expects of that assessment from 15 September 2026.
Cloud infrastructure and pipelines
For infrastructure and platform services the shared responsibility model leaves identity, configuration, and change on your side, so the ITGCs apply to the cloud console: who holds owner or root roles, whether MFA is enforced on them, whether console changes are logged, and whether infrastructure-as-code passes through the same approval as application code (the cloud audit guide covers the console-level tests). In a pipeline-based environment the change population is the merge and deployment history, approval evidence is the pull request review, the segregation control is branch protection plus the short list of accounts allowed to bypass it, and test evidence is the pipeline’s automated results plus user acceptance for financial logic. Test the pipeline’s own configuration and who can change it, because a change to the pipeline is a change to the control. Hundreds of deployments a month push you to the 25/40/60 tier and toward first-line continuous monitoring with internal audit testing the monitoring; the continuous auditing versus continuous monitoring guide explains the split. AI-assisted code changes nothing: approval, independent test, and deployment record are still what you test.
Small IT teams
A three-person IT department cannot always separate developer from deployer, and pretending otherwise produces a finding every year with no remedy. Accept a compensating control if it is real: a monthly review of the deployment log against tickets by the finance system owner, with evidence that questions were asked and answered, or configuration change logging with a documented review. Name it in the RCM so it is tested as a control, and make sure the reviewer can read the log; a review the reviewer cannot understand is not a control. The segregation of duties guide covers documenting and testing compensating controls.
Acquisitions, legacy systems, and the cybersecurity overlap
MidState’s two acquired distributors run legacy systems with little formal change control and administrator rights held by the former owners’ staff. The FY26 decision to leave them out rested on materiality and on the journal upload controls at corporate, documented with a date and a threshold. When their migration to the ERP begins, program development controls come into scope: project approval, requirements sign-off for the route-accounting configuration, and above all the data conversion reconciliation of customer balances, inventory, and open settlements; plan that year’s work around rows D1 to D3. Finally, access and change controls are also the first half of any cybersecurity program, so an ITGC review often surfaces conditions (MFA gaps, shared administrator accounts, backups reachable from production) that matter more for ransomware resilience than for the financial statements; report both consequences and rate the operational risk separately from the ICFR classification. The Risk Library catalogs the related technology risks, and the Topics hub lists every guide on this site by area.
Related guides
- SOX ITGC scoping — which systems and layers are in
- ITGCs vs application controls — the warranty on every automated control
- User access review — testing a recertification end to end
- Privileged access audit — the 100 percent test at every layer
- IAM audit — the full identity and access engagement
- IPE testing — validating the reports ITGCs protect
- ERP SoD analysis — the analysis behind row A9
- Control deficiency evaluation — the method behind Table 7
- Audit sample sizes: 25, 40, 60 — the ladder and the one-deviation rule
- Tools — mySampler, the RCM Workbench, and other free tools
Leave a Reply