Skip to main content
Regulatory Council
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Category: Internal Controls & Audit

General IT Controls

Also known as: ITGC, IT General Controls, Information Technology General Controls
Simply put

General IT controls are the policies and procedures an organization puts in place to manage and protect the technology systems that support its business activities. They cover how IT systems are acquired, built, deployed, used, and maintained, and they apply broadly across an organization's systems, data, and processes rather than to a single application. Their purpose is to help ensure that IT systems operate reliably and securely so the information they produce can be trusted.

Formal definition

General IT Controls (ITGC) are pervasive controls that apply across an organization's information systems, components, processes, and data, as distinct from application controls that are embedded within specific applications or transactions. Typically maintained over the IT environment as a whole, often the functions of the IT or MIS support unit, ITGC commonly address domains such as access and identity management, change management, system acquisition and development, and IT operations. In an audit context, ITGC are frequently tested to establish the reliability of the underlying IT environment on which application-level controls and financially significant reporting depend; weaknesses in ITGC can undermine reliance on otherwise effective application controls. The precise scope, control objectives, and testing approach vary by organization, sector, applicable frameworks, and regulatory context, and specific requirements should be confirmed against the relevant standards and primary sources.

Why it matters

General IT controls matter because most modern organizations depend on information systems to record transactions, safeguard data, and produce the reports that management, auditors, and regulators rely on. When the underlying IT environment is well governed, the information those systems generate can generally be trusted. When ITGC are weak, that trust erodes: even an application control that appears to work may not be reliable if unauthorized users can change data, if untested code can be moved into production, or if system operations are not properly monitored. For this reason, ITGC are often treated as foundational to the reliability of the broader control environment.

In an audit context, ITGC frequently determine how much reliance can be placed on application-level controls and on financially significant reporting. Because ITGC apply pervasively across systems, components, processes, and data rather than to a single application, a deficiency in a shared control domain, such as access management or change management, can affect many downstream processes at once. Auditors commonly test ITGC precisely to establish whether the IT environment as a whole provides a dependable basis for the controls that sit on top of it.

It is important to note that the specific scope, control objectives, and testing approaches for ITGC vary by organization, sector, applicable frameworks, and regulatory context. What constitutes an adequate control set in one environment may be insufficient or excessive in another, and specific requirements should be confirmed against the relevant standards and primary sources rather than assumed.

Who it's relevant to

Internal Auditors
Internal auditors evaluate whether ITGC are designed and operating effectively, often testing them to establish the reliability of the IT environment before placing reliance on application controls or system-generated reports. Professional certificate programs exist specifically for internal auditors seeking to demonstrate mastery of IT general controls.
IT and MIS Functions
The IT or MIS support unit typically maintains ITGC across the systems it operates for all business units. These teams design and run the processes for access management, change management, system development, and IT operations that the controls govern.
Compliance Officers
Compliance professionals rely on ITGC to help demonstrate that systems supporting regulated activities and financially significant reporting operate reliably and securely. Because applicability varies by jurisdiction, sector, and framework, they should confirm specific requirements against the relevant standards and primary sources.
Risk Managers
Risk managers are concerned with ITGC because weaknesses in pervasive control domains can affect many processes at once and can undermine reliance on otherwise effective application controls. Understanding the state of ITGC helps inform the assessment and treatment of technology-related risk.
External Auditors
External auditors frequently test ITGC to determine how much reliance can be placed on application-level controls and on financially significant reporting. The scope and testing approach depend on the organization, sector, and applicable audit and regulatory frameworks.

Inside ITGC

Access Controls (Logical Security)
Controls governing who can access systems, applications, and data, typically covering user provisioning and de-provisioning, authentication, authorization, privileged access management, and periodic access reviews. These controls support the principle of least privilege and appropriate segregation of duties within IT environments.
Change Management
Controls over how modifications to systems, applications, and infrastructure are requested, tested, approved, and migrated into production. This typically includes separation between development and production environments and authorization of changes prior to deployment, helping reduce the risk of unauthorized or erroneous changes.
IT Operations
Controls over the day-to-day running of IT systems, often including job scheduling and monitoring, incident and problem management, backup and recovery processes, and physical and environmental safeguards for data center or hosting facilities. These controls support the availability and integrity of systems that underpin financial and operational reporting.
System Development and Acquisition
Controls over the implementation of new systems or significant upgrades, which may include requirements definition, testing, data conversion validation, and approval before go-live. Scope and rigor commonly vary depending on whether systems are developed in-house, purchased, or delivered through third-party or cloud arrangements.
Relationship to Application Controls
ITGC operate at the environment level and are generally considered foundational to the reliability of automated application controls and system-generated reports. Weaknesses in ITGC can undermine reliance on application-level controls, which is why the two are typically assessed together rather than in isolation.

