ITGC controls, short for information technology general controls, are the foundational policies and procedures that keep an organization’s computer systems secure, reliable, and auditable. They sit beneath every business application a company runs, and when they fail, auditors and regulators treat the data those applications produce as untrustworthy. For publicly traded companies subject to the Sarbanes-Oxley Act, weak ITGCs can trigger material weakness disclosures that erode investor confidence and expose executives to personal liability.
What ITGCs Cover
ITGCs govern the entire technical environment rather than any single piece of software. They address who can log in, how code gets promoted to production, whether backups actually work, and whether the servers themselves are physically secure.
Application controls are a separate thing. Those are built into specific programs: a payroll system that rejects negative hours, an invoicing tool that flags duplicate entries. ITGCs create the conditions under which those application-level checks can be trusted. If the general controls underneath are broken, no automated check running on top of them can be relied on.
Two frameworks dominate how organizations structure their ITGCs. The Control Objectives for Information and Related Technologies (COBIT) framework, published by ISACA, organizes governance and management work across five domains.1ISACA. COBIT – Control Objectives for Information Technologies The Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control-Integrated Framework takes a broader view, wrapping IT controls into five components of internal control: the control environment, risk assessment, control activities, information and communication, and monitoring. Principle 11 of the COSO framework specifically calls for organizations to select and develop general controls over technology.2Committee of Sponsoring Organizations of the Treadway Commission. Internal Control | COSO Most SOX compliance programs map their ITGCs to one or both.
The controls themselves fall into three main categories: access to programs and data, program change management, and computer operations. A fourth area, third-party and cloud risk, has grown into its own domain as more financial systems moved off premises.
Access to Programs and Data
Access controls generate more audit findings than any other ITGC domain, for good reason. If the wrong person can read, change, or delete financial data, nothing else in the control environment matters much. Auditors break this domain into three pieces: authentication (proving you are who you claim to be), authorization (defining what you’re allowed to do), and lifecycle management (granting and revoking access as roles change).
Authentication
Every user needs a unique account. Shared or generic logins make it impossible to trace who did what, which is exactly the kind of gap auditors flag. For authentication strength, NIST Special Publication 800-63B sets the current bar. Passwords used as the sole authentication factor must be at least 15 characters long. When paired with a second factor, the minimum drops to eight.
One change surprises many IT teams: NIST now prohibits mandatory periodic password rotation. Forced resets every 90 days led people to pick weaker passwords and increment a trailing number. Passwords should only be forced to change when there is evidence of compromise.3National Institute of Standards and Technology (NIST). NIST Special Publication 800-63B: Authentication and Lifecycle Management Multi-factor authentication remains essential for higher-risk systems, and NIST’s higher assurance levels require phishing-resistant authenticators such as hardware security keys rather than SMS codes.
Authorization and Least Privilege
Once identity is confirmed, authorization dictates exactly which systems, files, or databases a person can reach. The principle of least privilege means giving employees only the access their current job requires. This is harder to maintain than it sounds. People transfer departments, take on temporary projects, and accumulate permissions that linger long after the need disappears.
Periodic access reviews catch this drift. Auditors typically ask for evidence that someone reviewed the full user list for critical applications at least quarterly, compared each user’s access to their current role, and removed anything unnecessary. Privileged accounts (system administrators, database admins, anyone with elevated rights) deserve special scrutiny. These accounts can bypass normal controls, so the number of privileged users should stay as small as possible, every action taken under those accounts should be logged, and the logs should be reviewed regularly.
Provisioning and De-provisioning
When someone joins the company, provisioning creates their digital identity based on a documented, approved request tied to their role. De-provisioning when someone leaves is where things go wrong most often. Terminated employees whose accounts remain active are one of the most common ITGC audit findings. Best practice is to disable all access on the employee’s last day, coordinated between HR and IT through an automated workflow whenever possible. Delays of even a few days create windows for data theft or unauthorized transactions, and auditors will document every instance where access removal lagged behind the termination date.
Program Change Management
Every update to a production system is a potential point of failure. Change management controls exist to make sure that only tested, approved, documented code reaches the systems that handle live business data. When these controls break down, the consequences range from corrupted transactions to undetected fraud.
The Standard Change Lifecycle
A change starts with a formal request that describes what needs to happen and why. Someone other than the requester evaluates the potential impact. Developers do their work in an isolated environment, walled off from production. Before anything migrates, the code passes through testing that verifies it works as intended and doesn’t break integrated components. Documentation of those test results gets retained as audit evidence.
Segregation of duties is the backbone of this process. The person who writes the code cannot be the same person who promotes it to the production environment. Code changes must be reviewed and approved by someone who was not involved in writing them, and the approval and merging process should be clearly defined in change management documentation.4General Services Administration. CIO IL-22-01 DevSecOps Model – Separation of Duties Final sign-off typically comes from a change advisory board or system owner.
Emergency Changes and Break-Glass Access
Not every change follows the standard lifecycle. When a critical system goes down at 2 a.m. on a Saturday, organizations need a way to act fast without abandoning accountability. Emergency change procedures allow expedited fixes, but they come with compensating controls: the change must still be documented after the fact, reviewed by someone other than the person who made it, and formally approved retroactively.
Break-glass accounts serve a similar purpose for access. These are pre-staged emergency credentials, kept physically secured, that allow authorized staff to bypass normal authentication when systems fail. The accounts should have obvious, distinctive usernames so they stand out in audit logs. Every use triggers an alert, and the audit trail gets reviewed by someone other than the person who used the account. Organizations that skip the retroactive review step tend to see break-glass accounts quietly repurposed for convenience, which is exactly the kind of breakdown auditors hunt for.
Computer Operations
Keeping systems running and recoverable falls under computer operations. This domain covers job scheduling, incident management, backup and recovery, and the physical infrastructure that houses everything.
Job Scheduling and Incidents
Automated job scheduling handles repetitive tasks like batch processing, report generation, and data transfers without manual intervention. When a scheduled job fails, the system should generate an immediate alert. Someone investigates, documents the root cause, and confirms resolution. This trail matters to auditors because an unresolved batch failure can mean transactions never posted or data got processed out of order. Incident management more broadly covers how the organization logs, prioritizes, and resolves system outages, with documented timeframes for escalation and resolution.
Backup and Recovery
Backups that have never been tested are backups that might not work. Organizations perform backups on a defined schedule and store copies in geographically separate locations. The real question auditors ask is whether those backups have actually been restored. Regular restoration testing proves the organization can recover data after a catastrophic failure.
Two metrics drive backup strategy. The Recovery Time Objective (RTO) is the maximum acceptable downtime, meaning how quickly systems must be restored after a disruption. The Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. An RPO of four hours means you can afford to lose up to four hours of transactions. These numbers flow from the business criticality of each system. A trading platform might need an RTO measured in minutes and an RPO near zero, while an internal knowledge base might tolerate a day of downtime. Regulatory frameworks like PCI DSS, HIPAA, and ISO 22301 all require organizations to define and test these objectives for covered systems.
Physical and Environmental Security
The technical controls above don’t help much if someone can walk into the server room unchallenged. Physical security for data centers includes restricting entry to a single controlled access point, using biometric or badge-based authentication, preventing tailgating through anti-passback mechanisms, and monitoring the perimeter around the clock. Visitor access should require sign-in, escort, and sign-out. Environmental controls like fire suppression, temperature regulation, and water detection protect the hardware itself.
Third-Party and Cloud Providers
When financial data lives in a SaaS application or a managed hosting provider, ITGCs don’t stop at the edge of your own network. The vendor’s control environment becomes an extension of yours, and you’re responsible for understanding whether it holds up.
Service Organization Control (SOC) reports are the standard mechanism for this. A SOC 1 report evaluates a service provider’s controls that could affect your financial reporting, which makes it directly relevant to SOX compliance. A SOC 2 report evaluates controls against five Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy. Most organizations that rely on a cloud provider for financially significant data need to obtain and review the SOC 1 report at minimum, often the SOC 2 as well.
Reading those reports matters more than collecting them. SOC reports typically identify Complementary User Entity Controls (CUECs), which are control activities the service provider expects you to implement on your end. A cloud payroll vendor might maintain strong access controls within their platform, but the CUEC section could note that your organization is responsible for promptly disabling terminated users or restricting who can approve payroll runs. If you haven’t mapped those CUECs to your own controls, you have a gap that auditors will find.
How Auditors Test ITGCs
Understanding what auditors look for helps you prepare controls that will actually hold up. Under PCAOB Auditing Standard 2201, the evaluation of IT controls is woven into the top-down, risk-based approach auditors use to identify significant accounts and the controls that protect them. If your program change and access controls are effective, an auditor can conclude that an automated check (like a three-way match in accounts payable) continues to work without retesting it every year.5Public Company Accounting Oversight Board. AS 2201: An Audit of Internal Control Over Financial Reporting If your ITGCs are weak, every application control those systems support needs individual testing, which is much more expensive.
Testing follows a predictable pattern. For access controls, auditors pull a sample of users from critical systems and compare each person’s access to their job role, looking for conflicts or excessive permissions. They sample new hires and terminations to check that provisioning and de-provisioning happened on time with proper authorization. They verify that periodic access reviews were actually performed and documented. For change management, they select a sample of changes deployed during the audit period and trace each one through the lifecycle: was there a documented request, did someone else approve it, was testing performed, did the person who wrote the code stay out of the migration. For operations, they examine backup logs for failures, verify that restoration tests occurred, and review incident tickets for evidence of timely resolution.
Walkthroughs are the starting point. An auditor sits with the person who performs the control, watches them walk through the process, and confirms that the documented procedure matches reality. Testing then confirms the control worked consistently throughout the audit period.
Why ITGCs Matter Under SOX
For publicly traded companies, ITGCs are a legal obligation, not a best practice. Section 404(a) of the Sarbanes-Oxley Act requires management to assess and report on the effectiveness of internal controls over financial reporting in every annual report. Section 404(b) requires the company’s external auditor to independently attest to that assessment.6Securities and Exchange Commission. SEC Proposes Additional Disclosures, Prohibitions to Implement Sarbanes-Oxley Act ITGCs are a critical piece of both because virtually every material financial transaction now flows through IT systems.
Material Weakness Disclosures
When auditors find ITGC deficiencies severe enough to qualify as a material weakness, the consequences hit fast. The company must disclose the weakness publicly, signaling to investors that financial data may not be reliable. IT-related issues have accounted for a growing share of material weakness disclosures; from 2017 to 2018 alone, the percentage of material weaknesses rooted in IT issues rose from 28 percent to 40 percent.
The most common failures that escalate to material weakness involve overlapping breakdowns. An access control gap by itself might be a significant deficiency. Combine it with weak change management, say developers who can also push code to production, and the auditor sees a pattern suggesting that no one is minding the store. At that point, the reliability of every automated control in those systems comes into question.
Personal Liability for Executives
SOX didn’t just create reporting obligations. It created criminal exposure. Under 18 U.S.C. ยง 1350, the CEO and CFO must personally certify that each periodic financial report fully complies with securities law and fairly presents the company’s financial condition. An officer who knowingly certifies a false report faces up to $1,000,000 in fines and 10 years in prison. If the false certification is willful, the penalties jump to $5,000,000 and 20 years.7Office of the Law Revision Counsel. United States Code Title 18 – 1350 Failure of Corporate Officers to Certify Financial Reports When a CFO signs a certification, they are implicitly vouching for the IT controls that produced the numbers.
Building a Program That Holds Up
Organizations that treat ITGCs as a compliance checkbox tend to scramble before every audit cycle. Those that build them into daily operations spend less time remediating findings. A few principles make the difference.
Start by mapping controls to the systems that matter most to financial reporting. Not every server or application needs the same rigor. Focus the heaviest controls on systems that process, store, or report material financial data. Align your ITGC categories to a recognized framework like COBIT or COSO so that auditors can follow your logic without translating between your terminology and theirs.
Automate where you can. Automated provisioning and de-provisioning tied to HR systems eliminates the delay between an employee’s last day and their access being cut. Automated deployment pipelines enforce segregation of duties by design, rejecting code merges from unauthorized users. Automated backup monitoring surfaces failures the moment they happen. The common thread is removing the human step where controls most often fail.
Document everything as it happens, not after the fact. Auditors can’t test a control that has no evidence trail. If your access review happened but nobody saved the spreadsheet showing who reviewed what, the control effectively didn’t happen from an audit perspective. The same applies to change approvals, backup restoration tests, and incident resolutions. Evidence retention is the difference between a clean audit opinion and a finding.