ITGC: IT General Controls and ITAC Explained

Last updated August 2026. ITGC stands for IT general controls: the controls that govern the technology environment around your systems rather than the transactions inside any one of them. Auditors group them into four domains: access to programs and data, program changes, program development, and computer operations. They matter because every automated control and every report a system produces is only as trustworthy as the environment it runs in. If anyone can change the code without approval, no output from that system can be relied on.

This guide covers what sits in each domain, how ITGC differs from ITAC, what evidence a SOX or SOC 2 auditor actually samples, and the exceptions that get written up most often.

What does ITGC stand for?

ITGC stands for information technology general controls, usually shortened to IT general controls. The word doing the work is "general": these controls apply broadly across systems and infrastructure, as opposed to application controls, which live inside one specific application. An access provisioning process that covers every production system is a general control. A three-way match rule inside your ERP is not.

The concept comes out of financial audit, where it was formalized because auditors needed a way to decide whether they could rely on a system's output at all. It has since spread well beyond SOX. The same four domains reappear in SOC 2, ISO 27001, PCI DSS and HITRUST under different names and numbering.

What are the four ITGC domains?

Here are the four domains, what each governs, and the evidence auditors ask for. This table is the part worth keeping.

Some frameworks and firms split these differently. You will see three domains where development is folded into changes, and five where segregation of duties is pulled out of access into its own heading. The underlying control set is the same; only the packaging moves. When a checklist you find online has a different count, that is why.

What is the difference between ITGC and ITAC?

ITGC governs the environment around an application. ITAC, meaning IT application controls, governs what happens inside it. ITGCs are broad and system-agnostic; ITACs are specific, automated and embedded in one application's logic.

The relationship is the important part, and it runs one way. An application control is only as reliable as the general controls beneath it. If your ERP automatically blocks any purchase order over $50,000 without a second approval, that is a strong ITAC. But if a developer can push a change to production unreviewed, the auditor cannot rely on that rule, because nothing proves it was in force all year. This is why ITGC failures cascade: a broken change management control does not just produce one finding, it undermines every automated control in the systems it covers.

That last row is the practical reason auditors spend so much time on ITGC. Testing an automated application control once is cheap, but only if the general controls hold. When they do not, the auditor has to fall back to substantive testing, which means far more sampling, a longer engagement and a bigger bill.

Why do ITGCs matter for SOX?

Under Sarbanes-Oxley section 404, management must assess the effectiveness of internal control over financial reporting, and for accelerated filers the external auditor attests to it. Financial reporting runs on systems, so the auditor needs to know whether those systems can be trusted. ITGCs are how that question gets answered.

SOX ITGC scoping starts from the financial statements and works backwards: which accounts are material, which processes feed them, which applications support those processes, and which databases and operating systems sit underneath. Everything in that chain is in scope. Everything outside it is not, and over-scoping is one of the most common and expensive mistakes in a first-year program. A marketing tool that never touches the general ledger does not need SOX ITGC treatment, however important it is to the business.

If you are building the wider program rather than just the IT half, our guide to SOX compliance requirements covers the surrounding obligations, and SOX compliance software covers keeping the control evidence current between quarters.

Access to programs and data, the domain that fails most

Access is where the majority of ITGC exceptions come from, for an unglamorous reason: it is the only domain that decays on its own. Change management fails when someone skips a step. Access fails when nobody does anything at all, because people join, move teams and leave continuously, and entitlements accumulate unless something removes them.

Three things reliably draw findings. Terminated users whose access was not removed promptly, where the auditor compares the HR termination date against the deactivation timestamp and counts days. Privileged accounts that nobody owns, particularly shared service and break-glass accounts with no named individual behind them. And access reviews that were performed but not evidenced, which is the most frustrating category because the work happened and the control still fails: a review with no record of who reviewed what, when, and what they decided cannot be tested. The mechanics of doing this properly are in our walkthrough of the user access review process, and user access review software handles the sign-off trail that makes the control provable.

