What Are IT General Controls (ITGCs)?

IT general controls are the controls over your technology environment that make everything running inside it reliable. They are not accounting controls. They are the controls that answer a prior question: can an auditor trust that this system computed what it says it computed, that only authorized people touched it, and that nobody quietly changed the logic mid-year?

The term has a regulatory anchor. In its 2007 interpretive guidance for management, the SEC identified the relevant ITGC areas as “program development, program changes, computer operations, and access to programs and data.” That same guidance sets an important boundary: IT general controls alone “ordinarily do not adequately address financial reporting risks.” They earn their place in a SOX program only because other controls depend on them.

The dependency chain is what makes ITGCs load-bearing. An automated three-way match, a system-enforced approval threshold, an aging report feeding a reserve estimate — each is only as good as the environment underneath it. If a developer can push unreviewed code to production, the automated control you tested in March may not be the control that ran in November.

The COSO 2013 framework encodes the same idea in Principle 11, which requires organizations to select and develop general control activities over technology, covering technology infrastructure, security management, and technology acquisition, development, and maintenance. Our primer on compliance controls and how to use them effectively covers the surrounding vocabulary.

What Are the Four ITGC Domains?

Most SOX programs organize ITGCs into the four domains the SEC named. Scope them per in-scope system and per layer — application, database, operating system, and any supporting tooling — because auditors will ask about each layer separately.

Notice that every evidence column is a record with a date, a name, and an outcome. “We do this” is not evidence. A control that operates but leaves no trace fails testing exactly like a control that never operated.

How Do ITGCs Fit Into SOX 404?

Section 404 of the Sarbanes-Oxley Act splits into two obligations. Under 404(a), management must assess and report on the effectiveness of internal control over financial reporting (ICFR) annually. Under 404(b), the external auditor must issue its own opinion on ICFR — but only for accelerated and large accelerated filers. After the SEC’s March 2020 amendments to the filer definitions, smaller reporting companies with less than $100 million in annual revenue are excluded from accelerated filer status and therefore from the 404(b) attestation, though 404(a) still applies to them.

ICFR itself is defined in Exchange Act Rule 13a-15(f) as a process providing reasonable assurance regarding the reliability of financial reporting. ITGCs are not named there — they arrive through the risk assessment. Auditors following PCAOB Auditing Standard 2201 use a top-down approach, starting at the financial statement level and working down to significant accounts and relevant assertions. AS 2201 is explicit that “the identification of risks and controls within IT is not a separate evaluation. Instead, it is an integral part of the top-down approach.”

That framing has a practical consequence. Your ITGC scope is derived, not chosen. It follows the systems that support in-scope processes and the automated controls and reports you are relying on. AS 2201 also notes that an automated control is generally expected to be lower risk when relevant IT general controls are effective — which is why strong ITGCs let you test an automated control once rather than sampling 25 manual executions.

One 2026 scheduling note: a package of PCAOB amendments adopted in May 2024, including conforming amendments to AS 2201 alongside the new QC 1000 quality control standard, was postponed to take effect December 15, 2026. The substantive ITGC expectations in AS 2201 are unchanged.

What ITGC Deficiencies Do Auditors Find Most Often?

The failure patterns are remarkably consistent, and they are documented in public filings and inspection reports rather than folklore.

Access management leads by a wide margin. In KPMG’s analysis of SEC filings, systems-related issues appeared in 37% of the 238 companies that disclosed material weaknesses in fiscal 2025, up from 30% the prior year, with the most frequently cited issue being “managing user access, including inappropriate access rights, failure to timely manage terminated users, and inadequate access reviews.” KPMG’s separate analysis of IT controls and ICFR, citing Ideagen Audit Analytics data, found that IT issues became the top issue cited in adverse ICFR opinions for the first time. If your access review is a spreadsheet emailed to managers, read our walkthrough of the user access review process step by step.

