What an ITGC is, and why it never touches a number

An auditor asks for "your ITGCs," and the reply is usually one of two things: a spreadsheet listing every system the company owns, or a SOC 2 report handed over on the theory that it must cover the same ground. Both answers miss what the term means, and the miss is expensive in both directions — ITGC scope is one of the few parts of a SOX program where doing too much costs about as much as doing too little.

So it is worth being exact about what an IT general control actually is.

An ITGC is a control that makes another control trustworthy

An IT general control is a control over the IT environment — who can get in, what can change, whether the machinery ran — whose purpose is to keep other controls working the way they are supposed to. It sits underneath. It does not touch a number.

That sounds like a technicality until you see what follows from it. The SEC's 2007 interpretive guidance on management's assessment of internal control over financial reporting puts the point directly: "IT general controls alone ordinarily do not adequately address financial reporting risks, the proper and consistent operation of automated controls or IT functionality often depends upon effective IT general controls."

Both halves of that sentence do work. An ITGC does not, on its own, stop a revenue figure from being wrong. But the control that does stop it — the automated tolerance check, the system-calculated accrual, the exception report a controller reviews — is only worth as much as the assurance that the program computing it has not been changed without authorisation and cannot be operated by someone who should not be there.

Which makes the definition relational rather than technical. A control is an ITGC because a financial reporting control depends on it. Nothing about the control's own contents makes it one.

The definition starts with ICFR, not with IT

Rule 13a-15(f) defines internal control over financial reporting as a process designed to "provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles," including policies and procedures that pertain to maintaining records that "accurately and fairly reflect the transactions and dispositions of the assets of the issuer."

Information technology is not mentioned anywhere in it. ITGCs are not a separate obligation bolted onto Section 404. They are inside ICFR only to the extent financial reporting depends on systems — which, for almost every company operating now, is most of it.

Nor does any of this depend on having an auditor on the other side of it. Section 404 of the Sarbanes-Oxley Act, codified at 15 U.S.C. 7262, provides at subsection (c) that the attestation requirement does not apply to an audit report prepared for an issuer that is neither a large accelerated filer nor an accelerated filer — but management's assessment stands either way, as 404(a) vs 404(b) sets out.

The SEC guidance is equally clear about method: "The identification of risks and controls within IT should not be a separate evaluation. Instead, it should be an integral part of management's top-down, risk-based approach to identifying risks and controls."

That is precisely why the list-every-system answer fails. It starts from the inventory rather than from the financial statements. How to run it the other way round is the subject of the ITGC scoping article.

Three things that get called by each other's names

Most of the confusion in this area is a naming problem. Three different kinds of control involve systems, and only one of them is an ITGC.

Term	What it is	What testing it looks like
Automated application control	Logic inside the system performs the control — a check that blocks a purchase order above the approved amount	Test the configuration once, then show it did not change
IT-dependent manual control	A person performs the control using information the system produced — a reviewer works an aging report	Test the reviewer's work and the completeness and accuracy of the report
IT general control	A control over the environment the other two run in — access, change, operations	Test the population of users, changes or jobs across the period

The test question for any candidate control is short: if this failed, which financial reporting control would stop being reliable? A clean answer makes it an ITGC. No answer means it is not one, whatever else it may be worth to the business.

What is not an ITGC

The guidance draws the boundary itself. Management "only needs to evaluate those IT general controls that are necessary for the proper and consistent operation of other controls," and does not need to evaluate those that "primarily pertain to efficiency or effectiveness of a company's operations, but which are not relevant to addressing financial reporting risks."

In practice that leaves a good deal outside the line. Endpoint protection, phishing simulations, the web application firewall, the vulnerability management programme, the sandbox with no path to production: all genuinely worth doing, none of them ITGCs unless a financial control rests on them. Keeping them out is not a lowering of standards. It is the difference between a SOX program and a security program that happens to be audited annually.

The blurry cases are worth deciding deliberately rather than by default — backup and recovery is the usual one, and whether it belongs in scope depends on whether any financial reporting control depends on restoration. In our view, pick a position, write the reasoning down, and raise it with the auditor early rather than arguing it during fieldwork.

The same logic applies to reports from providers. A provider's report is a statement about their environment rather than yours, so it cannot tell you which of your financial reporting controls have come to depend on them — that mapping is work only you can do. Which report to ask for, and what each one is built to answer, is set out in SOC 1 vs SOC 2.

Why auditors care about a control that touches no number

Because ITGCs are the reason the rest of the testing can be cheap.

PCAOB AS 2201 lists, among the factors affecting the risk associated with a control, "the degree to which the control relies on the effectiveness of other controls (e.g., the control environment or information technology general controls)" and "whether the control relies on performance by an individual or is automated (i.e., an automated control would generally be expected to be lower risk if relevant information technology general controls are effective)."

