What Are IT General Controls and Why Do Auditors Test Them?

IT general controls are the bedrock beneath every automated business process. When a system enforces an approval limit, calculates a balance, or restricts who can post payments, that control is only as reliable as the IT environment running it. This guide explains the four ITGC domains, why they are foundational to financial reporting, and why auditors test them before anything else.

What exactly are IT general controls?

IT general controls are the policies and procedures that ensure an organization’s information systems operate properly and securely. They are “general” because they apply across the IT environment rather than to a single application — they govern who can access systems, how changes are made, how operations run, and how new systems are developed.

ITGC are distinguished from application controls, which are built into specific systems (an automated three-way match in the purchasing module, for example). Application controls only work reliably if the general controls underneath them are sound. This dependency is why ITGC are foundational — they support the entire structure of automated controls a company relies on, including those critical to financial reporting.

What does access management cover?

Access management controls who can access systems and what they can do, ensuring only authorized users have appropriate access. It covers user provisioning and de-provisioning, password and authentication policies, privileged access management, and periodic access reviews to confirm rights remain appropriate as roles change.

Access is the most common ITGC weakness. Users accumulate rights over time, terminated employees retain access, and excessive privileges create segregation-of-duties conflicts invisible without systematic review. Strong access management — least-privilege provisioning and regular reviews — directly supports the segregation of duties that prevents fraud, linking ITGC to the control fundamentals in our internal controls guide.

Why is change management critical?

Change management controls ensure that modifications to systems — software updates, configuration changes, new functionality — are authorized, tested, and implemented without breaking existing controls or corrupting data. An uncontrolled change can silently disable a key control or introduce an error that affects every transaction processed afterward.

Effective change management requires authorization, testing in a separate environment, segregation between developers and those who deploy to production, and documentation of every change. The risk is acute: a single poorly controlled change to a financial system can undermine the reliability of the numbers, which is why auditors scrutinize change management closely when relying on system-based controls.

What do IT operations controls ensure?

IT operations controls ensure systems run reliably day to day: data is backed up and recoverable, scheduled jobs (like overnight batch processing) complete correctly, incidents are managed, and the environment is monitored for problems. These controls protect against data loss and processing failures that could corrupt financial records.

Backup and recovery is especially important — a company that cannot recover its data after a failure faces existential risk, and auditors test that backups actually work, not just that they run. Job scheduling controls matter because financial processing often depends on batch jobs completing in the right sequence; a failed job can leave records incomplete or duplicated.

Why do auditors test ITGC before application controls?

Auditors test ITGC first because application controls depend on them. If access is poorly controlled, an unauthorized person could alter data regardless of application controls; if change management is weak, a control could have been disabled mid-period without anyone knowing. Only when ITGC are reliable can the auditor trust the automated controls running on the systems.

This dependency creates a logical sequence: establish that the IT environment is controlled, then rely on the application controls within it. If ITGC fail, the auditor cannot rely on any system-based control and must fall back to extensive manual substantive testing — dramatically increasing audit effort and cost. This is why ITGC weaknesses are among the most consequential findings in a SOX program.

How do ITGC weaknesses affect financial reporting?

Because financial systems run on the IT environment, ITGC weaknesses can directly compromise the reliability of financial reporting. Weak access controls enable unauthorized changes to financial data; poor change management can disable automated controls; failed operations can corrupt or lose records. Each undermines confidence in the numbers.

For SOX-regulated companies, significant ITGC deficiencies can rise to material weaknesses, requiring public disclosure. Even without SOX, weak ITGC increase control risk, leading auditors to do more substantive testing and charge higher fees. Strong ITGC, by contrast, allow reliance on efficient automated controls — the connection between IT control quality and financial reporting reliability that finance leaders should understand.

How do ITGC differ in cloud environments?

Cloud computing shifts some ITGC responsibility to the cloud provider while leaving others with the customer — a shared responsibility model. The provider controls the physical infrastructure and platform security; the customer controls access, configuration, and how the service is used. Misunderstanding this split is a common source of control gaps.

