Skip to content
complianceofficer

ITGC controls software for SOX: IT general controls, IT application controls and the ITGC audit

ITGC are the IT general controls that make a financial system trustworthy enough to rely on: who can get into it, how changes reach production, how it was built, and whether it runs and gets monitored. They are not a separate compliance regime. They exist because a SOX 404 assessment that leans on an automated control or a system-generated report has to prove the system behaved for the whole period, not just on the day someone took a screenshot.

Two things make ITGC expensive. Scope, because the number of systems a control matrix touches keeps growing, and evidence, because auditors want complete populations rather than samples of convenience. This page covers how scope is actually set, the four domains and what sits in each, how ITGC differ from IT application controls, what evidence gets requested, and how a failed ITGC escalates.

Every standard reference here was checked against the PCAOB's published text of AS 2201 and AS 2110 in August 2026. Where a widely repeated practice is not in the standards, this page says so.

Scan your IT and financial reporting control obligations

Pick your industry and size, then choose the frameworks you report against. The scan returns the obligations that apply to an organization like yours, what moved in the last 12 months, and the primary source behind each line. No signup, nothing stored.

§ Live · Compliance scan

No signup. Nothing you pick is stored.

Frameworks you answer to

Sample register · fintech, US · what a scan returns

  • § 01 Written AML program with a named officer
  • § 02 KYC and customer due diligence
  • § 03 Sanctions screening lists Changed
  • § 04 PCI DSS v4.0 validation
§ 116 The domains

The four ITGC domains, and the risks each one is answering

Almost every ITGC program organizes itself into four domains. It is worth being honest about where that split comes from: it is practice convention inherited from the IT audit literature, not a list written into a PCAOB standard. AS 2201 and AS 2110 never enumerate ITGC domains. What AS 2110 does give you, in Appendix B paragraph .B4, is the list of risks arising from IT that your controls have to answer. Mapping the domains back to those risks is the fastest way to tell whether a control matrix is covering the ground or just filling a template.

ITGC domain Typical controls AS 2110 .B4 risk it answers
Access to programs and data Provisioning approval, periodic user access review, privileged and firefighter access, segregation of duties conflicts, termination revocation, password and MFA configuration Unauthorized access to data that may result in destruction of data or improper changes, including the recording of unauthorized or non-existent transactions; IT personnel gaining access privileges beyond those necessary, breaking down segregation of duties
Program change Change request and approval, testing before release, segregation between developer and migrator, emergency change handling, configuration change tracking Unauthorized changes to systems or programs; unauthorized changes to data in master files; failure to make necessary changes to systems or programs
Program development New system and major upgrade approval, user acceptance testing, data conversion validation and reconciliation, go-live authorization Systems or programs that process data inaccurately, or process inaccurate data; inappropriate manual intervention
Computer operations Batch job scheduling and failure monitoring, interface reconciliation, backup execution, restoration testing, incident and problem handling Potential loss of data or inability to access data as required; failure of processing to complete or complete accurately

Two of those four carry most of the audit findings in practice, and they are the two with the largest populations: access and change. Both produce a list that runs to thousands of rows over a year, and both are the places where a control that looks fine in the narrative turns out to have no evidence for March.

Program development is the domain teams most often argue their way out of, on the grounds that they had no major implementations that year. That argument is fine when it is true and documented. It stops being fine the year a module goes live, an acquisition is migrated, or a chart of accounts is converted, because the conversion itself becomes the highest-risk event in the whole ITGC population.

§ 117 Scope

How ITGC scope is set, and why most teams get it backwards

The single most common scoping mistake is starting from a list of systems. Someone exports the application inventory, filters for anything financial, and calls that ITGC scope. The result is a program that tests a reporting sandbox nobody relies on while missing the spreadsheet-fed pricing tool that feeds revenue.

The standard says to do the opposite. PCAOB AS 2201 paragraph .36 carries a note that is worth quoting exactly, because it settles the argument:

