IT General Controls (ITGC): Domains, Examples, and How They Are Tested

IT general controls, or ITGCs, are the controls over the systems that produce financial and operational data: who can access them, how they are changed, how new ones are built and implemented, and how they are operated day to day. They matter because almost every other control depends on them. An automated three-way match, a system-calculated revenue schedule, and the aging report a controller reviews are only reliable if the underlying system is protected from unauthorized access, unauthorized change, and operational failure. When ITGCs fail, auditors cannot rely on application controls or system-generated reports, and the testing burden shifts to expensive manual work or, in a SOX audit, to a deficiency finding. This article covers the four ITGC domains, the controls that live in each, and how they are actually tested.

Where ITGCs sit in a control framework

Controls over financial reporting come in layers. Entity-level controls set tone and governance. Process controls, both manual and automated, act on individual transactions and balances. ITGCs sit underneath the automated process controls and the reports the manual ones depend on, which is why they are scoped by system: an ITGC program covers the applications, databases, operating systems, and infrastructure that support in-scope financial processes, plus the outsourced services those systems depend on. In a public company the framework is SOX and the auditor's standard is PCAOB AS 2201, covered in our guide to SOX compliance. In a private company the same controls appear under SOC 2, ISO 27001, and lender or acquirer diligence, with the same four domains and largely the same evidence.

Domain one: logical access to programs and data

Access controls make sure only authorized people can reach systems and data, at the level their role requires. The core controls are user provisioning that requires documented approval before an account is created, deprovisioning that removes access promptly when someone leaves or changes roles, periodic access reviews in which system owners confirm every account and its permissions, and privileged access management that restricts administrator and database rights to a small named group whose activity is logged. Authentication requirements, including password policy and multi-factor authentication on financially significant systems, complete the domain. The most common findings are terminated employees whose access outlived them, shared administrator accounts that cannot be attributed to a person, and access reviews that were performed but never acted on. Segregation of duties lives here too: the person who can create a vendor should not be able to approve its invoices, and the system permissions have to enforce that rather than a policy document asserting it.

Domain two: program change management

Change controls ensure that modifications to in-scope systems are authorized, tested, and approved before they reach production, and that developers cannot push their own changes live. The evidence is a ticket or change record for every production change showing the request, the approval, the test results, and the approval to deploy, plus system configuration that separates development, test, and production environments and restricts production deployment to people who did not write the code. Emergency changes get their own path with retrospective approval. Auditors test this domain by pulling the population of production changes directly from the system, not from the ticketing tool, and tracing a sample back to complete records, which is how undocumented changes get found. Configuration changes to ERP settings, report logic, and interfaces count as changes even when no code is written, and they are the ones most often missed.

Domain three: program development and implementation

When a company implements a new system or a major upgrade, development controls govern the project: requirements and design approval, testing including user acceptance, data migration with reconciliation between the old and new systems, and formal go-live approval. This domain is dormant in years without major projects and becomes the center of attention during an ERP implementation, which is also when material weaknesses most often get created, because migrated balances were never reconciled or legacy access was carried into the new system wholesale. A buyer performing technology diligence looks at exactly the same evidence.

Domain four: computer operations

Operations controls keep systems running correctly: job scheduling and monitoring for batch processes such as nightly interfaces and postings, with failures logged and resolved; backup and recovery with periodic restoration testing; incident and problem management with root cause documented for anything that affected financial data; and monitoring of interfaces between systems so that a record dropped between the billing platform and the general ledger is caught. Where systems are hosted or operated by a third party, the operations evidence comes from that provider's SOC 1 report, and the company's control is reviewing the report, mapping its complementary user entity controls, and covering any gap in the report's period with a bridge letter.

Why the domains cannot be tested in isolation

ITGCs are assessed as a system because a failure in one domain undermines the others. If developers hold production access, change management cannot be relied on regardless of how well tickets are documented. If access reviews never remove anyone, the provisioning approval at hire means little a year later. Auditors therefore test the domains together per system and reach a conclusion about whether the system's automated controls and reports can be relied on for the period. This is also why a company cannot fix an ITGC finding by adding a compensating manual review at year end: the manual review may address the specific misstatement risk, but the automated controls the system supports still lose their reliance, and the testing burden expands across every process that touches the system.

ITGCs in cloud and SaaS environments

Most companies now run in-scope financial systems as cloud services, which changes where the controls live without changing what they are. For infrastructure and platform services, part of the control set is inherited: the provider's SOC 1 or SOC 2 report evidences physical security, hardware operations, and often the platform's own change management, and the company's control is obtaining and reviewing those reports annually and covering any period gap. What remains the company's own is everything about its use of the service: who has access to the SaaS application and at what role, how configuration changes to the application are approved, how integrations and data flows between systems are controlled, and how the identity provider that gates access to all of it is administered. In practice the identity provider becomes the single most important system in the ITGC scope, because a compromised or poorly governed identity platform undermines access control everywhere at once. Auditors test the company's controls over its SaaS configurations directly and rely on the provider's report for the rest, and the most common gap is a company that assumes the provider's SOC report covers user access to its own instance, which it never does.

How ITGCs are tested

Testing follows the same sequence as any control: understand the design through a walkthrough, confirm it operated throughout the period through inspection and reperformance, and conclude on design and operating effectiveness. Populations come from the system of record, an export of all accounts, all changes, all job failures, so the tester chooses the sample rather than the control owner. Sample sizes scale with frequency under common audit practice: one instance for an annual control, two for quarterly, two to five for monthly, five to fifteen for weekly, and twenty to forty for daily or multiple-times-daily controls, with automated controls tested once when change management is effective. Exceptions are evaluated for whether they represent a design gap or an isolated failure, and whether the control operated for enough of the period after remediation to be relied on. Internal audit or an outside firm performs this testing during the year so that management's assessment rests on evidence rather than assertion, a discipline covered more broadly in our internal security audit guide.

ITGCs and the security program are the same controls

Every ITGC domain has a twin in a security framework. Access and privileged access controls are the core of SOC 2's logical access criteria and ISO 27001's access control section. Change management appears in both. Backup, incident, and monitoring controls are operations controls in either context. Companies that hold a current SOC 2 report already have the evidence architecture ITGC testing needs, scoped to a broader system boundary, and the work of a SOX program is narrowing that scope to financially relevant systems and aligning the period. Our SOC 2 compliance checklist maps the overlap. BD Emerson performs ITGC design assessment and testing through our ITGC audit practice, staffed by the same practitioners who run SOC 2 and ISO 27001 programs, for companies preparing for their first SOX year, supporting internal audit, or fixing the access and change findings that surfaced in an external audit.