In the cloud, auditors must understand which controls the provider operates (relying on the provider’s SOC reports) and which the customer must implement. Cloud misconfiguration — leaving storage open, granting excessive access — is a leading cause of breaches precisely because customers assume the provider handles security they are actually responsible for. This connects ITGC directly to third-party risk management.

What is segregation of duties in IT systems?

IT segregation of duties ensures no single person can both make changes and conceal them — developers should not deploy their own code to production, and users should not have conflicting access that lets them both initiate and approve transactions. System access rights must enforce the business segregation of duties that prevents fraud and error.

The challenge is that system access is complex and accumulates invisibly. A user who changes roles may retain old access, creating a conflict nobody notices. Specialized tools analyze access rights for segregation conflicts, and regular access reviews catch them. This IT-level segregation underpins the business-level controls described in our internal controls guide, making it foundational to the whole control environment.

How do auditors test ITGC in practice?

Auditors test ITGC through a mix of inquiry, observation, inspection, and re-performance. For access management, they review user lists, test the joiner-mover-leaver process, and examine privileged accounts. For change management, they sample changes and verify authorization, testing, and segregation. For operations, they confirm backups work and jobs complete. For development, they review the system implementation process.

The testing establishes whether each control operated effectively throughout the period, not just at a point in time. Because ITGC support everything else, a deficiency here often has broad implications, potentially undermining reliance on multiple application controls. This is why ITGC testing is foundational to a SOX program and why ITGC findings receive close attention from both management and external auditors.

How do automated and manual ITGC compare?

Automated ITGC — enforced by systems, such as automatic access expiry or mandatory change approval workflows — are more reliable and consistent than manual ones, because they cannot be skipped under pressure or forgotten. Manual ITGC, such as a periodic access review performed by a person, are more flexible but prone to human error and inconsistency.

The trend is toward automation, since automated controls scale and self-document. But automated controls carry their own risk: a misconfigured automated control fails silently and at scale, affecting every transaction without anyone noticing. This is why auditors test that automated controls are configured correctly and monitored, not just that they exist, applying the same design-and-operation testing used for all internal controls.

What happens when ITGC fail an audit?

When ITGC fail, the auditor cannot rely on the automated controls running on those systems and must fall back to extensive manual substantive testing — testing the actual data and balances directly rather than relying on the controls that should protect them. This dramatically increases audit effort, time, and cost.

For SOX-regulated companies, significant ITGC deficiencies can rise to material weaknesses requiring public disclosure, with serious market consequences. Even without SOX, ITGC failures signal an unreliable IT environment and elevated control risk. The lesson for finance leaders is that investing in strong ITGC is not just an IT matter — it directly affects audit cost, financial reporting reliability, and the company’s control posture, as detailed in our SOX guide.

How do ITGC support business continuity?

ITGC underpin business continuity through backup, recovery, and operations controls that ensure systems and data can be restored after a failure or disaster. A company that cannot recover its financial systems after an incident faces existential risk, which is why auditors test that backups are not just performed but actually recoverable.

Disaster recovery planning — documented procedures, tested recovery capability, and defined recovery time objectives — is part of the operations domain of ITGC. For organizations dependent on their systems (which is now nearly all of them), the ability to recover from ransomware, hardware failure, or disaster is fundamental. This resilience connects ITGC to the broader business continuity considerations within enterprise risk management.

How do you remediate ITGC deficiencies efficiently?

Remediating ITGC deficiencies efficiently means fixing root causes — often process and access governance rather than isolated technical fixes. A recurring access deficiency usually points to a weak joiner-mover-leaver process, not a one-off error; fixing the process resolves the pattern. Automation of access reviews and change approvals removes the manual gaps that cause many ITGC failures.

Prioritization matters because ITGC deficiencies vary in impact: a privileged access weakness is more serious than a minor documentation gap. Addressing the deficiencies that most undermine reliance on automated controls first restores audit efficiency fastest. This risk-based remediation, with re-testing to confirm the fix, follows the same disciplined approach described in our control deficiency remediation guide, applied to the IT environment.

Frequently Asked Questions