"The identification of risks and controls within IT is not a separate evaluation. Instead, it is an integral part of the top-down approach used to identify significant accounts and disclosures and their relevant assertions, and the controls to test, as well as to assess risk and allocate audit effort as described by this standard."

Read that as a scoping rule and it gives you a single test. A system enters ITGC scope only when something you are relying on in your Section 404 assessment lives inside it. That means one of three things: an automated control operates there, a system-generated report or population comes out of it, or a manual control's evidence is produced by it. Nothing else earns a system a place in the matrix.

System Why it is in scope, or not Verdict
General ledger and ERP Posts the transactions, produces the trial balance, hosts most automated controls In scope, always
Consolidation and reporting tool Produces the statements themselves, holds elimination and translation logic In scope
Payroll platform Feeds a material expense line and often a significant accrual In scope where material
CRM or order-entry system In scope only if it originates the revenue population or runs a control you rely on, not because it touches customers Depends on reliance
Data warehouse or BI layer In scope when a report you rely on is built there, which is more often than teams admit Depends on reliance
Ticketing, HR, marketing tools Financially irrelevant unless they produce control evidence, in which case the evidence path is what you scope Usually out

Scope creep is the actual cost driver

KPMG's 2025 SOX survey put the average in-scope system count at 40, up from 17 two years earlier, while key controls went from 463 to 546 and total program cost rose from $1.6 million to $2.3 million. The rates did not move much. The surface area did. Every additional in-scope system multiplies the ITGC population, because the same access review and the same change control get tested again in a new place.

That is the arithmetic behind a defensible scoping memo. Documenting why a system is out of scope is cheaper than testing it, and it is the one piece of ITGC documentation that pays for itself every year. Our SOX compliance guide covers how the same top-down logic sets scope for the financial statement side.

§ 118 ITGC vs ITAC

ITGC and IT application controls are not the same control

An IT application control performs an accounting check inside a process. A three-way match that blocks payment when the invoice, receipt and purchase order disagree. A posting-period lock. A credit limit that stops an order. An IT general control does not check any transaction. It protects the environment those checks run in.

The relationship is one of reliance, and AS 2201 paragraph .47 states the dependency plainly when it lists risk factors: an automated control "would generally be expected to be lower risk if relevant information technology general controls are effective." Take away that condition and the automated control gives you nothing.

IT general controls (ITGC) IT application controls (ITAC)
What it protects The system and its data as a whole One assertion in one process
Who operates it IT, with business approval on access and change The application, configured by the business
How it is tested Sampled from a period population of access grants, reviews and changes Configuration inspection plus reprocessing or observation of the rule firing
Blast radius on failure Pervasive: every automated control and report in that system loses reliance Contained: one control, one assertion
Test frequency Across the whole reliance period, because access and change happen continuously Often a smaller sample, on the strength of effective ITGC

That last row is the trade every SOX program is trying to make. Strong ITGC let you test an automated control lightly, because the environment guarantees it did not change. Weak ITGC force you back to manual sampling on every automated control the system runs, which is exactly the direction the KPMG data shows programs drifting: the share of controls that are automated fell from 21 percent to 17 percent while hours per control rose from 12 to 16.

§ 119 Evidence

What auditors actually request in an ITGC audit

ITGC testing fails on populations far more often than it fails on samples. The auditor does not want your evidence for the five changes you picked. They want proof that the list you picked from is complete, because a sample drawn from an incomplete population tests nothing. That is the request that catches teams unprepared, and it is worth knowing what it looks like per domain before February.

  • Access. The complete user listing as of a date, generated in front of the auditor or with a query they can see, plus the privileged and administrator listing, joiner and leaver records reconciled to HR, and the periodic access review showing who reviewed it, what they changed, and when. A review with no removals and no comments invites the question of whether it happened.
  • Change. The full population of production changes for the period, reconciled to the deployment log rather than to the ticket queue, since anything deployed without a ticket is the population gap that matters. For selected changes: the request, the approval, evidence of testing, and proof that the person who wrote it did not move it.
  • Development. Project approval, user acceptance sign-off, and for any conversion the reconciliation of record counts and control totals before and after. Data conversion evidence is the piece most often missing a year later, because the project team disbanded.
  • Operations. Job schedules with the failure and rerun log, interface reconciliations, backup completion records, and evidence of an actual restoration test rather than a policy saying one happens.

