IT general controls, often shortened to ITGCs, are the environment-wide safeguards that keep an organization’s technology trustworthy enough to produce reliable financial data. They govern three things: who can access systems, how changes to those systems get made, and how daily operations run. When ITGCs work, auditors can rely on the automated processes that touch financial reporting. When they fail, every downstream control built on top of that technology becomes suspect.
For public companies, this isn’t optional. Section 404 of the Sarbanes-Oxley Act requires management to assess internal controls over financial reporting in every annual report, and for larger filers, an independent auditor must attest to that assessment.1Office of the Law Revision Counsel. 15 U.S. Code 7262 – Management Assessment of Internal Controls ITGCs are a core part of that assessment, because most financial data now flows through systems rather than paper.
The Three Domains ITGCs Cover
ITGCs are organized around three domains, each targeting a different risk to the integrity of financial data. PCAOB Auditing Standard 2201 identifies these same three areas — program changes, access to programs, and computer operations — as the general controls an auditor must evaluate before relying on any automated application control.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements
Access Management
Access management controls determine who can get into systems, what they can do once inside, and how quickly access gets shut off when it’s no longer needed. The organizing principle is least privilege: every user should have exactly the access their job requires, nothing more. The domain covers logical access to applications, databases, operating systems, and network infrastructure.
The controls follow a lifecycle. New accounts require documented requests and approvals before provisioning. When employees change roles, their access should be reviewed and adjusted. When they leave, accounts must be disabled promptly. Stale accounts belonging to departed employees are among the most common ITGC audit findings and among the easiest to prevent.
Periodic access reviews complete the lifecycle. At least annually, control owners should review all user access rights for critical applications and confirm each user’s access is still appropriate. Privileged accounts — system administrators, database owners, anyone with elevated permissions — get closer scrutiny, including multi-factor authentication and logging of all privileged activity.
Segregation of duties sits at the intersection of access management and business process risk. No single person should be able to both initiate and approve the same transaction. A user who can create a new vendor record and also approve payments to that vendor has a combination that could conceal fraud. Organizations enforce segregation through access matrices and automated rule sets that flag incompatible combinations before they get provisioned.
Change Management
Change management controls ensure that modifications to applications, databases, operating systems, and infrastructure follow a documented, authorized process. The risk is straightforward. Unauthorized or untested changes to production systems can introduce errors into financial data, and nobody may notice until the next audit, or until financial statements have already been filed.
A well-designed process follows a clear sequence. A change request is submitted and documented, describing the modification and its business justification. Someone independent from the developer reviews and approves the request. The change is built and tested in a non-production environment, and the test results are documented. A separate approval authorizes migration to production. The deployment itself is performed or verified by someone other than the developer who wrote the code.
That separation between the person making the change and the person approving or deploying it is one of the most important controls in the domain. When the same person who writes code can push it directly into production without independent review, a critical check is gone.
Emergency changes are inevitable. Production systems break and need immediate fixes. But emergency changes still require controls. The typical approach allows the fix to be deployed with abbreviated pre-approval, then requires formal after-the-fact documentation and management review within a short window. Organizations that treat “emergency” as a blanket bypass of the change process end up with audit findings.
Modern development teams using automated CI/CD pipelines can build many of these controls directly into the deployment tooling. Automated pipelines can enforce code review requirements, run mandatory test suites, require approval gates before production deployment, and log every step. Well-implemented pipelines actually strengthen change management because they eliminate the human shortcuts manual processes are prone to. For auditors, the key is verifying that the pipeline configuration itself is protected. Who can modify the pipeline rules is just as important as who can modify the application code.
IT Operations
IT operations controls cover the daily activities that keep systems running, processing transactions correctly, and recovering when things go wrong. The domain includes batch job monitoring, backups, incident management, and disaster recovery.
Batch job monitoring ensures that scheduled data processing jobs complete successfully. Any failures or anomalies must be logged, investigated, and resolved before they affect downstream financial data. For organizations that rely on overnight batch processing to update ledgers or reconcile accounts, a failed job that goes unnoticed can mean incomplete or inaccurate financial records.
Backup and recovery controls protect against data loss. Two metrics anchor backup planning. The Recovery Time Objective (RTO) defines the maximum acceptable downtime, or how quickly a system must be restored after a disruption. The Recovery Point Objective (RPO) defines the maximum acceptable data loss, measured in time. An RPO of four hours means backups must run at least every four hours, because anything created after the last backup would be lost in a disaster. Auditors look for evidence that these objectives are formally defined and that backup procedures actually meet them.3Ready.gov. IT Disaster Recovery Plan
Disaster recovery and business continuity plans must be tested regularly, not just written and shelved. Testing validates whether the organization can actually recover within its stated RTO and RPO targets. A plan that has never been tested is barely a plan. Physical security controls — restricted access to data centers, environmental monitoring, visitor logging — also fall under IT operations, since physical access to hardware can bypass every logical control in existence.
How ITGCs Differ From Application Controls
Understanding the difference between ITGCs and application controls explains why ITGC failures are so damaging. ITGCs are broad and environmental; they apply across the entire technology landscape. Application controls are narrow and process-specific; they’re embedded in individual software applications to enforce business rules.
A classic application control is the three-way match in a procurement system. The system compares a purchase order, a receiving document, and a vendor invoice, and blocks payment unless all three agree. That control lives inside the procurement application and enforces one business rule. An ITGC, by contrast, might be the access control restricting who can modify the three-way match configuration, or the change management control that governs how the procurement application itself gets updated.
The relationship is hierarchical. Application controls depend on ITGCs for their integrity. If unauthorized personnel can modify application code (a change management failure) or grant themselves elevated access (an access management failure), then application controls can no longer be trusted, because someone may have tampered with them. That’s why auditors test ITGCs first. Under AS 2201, the auditor evaluates general controls over program changes, system access, and computer operations as a prerequisite to relying on automated application controls.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements
There’s also a middle category worth knowing about: IT-dependent manual controls. A person makes the decision, but relies on a system-generated report to do so. A manager reviews an automated exception report each morning and investigates flagged items. The human review is the control, but it only works if the report is accurate, which in turn depends on ITGCs. Auditors assessing these hybrid controls need to verify both the human review process and the reliability of the underlying report.
When ITGCs are found to be ineffective, the auditor typically cannot rely on automated application controls or IT-dependent manual controls in the affected systems. Testing scope expands, often requiring extensive manual transaction testing to compensate for the loss of system-level assurance. That’s expensive, disruptive, and a strong incentive to keep ITGCs healthy.
ITGCs When Systems Live in the Cloud
Most organizations now run critical financial applications on infrastructure they don’t directly control. Cloud platforms, hosted ERP systems, and outsourced data centers all shift some ITGC responsibility to the service provider. The controls don’t disappear. They move. Auditors still need assurance those controls work, even though they can’t walk into the provider’s data center.
The standard mechanism for that assurance is a Service Organization Control (SOC) report. A SOC 1 report focuses specifically on controls at a service organization that are relevant to user entities’ internal control over financial reporting, making it directly applicable to SOX compliance. A SOC 2 report addresses controls related to security, availability, processing integrity, confidentiality, and privacy, which is useful for broader IT risk but less directly tied to financial reporting.4AICPA. System and Organization Controls SOC Suite of Services
Within each type, there are two variants. A Type I report evaluates whether controls are suitably designed as of a specific date. A Type II report goes further, testing whether those controls operated effectively over a period of time (typically six to twelve months). For ongoing ITGC reliance, auditors need a Type II report. A Type I snapshot doesn’t tell you whether the controls actually worked throughout the year.
SOC reports almost always list complementary user entity controls (CUECs), meaning controls the service provider expects your organization to implement on your end. A cloud provider might encrypt data in transit but expect you to manage your own user access provisioning and password policies. If your organization hasn’t implemented the CUECs listed in the SOC report, the overall control environment has a gap the auditor will flag. Reviewing and documenting CUECs before the audit is one of the most commonly overlooked preparation steps.
Why ITGC Failures Get Serious Fast
Not every ITGC failure carries the same weight. Auditors classify control weaknesses into three tiers based on the likelihood and magnitude of potential financial statement misstatement.
- A control deficiency exists when a control’s design or operation doesn’t allow personnel to prevent or detect misstatements in a timely way during their normal work. Something isn’t working right, but the exposure may be limited.
- A significant deficiency is a deficiency, or combination of deficiencies, serious enough to merit attention from those responsible for oversight of financial reporting. Less severe than a material weakness, but a signal of real risk.
- A material weakness is a deficiency, or combination of deficiencies, severe enough that there’s a reasonable possibility a material misstatement in the financial statements won’t be prevented or detected on a timely basis.
Only material weaknesses must be publicly disclosed, and the distinction matters. If an auditor identifies a material weakness, the company cannot conclude that its internal controls are effective, and the auditor’s attestation report will reflect an adverse opinion on internal controls.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements That public disclosure can affect stock price, investor confidence, and regulatory scrutiny.
The SEC treats persistent failures seriously. In a 2019 enforcement action, the SEC charged four public companies for failing to maintain effective internal controls over financial reporting for periods ranging from seven to ten consecutive years. Penalties ranged from $35,000 to $200,000, and one company was required to retain an independent consultant to remediate its material weaknesses.5U.S. Securities and Exchange Commission. SEC Charges Four Public Companies With Longstanding ICFR Failures SEC officials said disclosing material weaknesses is not a substitute for actually fixing them.
ITGC deficiencies are particularly dangerous because of their pervasive nature. A material weakness in access management doesn’t affect just one account or one transaction. It potentially undermines every application and process running on the affected systems. A single ITGC material weakness can force the auditor to expand testing across dozens of application controls.
There’s an upside to healthy ITGCs that goes beyond avoiding findings. AS 2201 allows an auditor to rely on prior testing of an automated application control if general controls are effective and the auditor confirms the specific automated control hasn’t changed since the last test.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements That benchmarking is why organizations invest heavily in keeping ITGCs clean. It directly reduces audit effort and cost year over year.
How ITGCs Get Tested
ITGC testing follows two phases: design effectiveness first, then operating effectiveness. Skipping the design phase is a common mistake. Testing whether a control operated correctly is pointless if the control was poorly designed to begin with.
Design testing takes the form of a walkthrough. The auditor traces a single transaction or event through the entire control process, from initiation to completion, confirming that each step is designed to meet its control objective. Under AS 2201, walkthroughs usually combine inquiry with appropriate personnel, observation of operations, inspection of documentation, and re-performance of the control.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements The question is: if this control works as described every time, would it actually prevent or detect the misstatement it’s supposed to address?
Once design is confirmed, the auditor tests whether the control actually operated as intended throughout the audit period. That involves selecting a sample of transactions or events and examining the evidence for each one. Sample sizes are driven by the frequency of the control. A control that operates with every transaction (like an automated approval workflow) requires a larger sample than one that operates quarterly (like a periodic access review).
Testing procedures are tailored to each domain:
- For access management, auditors select a sample of new user accounts and verify each has a documented, approved access request. They select a sample of terminated employees and confirm accounts were disabled within the timeframe specified by policy. They review the most recent periodic access review for completeness and evidence of follow-up on inappropriate access.
- For change management, auditors select a sample of production changes and examine each for a documented request, independent approval, testing evidence in a non-production environment, and migration approval. They review a sample of emergency changes for after-the-fact documentation and management sign-off.
- For IT operations, auditors verify that backup jobs completed as scheduled and that restore tests were performed. They review batch job monitoring logs for evidence that failures were identified and resolved. They confirm that disaster recovery testing occurred and that results were documented.
After testing, the auditor documents all identified deficiencies, classifies them using the three-tier hierarchy, and communicates them to management. Material weaknesses and significant deficiencies must be communicated in writing to management and to those charged with governance, typically the audit committee. Management develops remediation plans, and the auditor follows up to confirm they get executed. The speed and seriousness of the remediation response often determines whether a significant deficiency escalates into a material weakness in the next reporting period.