Segregation of duties sits inside this domain and is tested differently. The auditor is not asking whether someone did something wrong; they are asking whether the system permits an individual to complete a whole sensitive transaction alone. The classic pairs are creating a vendor and approving payment to it, and writing code and deploying it to production.

Program changes and program development

The change management control an auditor tests is narrow and specific: every change that reached production was authorized, tested and approved by someone other than the person who made it. In practice the difficulty is rarely the approval step, it is proving population completeness. The auditor will ask how you know the change list you handed over contains every change. If your evidence is an export from a ticketing system, the natural follow-up is what stops a change from reaching production without a ticket. A deployment pipeline that refuses unlinked changes answers that question; a policy saying developers should always raise a ticket does not.

Emergency changes are the standard exception. Most organizations allow them, which is reasonable, and most fail to document them retrospectively, which is not. A functioning emergency process needs a defined trigger, a named approver and a documented review after the fact, within a stated window.

Program development covers new systems rather than changes to existing ones, and for most companies it only comes into scope in a year with a major implementation. When it does, the item auditors care about disproportionately is data conversion: whether the balances that moved into the new system were reconciled to the old one and signed off. That reconciliation is easy to produce at the time and close to impossible to reconstruct a year later.

Computer operations

Operations is the domain teams evidence worst, because nothing generates a document until something goes wrong. Backups run silently, jobs succeed silently, and then an auditor asks for proof that a nightly process completed on 40 sampled dates across the year.

Two controls carry most of the weight. Job monitoring, where the test is not that jobs never failed but that failures were detected and resolved, so a period with zero recorded failures is treated as a red flag rather than a clean result. And backup and recovery, where the control auditors care about is the restore test, not the backup itself. A backup nobody has ever restored is an untested assumption. Availability and job evidence both need to be dated and external to the person asserting it, which is why continuous service and API monitoring is worth having in place before the audit rather than reconstructing uptime from memory and chat history afterwards.

How are ITGCs tested?

For a control that operates many times across the period, the auditor picks a sample and tests each item. Sample sizes follow control frequency: a daily control usually draws around 25 items, weekly around 5 to 15, monthly 2 to 5, quarterly 2, and annual controls are tested once. Those are the conventions in common use rather than a rule fixed in a standard, and firms vary.

Before sampling, the auditor establishes population completeness, and this trips up more programs than the sampling itself. You have to show that the list you sampled from is the whole list. A system-generated report with its parameters visible does this; a spreadsheet someone maintained does not.

The distinction between design and operating effectiveness matters too. A control can be well designed and still fail because it was not performed in three of the twelve months. That is the same distinction as a SOC 2 Type 1 versus Type 2 report: design at a point in time against operation across a period.

The same controls, several frameworks

The commercially useful fact about ITGC is that these four domains are not SOX-specific. The same access review satisfies a SOX ITGC, several SOC 2 common criteria, ISO 27001 Annex A controls in the access control theme, and PCI DSS requirement 7. The same change approval evidence answers change management questions in all of them.

Regulated industries extend the same list further than most teams expect. In an FDA-regulated company, the access and change domains carry most of the weight of 21 CFR Part 11: limiting system access to authorized individuals sits at 11.10(d), authority checks at 11.10(g), and control over systems documentation at 11.10(k). Quality teams often run those as a separate validation project when the evidence already exists in the ITGC programme, and the two rarely reconcile because nobody realized they were testing the same control twice.

Most teams do not get this leverage, because each audit is run as its own project with its own evidence request list, and the same screenshot is collected three times by three people. Mapping a control once and pointing every framework at the same dated artifact is the entire argument for compliance audit software, and it is why the second framework should cost a fraction of the first. If you want the control-level detail, the ISO 27001 Annex A controls list shows where the ITGC domains land in that standard.

The short version

ITGC means IT general controls, grouped into access to programs and data, program changes, program development and computer operations. They exist so an auditor can decide whether a system's output is trustworthy, which is why an ITGC failure undermines every application control that depends on it. Access is where most exceptions occur, population completeness is where most tests get stuck, and the restore test is the operations control people forget. None of it is technically hard. It is mostly a question of whether the evidence was captured while the control ran, or is being reconstructed now that someone has asked.