Sample sizes are your judgment, not a rule

The widely circulated table that pairs control frequency with a sample size, 25 for daily, 2 for quarterly, 1 for annual, is practice convention. PCAOB AS 2201 prescribes no sample sizes at all. You choose them based on the risk associated with the control and you have to defend that choice, which means a higher-risk ITGC deserves more than the table says and a low-risk one may deserve less. Treating the table as a rule is how a program ends up with hours it cannot justify and coverage it cannot defend.

Timing matters as much as size. ITGC operate continuously, so a sample drawn entirely from Q4 does not cover a period of reliance that starts in January. If you tested in October and the year ends in December, you owe a roll-forward, and that roll-forward has to be planned before October rather than negotiated in January.

§ 120 Deficiencies

How a failed ITGC turns into a material weakness

An ITGC exception is not a material weakness by itself. The severity question is the same one AS 2201 Appendix A asks of any deficiency: is there a reasonable possibility that a material misstatement would not be prevented or detected on a timely basis. What makes ITGC different is the multiplier. A single failed control does not sit alone, it removes the basis for relying on everything downstream of it.

Work the chain in this order and the conclusion usually writes itself.

  1. 1 Name what broke and for how long. A control that failed once in March is a different fact pattern from one that never operated. The period of exposure sets everything after it.
  2. 2 List what depended on it. Every automated control in that system, every system-generated report used as evidence, and every population drawn from it during the exposure window.
  3. 3 Ask what could have got through. Magnitude is measured on potential misstatement, not on what actually happened. Finding no errors does not close the question, it just means you have not found any.
  4. 4 Look for a compensating control that runs outside the broken system. A reconciliation performed in the same system by the same over-privileged user compensates for nothing.
  5. 5 Aggregate before you conclude. Both AS 2201 severity definitions cover "a deficiency, or a combination of deficiencies." Four survivable access exceptions in one ERP are one finding, not four.

One timing point catches people every year: remediation after the balance sheet date does not change the year-end conclusion. Internal control over financial reporting is assessed as of a date. Fixing an access review in February is the right thing to do and it does not retire a December finding. The material weakness vs significant deficiency breakdown walks through both severity tests with worked examples.

§ 121 Where software helps

Where ITGC software earns its money, and where it does not

Software does not make an ITGC effective. A tool cannot approve a change, revoke a terminated user's access or decide that a system belongs out of scope. What it can do is remove the two failure modes that cost real programs the most: evidence that goes missing between test date and audit date, and a control matrix that quietly falls out of date while the rules underneath it move.

Worth paying for

  • A control matrix that ties each ITGC to the account, assertion and automated control that depends on it, so blast radius is a lookup rather than a workshop
  • Evidence captured with its source, date and preparer at the moment of testing
  • Population completeness checks that reconcile a change list to the deployment log
  • Deficiency tracking that aggregates by system and process rather than by ticket
  • Alerting when a standard or a regulator changes something your matrix assumed

Not worth paying for

  • A generic ITGC control library dropped in without scoping, which produces controls you do not rely on and cannot retire
  • Screenshot storage with no population lineage behind it
  • Dashboards that count controls tested rather than reliance established
  • Anything sold as ITGC certification, which does not exist

Complianceofficer is being built for the second half of that problem. The control side is well served by existing platforms. What almost nothing does is watch the rulebook itself and tell you when a published change affects a control you already wrote. If you are buying for the full Section 404 cycle rather than the IT layer alone, our SOX compliance software page covers the risk and control matrix, walkthroughs and testing workflow, and audit management software covers the internal audit side that usually owns ITGC testing. Pricing across this category is quote-driven, and our compliance software pricing breakdown collects the public buyer data.