Read that as an economics statement. A control the computer performs the same way on every transaction is the cheapest thing in the program to test — but only if you can demonstrate the program did not change and nobody could change it. Strip the ITGCs away and the leverage inverts: each automated control has to be proven the hard way, transaction by transaction.

What happens when one fails

An ITGC deficiency is scored by what depends on it, not by how alarming it looks on its own. AS 2201 includes among the factors affecting severity "the interaction or relationship of the control with other controls, including whether they are interdependent or redundant," and the SEC guidance frames management's own evaluation around whether there is a reasonable possibility that ICFR will fail to prevent or detect a misstatement, with magnitude driven by things like the amounts and volume of activity exposed to the deficiency.

That is why the same fact pattern can be trivial or serious. A departed administrator whose account stayed open on a system holding nothing that reaches the financial statements is a security housekeeping problem. The same account left open on the ERP is potentially pervasive, because every automated control and every system-generated report in that ERP now sits on an access control that demonstrably did not work.

Two consequences follow, and both are our own observation rather than anything a standard says. ITGC exceptions aggregate: individually minor findings across access, change and operations in one system tend to get evaluated together. And an unreliable ITGC does not merely fail — it makes the controls above it untestable in the efficient way, pushing work back onto larger manual samples at the point in the year with least room for it.

Where to start if nothing is written down yet

1. Build the inventory by dependency, not by system. For each in-scope application, write the sentence "this system is relied upon for ___" and finish it with a control, an account or a report. Systems where the sentence cannot be finished are out.
2. Write the exclusions down with reasons. A documented exclusion is a conversation; a silent one is a scope expansion waiting to happen.
3. Check that the evidence exists for a period already past. ITGCs operate continuously, and no amount of later effort creates a user list, an approval or a change ticket for a month that has already closed.

If you are working out how much runway you have, the SOX 404 deadline calculator lays the milestones back from your year-end, and the readiness scorecard will show which gaps are still fixable in the time left. This is general information rather than audit or legal advice; confirm scope decisions with your auditor or counsel.

Common questions

Is an ITGC the same thing as an IT security control?

They overlap, but they answer different questions. An IT general control earns its place in a SOX program because a financial reporting control depends on it. The SEC's interpretive guidance is explicit that management need not evaluate IT general controls that primarily pertain to the efficiency or effectiveness of operations but are not relevant to addressing financial reporting risks. A security control with no financial control resting on it is still worth having, and still not an ITGC.

How do we tell whether a system belongs in ITGC scope?

Ask what financial reporting control would become unreliable if that system's access, change or operations controls failed. If you can name one, the system is in scope for the controls that support it. If you cannot name one, write down the reason for the exclusion rather than leaving it silent.

Does a SOC 2 report cover our ITGCs?

Not on its own, and in our view the question is the wrong shape. A report you receive from a provider is a statement about the provider's environment; your ITGCs are the controls in yours, and the two are different populations. The useful move is to work out which of your financial reporting controls have come to depend on that provider, and then decide what evidence about them you actually need. Which report to ask a provider for is worth settling before you ask for one.

Is every ITGC exception a material weakness?

No. Severity turns on what depends on the control and on the magnitude of misstatement that could result. AS 2201 defines a material weakness as a deficiency, or combination of deficiencies, creating a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis, and a significant deficiency as less severe but important enough to merit attention by those responsible for oversight. In our view the scoring rarely turns on the exception in isolation: what sat on top of the control decides it, and combinations in the same system are where the risk concentrates.

Do ITGCs matter if we are only subject to 404(a) with no auditor attestation?

Generally yes. Section 404 of the Sarbanes-Oxley Act, codified at 15 U.S.C. 7262, provides at subsection (c) that the auditor attestation requirement does not apply to an audit report prepared for an issuer that is neither a large accelerated filer nor an accelerated filer. Management's own obligation is untouched by that: Rule 13a-15(c) requires management to evaluate the effectiveness, as of the end of each fiscal year, of the issuer's internal control over financial reporting. Controls that rely on systems cannot be concluded on without evidence about those systems. Confirm your own filer status and its consequences with your auditor or counsel.

Sources

1. 17 CFR 240.13a-15 — Controls and procedures, including the definition of internal control over financial reporting at paragraph (f) · U.S. Government Publishing Office (Code of Federal Regulations)
2. Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting Under Section 13(a) or 15(d) of the Securities Exchange Act of 1934 (Release No. 33-8810) · U.S. Securities and Exchange Commission, published in the Federal Register
3. AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements · Public Company Accounting Oversight Board
4. 15 U.S.C. 7262 — Management assessment of internal controls (Sarbanes-Oxley Act Section 404), including the exemption from auditor attestation at subsection (c) · U.S. Government Publishing Office (United States Code)