IT general controls are the baseline safeguards over an organization’s technology environment: the rules and processes that govern who can access systems, how changes get deployed, and whether daily operations run reliably. They sit underneath every automated financial process, and for any public company subject to Sarbanes-Oxley, management must assess them in each annual report while an independent auditor attests to that assessment.1Office of the Law Revision Counsel. 15 U.S. Code 7262 – Management Assessment of Internal Controls When these controls break down, every automated process that touches financial data becomes suspect, and the audit consequences cascade fast.
The reason auditors care so much about them is structural. Under PCAOB Auditing Standard 2201, auditors must evaluate general controls over program changes, access to programs, and computer operations before they can place any reliance on automated application controls.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements If the general controls hold up, the auditor can even rely on prior years’ testing of automated controls that haven’t changed, which directly reduces audit effort and cost. If they don’t, the auditor has to expand manual testing across everything those systems touch.
The Three Domains That Make Up IT General Controls
ITGC work is organized around three domains that together cover the technology lifecycle and daily operations. Each targets a different risk to the integrity of financial data, and a weakness in any one can undermine everything downstream.
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 guiding principle is least privilege: every user should have exactly the access required for their job, nothing more. This covers logical access to applications, databases, operating systems, and network infrastructure.
Effective access management depends on a formal lifecycle. New accounts require documented requests and approvals before provisioning. When employees change roles, their access should be reviewed and adjusted. When they leave the organization, accounts must be disabled promptly. Stale accounts for departed employees are one of the most common findings in ITGC audits, and among the easiest to prevent.
Periodic access reviews round out the lifecycle. At least annually, control owners should review all user access rights for critical applications and confirm that each user’s access is still appropriate. Privileged accounts (system administrators, database owners, anyone with elevated permissions) deserve even closer scrutiny, including multi-factor authentication and logging of privileged activity.
Segregation of duties sits at the intersection of access management and business process risk. The principle is simple: 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 of access that could mask fraud. Organizations enforce segregation through access matrices and automated rule sets that flag incompatible combinations before they’re provisioned.
Change Management
Change management controls ensure that modifications to applications, databases, operating systems, and infrastructure follow a documented, authorized process. The risk being controlled 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 change 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. Test results are documented. A separate approval authorizes the 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 the most important control in this domain. When the same person who writes code can push it directly into production without independent review, you’ve lost a critical check. AS 2201 specifically calls out controls over program changes as an area the auditor must evaluate before relying on automated controls.2PCAOB. AS 2201 An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements
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 quickly find themselves 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. When implemented well, automated pipelines actually strengthen change management because they eliminate the human shortcuts that manual processes are prone to. For auditors, the key is verifying that the pipeline configuration itself is protected: who can modify the pipeline rules matters as much 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. This includes batch job monitoring, system backups, incident management, and disaster recovery.
Batch job monitoring ensures that scheduled data processing jobs complete successfully. Failures or anomalies must be logged, investigated, and resolved before they affect downstream financial data. For organizations that rely heavily on overnight batch processing to update ledgers or reconcile accounts, a failed job that goes unnoticed can mean incomplete or inaccurate records.
Backup and recovery controls protect against data loss. Organizations establish backup schedules using two key metrics. The Recovery Time Objective (RTO) defines the maximum acceptable downtime: 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 gone 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 plans 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, like restricted access to data centers, environmental monitoring, and visitor logging, also fall under IT operations, since physical access to hardware can bypass every logical control in existence.
How IT General Controls Relate to Application Controls
Understanding the difference between ITGCs and application controls explains why ITGC failures matter so much. 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, where the software compares a purchase order, a receiving document, and a vendor invoice and blocks payment unless all three agree. That control is specific to the purchasing process within that one application. An ITGC, by contrast, might be the access control that restricts who can modify the three-way match configuration, or the change management control that governs how the procurement application 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. This is why auditors test ITGCs first. Under AS 2201, general controls are 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 understanding: IT-dependent manual controls. These are controls where a person makes the decision but relies on a system-generated report to do so. An example is a manager who 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. When auditors assess these hybrid controls, they verify both the human review process and the reliability of the underlying report.
When ITGCs are ineffective, the auditor typically cannot rely on automated application controls or IT-dependent manual controls in the affected systems. The result is a significant expansion of testing scope, often requiring extensive manual transaction testing to compensate for the loss of system-level assurance. That is expensive and disruptive, and it’s a strong incentive to keep general controls healthy.
ITGCs in Cloud and Third-Party Environments
Most organizations now run critical financial applications on infrastructure they don’t directly control: cloud platforms, hosted ERP systems, outsourced data centers. The ITGCs for these environments don’t disappear. They shift partially to the service provider. Auditors need assurance that the provider’s controls are effective, even though they can’t walk into the provider’s data center and test them directly.
The standard mechanism for that assurance is a Service Organization Control (SOC) report. A SOC 1 report focuses on controls at a service organization that are relevant to user entities’ internal control over financial reporting, which makes it directly applicable to SOX compliance. A SOC 2 report addresses controls related to security, availability, processing integrity, confidentiality, and privacy. That’s useful for broader IT risk assessment 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): controls that the service provider expects your organization to implement on your end. A cloud provider might encrypt data in transit, for example, 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 that the auditor will flag. Reviewing and documenting your CUECs before the audit is one of the most commonly overlooked preparation steps.
How Auditors Test ITGCs and Classify Deficiencies
ITGC testing runs in 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 typically 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 auditor is asking whether the control, if it works as described every time, would 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. Sample sizes are driven by control frequency. 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). Typical procedures by domain:
- Access management: verify that a sample of new user accounts each has a documented, approved access request; confirm that terminated employees’ accounts were disabled within the policy timeframe; and review the most recent periodic access review for completeness and follow-up.
- Change management: examine a sample of production changes for documented request, independent approval, testing evidence, and migration approval; review emergency changes for after-the-fact documentation and sign-off.
- IT operations: verify that backup jobs completed as scheduled and that restore tests were performed; review batch job monitoring logs for evidence of failure resolution; confirm that disaster recovery testing occurred and was documented.
Not all findings carry the same weight. When auditors identify control weaknesses, they classify them into a three-tier hierarchy 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. 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 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. If an auditor identifies one, 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 Public disclosure can affect stock price, investor confidence, and regulatory scrutiny, and SEC officials have emphasized that disclosing material weaknesses is not a substitute for actually fixing them.5U.S. Securities and Exchange Commission. SEC Charges Four Public Companies With Longstanding ICFR Failures
ITGC deficiencies are particularly dangerous because of their pervasive reach. 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, and a single ITGC material weakness can force the auditor to expand testing across dozens of application controls.
Preparing for an ITGC Audit
The difference between a smooth audit and a painful one is almost always preparation. The goal is to have your documentation organized, your control owners identified, and your evidence ready before fieldwork begins.
Scoping comes first. Identify the systems, applications, databases, and infrastructure components that directly support financial reporting. In a SOX context, that means tracing from significant accounts and disclosures back to the applications that process them, and from those applications down to the underlying technology components: operating systems, databases, and network devices. Cloud-hosted applications and third-party providers fall within scope if they process or store data relevant to financial reporting.
Once scope is defined, gather and organize the documentation that describes your control environment:
- IT policies and procedures, including access management, change management, incident response, and backup schedules.
- Current organizational charts showing reporting lines, particularly for IT personnel and system administrators.
- System configuration documentation, including password policies, account lockout settings, logging configurations, and access control lists for critical systems.
- Current Type II SOC 1 reports from any third-party service providers in scope, along with documentation of your implemented CUECs.
- Change logs from ticketing systems showing change requests, approvals, testing evidence, and deployment dates.
Identify every control owner: the person responsible for executing each control day to day. These are the people auditors will interview during walkthroughs, and each must be able to explain how the control works and point to evidence that it operated. Briefing control owners ahead of time on what to expect and what evidence they’ll need to produce saves significant time once fieldwork starts.
After testing, the auditor documents identified deficiencies, classifies them, 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 is then expected to develop and implement remediation plans, and the auditor will follow up to confirm they’re 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.