§ 122 Questions buyers ask

ITGC questions

What are ITGC controls?

ITGC stands for IT general controls. They are the controls over the systems that produce financial data, rather than over any single transaction. In practice they answer four questions: who can get into the system, how changes reach production, how new systems are built and migrated, and whether processing and backups run and get monitored. If those hold, an auditor can trust what the application calculates. If they do not, every automated control running inside that system becomes unreliable at the same time.

What are the four ITGC domains?

Access to programs and data, program change, program development, and computer operations. Worth knowing: that four-domain split is practice convention from the IT audit literature, not a requirement written into any PCAOB standard. AS 2201 and AS 2110 never enumerate ITGC domains. They describe IT risks and leave the taxonomy to you, which is why one firm tests four domains and another tests three.

What is the difference between ITGC and ITAC?

An IT general control protects the environment. An IT application control (ITAC) performs a specific accounting check inside a process, such as a three-way match, a posting-period lock or a credit-limit block. ITGC are pervasive and fail wide: one broken change-management control undermines every automated control in that system. An ITAC failure is narrow and hits one assertion in one process. You test ITGC so you can rely on ITAC.

Is ITGC required for SOX compliance?

The words IT general controls do not appear as a requirement in Section 404 of Sarbanes-Oxley. What makes ITGC unavoidable is reliance. The moment your Section 404 assessment leans on an automated control, a system-generated report or an application-produced population, you have to show the system was trustworthy for the whole period. ITGC are how you show it. Skip them and the manual controls above them lose their evidentiary base.

How do you determine ITGC scope?

Top-down, from the financial statements, never from an asset inventory. PCAOB AS 2201 paragraph .36 is explicit that identifying risks and controls within IT "is not a separate evaluation" but part of the same top-down approach used to pick significant accounts. So a system is in ITGC scope only if a control you are relying on runs in it or a report you are relying on comes out of it. Teams that scope from the CMDB test dozens of systems nobody relies on.

How many ITGC controls do you need for SOX?

There is no prescribed number, and any vendor quoting one is guessing. A single-ERP mid-market filer commonly lands between 20 and 40 ITGC across all in-scope systems. A multi-instance large accelerated filer runs into the hundreds because the same control repeats per system. The count that matters is per system in scope, not per company, which is why in-scope system growth drives program cost faster than headcount does.

What evidence do auditors ask for in an ITGC audit?

Population-level evidence first, then samples from it. For access: the complete user listing as of a date, the privileged-user listing, joiner and leaver records, and the review with the reviewer identified. For change: the full population of production changes for the period, with approval and test evidence for selected items. For operations: job schedules, failure logs and restore tests. The population is where most testing fails, because a screenshot is not a population.

What happens if an ITGC fails?

An ITGC failure is not automatically a material weakness, but it is rarely contained. You have to ask what it exposed: which automated controls and system-generated reports depended on that control, and whether a material misstatement could have passed through undetected. Because ITGC are pervasive, one failed change-management control can invalidate reliance on every automated control in that system at once, and the aggregation of those effects is what pushes a finding up the severity ladder.

Does a SOC 1 report cover ITGC for a cloud system?

Partly, and only if you read it properly. A SOC 1 Type 2 covers the provider's controls over the period, so it can carry the hosting and infrastructure layer. It does not cover your configuration, your user administration or your approvals, and every SOC 1 lists complementary user entity controls that the provider assumes you operate. Those remain yours to test. Check the period covered, the opinion, every exception noted, and the CUEC list.

Last updated August 2026.

§ 99 · Final entry

Get on the early-access list

Leave your work email, confirm the 6-digit code, and we will email you when your spot opens. Nothing is charged before launch.

§ 90

Related registers