Population completeness is the quiet killer. Auditors do not just sample your changes — they test whether the list of changes was complete. In its 2024 inspection of KPMG LLP, the PCAOB found the firm “did not test or otherwise verify the completeness of the population of changes” from which its sample was selected, and separately failed to evaluate the specific review procedures performed in a user access control. Those ITGC gaps then undermined the audit of revenue and deferred revenue.

System-generated reports get skipped. The PCAOB’s April 2024 Spotlight on auditor use of data and reports found that roughly 17% of inspection comment forms in both the 2021 and 2022 cycles involved insufficient testing of the accuracy and completeness of information produced by the company. Across all firms inspected in 2024, 39% of audits reviewed had Part I.A deficiencies, down from 46% in 2023, with reliance on system-generated reports called out as a recurring theme.

Unidentified systems. Companies routinely miss a database, a middleware job, or a SaaS tool feeding the general ledger because scoping was done once and never revisited.

When Does an ITGC Gap Become a Material Weakness?

AS 2201 defines a material weakness as a deficiency, or combination of deficiencies, such that there is a reasonable possibility a material misstatement of the annual or interim financial statements will not be prevented or detected on a timely basis. A significant deficiency is less severe but still merits the attention of those charged with oversight.

ITGC deficiencies are evaluated differently from process-level ones because of leverage. A single broken change management control does not misstate anything by itself — but it can invalidate every automated control and every system-generated report in that application. Auditors therefore look at the aggregate: how many dependent controls does this gap touch, and can any of them still be relied on?

Two questions usually decide the outcome. First, is there a compensating control that operates at sufficient precision? A detective reconciliation performed by someone independent of the access gap can contain the damage; a management review that would not catch the error will not. Second, did the deficiency actually produce errors? Evidence of unauthorized changes or improper access moves the assessment sharply toward material weakness.

Outsourced systems follow the same logic. Under PCAOB AS 2601, only a Type 2 service auditor report provides evidence of operating effectiveness over a period; a Type 1 does not and cannot support reducing control risk. Check the report period against your fiscal year, and read the complementary user entity controls — those are your obligations, not your vendor’s. Our comparison of the PCAOB versus the AICPA explains why the standards differ.

The stakes are not theoretical. In January 2019 the SEC charged four public companies with longstanding ICFR failures, imposing penalties from $35,000 to $200,000 on companies that had disclosed material weaknesses for seven to ten consecutive years without remediating them.

How Do You Keep ITGC Evidence Audit-Ready Year-Round?

Most ITGC failures are not design failures. The control existed and someone performed it; nobody captured proof, or the proof surfaced only during the fourth-quarter scramble when it was too late to remediate.

Four practices move the needle:

1. Derive scope from the data flow, then re-derive it quarterly. Inventory every application, database, operating system, and integration that touches a significant account. Add a step to your change process that flags new systems for SOX scoping assessment.
2. Instrument access reviews instead of emailing spreadsheets. Pull entitlements directly from source systems, route them to named reviewers, and record the reviewer, the date, each decision, and the closure of every revocation. An access review without evidence of what happened to the exceptions is a finding waiting to happen.
3. Prove the population, not just the sample. Extract change records from the ticketing and deployment systems and reconcile them against each other. If your auditor cannot see how you established completeness, your sample proves nothing.
4. Keep policy and practice synchronized. Change management, access provisioning, and backup policies must describe what actually happens, with a documented review cadence. Our guide to policy management best practices covers the mechanics.

The market is moving in this direction. In Protiviti’s 2025 SOX compliance survey, fielded from late August to early October 2025, 68% of respondents said they were prioritizing additional technology and automation, 28% reported using segregation-of-duties analysis or access management tooling, and 24% were leveraging AI and machine learning tools including generative and agentic AI.

The end state is continuous controls monitoring: ITGC evidence accumulating automatically as a byproduct of normal operations, so a terminated user who still has production access is an alert in February rather than a material weakness in December.

Frequently asked questions

About this article. By Compyl Research. Last updated August 11, 2026. This is general information, not legal advice — consult counsel for your specific obligations. Compyl is an AI-powered, agentic GRC platform built by CISOs.