IT general controls (ITGCs) are the foundational controls an organization applies to its IT environment so that the systems and data behind its business processes, especially financial reporting, can be trusted. They cover who can access systems, how changes to systems are made, and how systems are operated day to day. Auditors test ITGCs because automated controls and system reports are only as reliable as the environment around them.
At a glance
- ITGCs apply across systems, rather than to one transaction or report; they support the controls inside each application.
- Common areas are logical access, change management, IT operations and, in some approaches, system development or acquisition.
- External auditors usually test ITGCs for systems relevant to financial reporting, which is central to Sarbanes-Oxley compliance for US public companies.
- When cloud or managed providers run part of the environment, their independent reports and your complementary controls both count.
What problem it solves
Finance teams rely on systems to calculate, record and report numbers. If anyone can change an ERP configuration, a payroll table or a revenue report without approval, those numbers can’t be trusted, whether through error or fraud. Auditors can’t test every transaction, so they test whether the environment is controlled well enough to rely on the system.
ITGCs give that assurance. For mid-market companies planning an IPO, raising capital or facing stricter audits, weak ITGCs are a common source of audit findings, extra audit work and, at worst, reported control weaknesses.
How it works
Logical access. Access to in-scope systems is requested, approved, granted on least privilege, reviewed periodically and removed promptly when people leave or change roles. Administrator and other privileged accounts get extra restriction and monitoring, often through privileged access management (PAM). Identity tools from identity and access management (IAM) help produce evidence.
Change management. Changes to applications, databases and infrastructure are requested, tested, approved and moved to production by people other than the developer where practical, with emergency changes reviewed after the fact.
IT operations. Scheduled jobs, interfaces, backups and incident handling are monitored, and failures are resolved and documented.
Development and acquisition. New systems and major upgrades follow a controlled process, including testing and data migration checks.
Evidence. Auditors sample tickets, approvals, access lists and system audit trails. Controls that run without leaving a record are hard to prove, so evidence collection is designed in from the start.
Control deficiency levels
ITGCs have no certification levels. When auditors find a problem in internal control over financial reporting, US practice classifies it by severity. The definitions come from auditing standards and SEC rules; your auditor makes the call, so treat this as an overview, not accounting or legal advice.
| Classification | What it generally means | Who evaluates it | What typically follows |
|---|---|---|---|
| Control deficiency | The design or operation of a control doesn’t allow management or employees, in the normal course of their work, to prevent, or detect and correct, misstatements on a timely basis; how severe it is gets assessed separately | Management and the external auditor | Fix and document; deficiencies are evaluated individually and in combination, because several can add up to a significant deficiency or material weakness |
| Significant deficiency | Less severe than a material weakness, but important enough to merit the attention of those overseeing financial reporting | Management and the external auditor | Communicated to the audit committee; remediation plan |
| Material weakness | A reasonable possibility that a material misstatement in the financial statements won’t be prevented or detected in time | Management and the external auditor | For public companies, generally disclosed and management can’t conclude controls are effective; remediation and retesting |
An ITGC failure doesn’t automatically mean a material weakness. Auditors consider compensating controls and which applications were affected.
When it matters for buyers
- When you choose an ERP, payroll, billing or other financial system provider. Ask whether the provider offers a SOC 1 report covering the service.
- When you outsource IT operations to an MSP. Access, change and backup controls may become partly theirs, and auditors will want evidence.
- When preparing for an IPO or SOX compliance. ITGCs are typically among the first things auditors test.
- When moving financial systems to the cloud. Control ownership shifts, and gaps can appear in the hand-off.
Our governance, risk and compliance overview covers help with control design, evidence and audit readiness.
Questions to ask vendors
- Do you provide a SOC 1 report for this service, and what period and controls does it cover?
- Which complementary user entity controls does your report expect us to operate?
- Can you export user access lists and admin activity logs for our quarterly access reviews?
- How are changes to the platform approved, tested and communicated to customers?
- If you manage our systems, who on your team has administrative access, and how is it reviewed?
- How quickly can you supply evidence when our auditors ask for it?
How it differs from SOC 2
A SOC 2 report is an attestation from a CPA firm about a service organization’s controls related to security and, optionally, availability, processing integrity, confidentiality or privacy. ITGCs are a category of controls, not a report. Many ITGCs, such as access reviews and change approval, also appear in SOC 2 audits, which is why the two get confused. But for financial reporting, auditors usually look to a SOC 1 report and to your own ITGCs, because SOC 1 is designed around internal control over financial reporting. In a compliance audit for a financial statement auditor, a SOC 2 alone may not answer their questions.