Common questions

Answers to the questions practitioners most commonly ask about ITGC.

Are General IT Controls the same as application controls?
No. General IT Controls (ITGC) are pervasive controls over the IT environment, such as access management, change management, and IT operations, that support the reliable functioning of multiple systems and applications. Application controls, by contrast, are typically embedded within a specific application and address the completeness, accuracy, and validity of processing for that application (for example, input validation or automated calculations). The two categories are related and often work together, since application controls frequently depend on effective ITGC, but they operate at different levels and should not be treated as interchangeable.
Do ITGC directly ensure the accuracy of financial reporting?
Not directly. ITGC are generally considered indirect or foundational controls: they support the continued effective operation of the automated controls and system-generated data on which reporting may rely, rather than themselves validating individual transactions or balances. In many control frameworks, a weakness in ITGC can undermine reliance on the application-level and automated controls above them, but ITGC are typically viewed as enabling other controls to function reliably rather than as a guarantee of reporting accuracy. Reliance on any control depends on its design and operating effectiveness in the specific context.
Which control domains are commonly included within ITGC?
In common practice, ITGC are often organized into domains such as access to programs and data (including logical access, authentication, and segregation of duties), program change management (authorization, testing, and approval of changes to systems), program development or system implementation, and IT operations (such as batch processing, job scheduling, backup, and incident management). The exact grouping and terminology vary by framework, auditor methodology, and organization, so the specific domains should be aligned with the relevant standard or guidance applicable in your context.
How do ITGC apply when systems are hosted by a third-party or cloud provider?
When systems are outsourced or hosted externally, responsibility for ITGC is typically shared between the organization and the provider, and the boundaries depend on the service model and contractual arrangements. Organizations often rely on independent assurance reports over a service provider's controls, and may need to consider complementary controls that remain their own responsibility, such as user access administration on their side. The scope of what the provider covers versus what the organization must control independently should be confirmed against the assurance report and the service agreement, and this can vary considerably by arrangement.
How should the scope of ITGC be determined for an assessment?
Scoping commonly follows a risk-based approach that starts from the objectives being supported, such as financial reporting reliability or a specific compliance obligation, and works down to the applications, databases, operating systems, and infrastructure relevant to those objectives. The scope generally focuses on systems that support in-scope automated controls or system-generated data. Because scoping decisions involve judgment and depend on the applicable framework and objectives, they are typically documented and revisited as the environment changes.
What is the relationship between ITGC and segregation of duties?
Segregation of duties is often addressed within the access management domain of ITGC, since access controls are a primary means of enforcing that incompatible functions, such as initiating and approving a change, or developing and deploying code, are not concentrated in a single individual. Segregation of duties can, however, also be a concern at the business-process and application level, so it is not exclusively an ITGC matter. How it is classified depends on the framework and the specific process being evaluated.

Common misconceptions

ITGC are the same as application controls.
They operate at different levels. ITGC are pervasive, environment-level controls (such as access, change management, and operations) that support the IT infrastructure broadly, whereas application controls are embedded within specific applications to ensure the completeness and accuracy of individual transactions. In many frameworks, effective ITGC are considered a precondition for placing reliance on automated application controls.
Strong ITGC guarantee data integrity and prevent breaches.
No control set eliminates risk. ITGC are designed to modify and reduce risk to the systems supporting an organization's objectives and reporting, but they do not guarantee outcomes. Residual risk typically remains, and control effectiveness depends on consistent operation, appropriate design, and factors outside IT's direct control.
ITGC apply only where systems are developed and hosted in-house.
ITGC concepts extend to purchased software, outsourced processing, and cloud arrangements, though the way controls are designed, evidenced, and tested often shifts. In third-party or cloud contexts, organizations frequently rely on service provider assurance while retaining responsibility for controls within their own scope; the precise allocation depends on the arrangement.

Best practices

Map ITGC to the applications and system-generated reports that support financial and operational objectives, so that control scope reflects where reliance is actually placed.
Enforce least privilege and periodic access reviews, with particular attention to privileged and administrative accounts and to timely de-provisioning of leavers and role changes.
Maintain clear separation between development, test, and production environments, and require authorization and testing before changes are migrated into production.
Establish and periodically test backup, recovery, and incident management processes rather than assuming their effectiveness, and document evidence of testing.
For outsourced or cloud arrangements, define which controls the organization retains versus those relied upon from the service provider, and obtain appropriate assurance over provider controls.
Assess ITGC together with the application controls and reports they support, since ITGC weaknesses can undermine reliance on otherwise well-designed automated controls.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.