Skip to main content
Governance Authority
Category: Internal Controls

IT General Controls

Also known as: ITGC, Information Technology General Controls, IT general and application controls (ITGC/ITAC, when referenced together)
Simply put

IT general controls are the policies and practices that govern how an organization's technology is acquired, built, deployed, used, and maintained. They generally apply broadly across an organization's systems, components, processes, and data rather than to a single application or transaction. In practice, they often involve people performing activities within or to systems to keep the technology environment reliable and secure.

Formal definition

ITGC are controls that typically apply pervasively across all of an organization's systems, components, processes, and data for a given information environment, in contrast to IT application controls (ITAC), which operate at the level of a specific application or transaction. They are generally process- or policy-based controls governing the acquisition, architecture, deployment, use, and maintenance of technology. ITGC are commonly evaluated within IT audit and IT governance activities and, alongside ITAC, are used as a model for assessing the maturity of the processes an auditor tests; the specific scope, framework alignment, and testing approach vary by organization, engagement, and applicable requirements, and should be determined through professional judgment. This entry is educational and not legal, audit, or compliance advice.

Why it matters

IT general controls matter because they form the foundation on which many other controls depend. Because ITGC generally apply pervasively across an organization's systems, components, processes, and data, weaknesses in these controls can undermine confidence in the systems that process transactions and produce financial and operational information. When the broad environment governing how technology is acquired, built, deployed, used, and maintained is unreliable, the application-level controls that sit on top of it become harder to rely on.

For assurance and compliance purposes, ITGC are commonly evaluated within IT audit and IT governance activities. Alongside IT application controls, they are often used as a model for assessing the maturity of the processes an auditor has to test, which gives audit and assurance functions a structured way to understand and evaluate the technology environment. The scope, framework alignment, and testing approach are not uniform, however; they vary by organization, engagement, and applicable requirements, and should be determined through professional judgment rather than assumed to be standardized across contexts.

Because ITGC are typically process- or policy-based and frequently involve people performing activities within or to systems, they also require sustained attention from those responsible for maintaining the technology environment. This entry is educational and not legal, audit, or compliance advice, and the specific controls an organization needs will depend on its facts and circumstances.

Who it's relevant to

Internal Auditors
Internal auditors regularly evaluate ITGC as part of IT audit activities. Professional bodies offer certificate programs intended to give internal auditors the minimal technical competencies needed to perform basic IT-related audit activities, reflecting how central these controls are to audit work. ITGC, alongside ITAC, can serve as a model for assessing the maturity of the processes an auditor tests.
IT Governance and Technology Management
Those responsible for governing and managing technology rely on ITGC to set the policies and practices that determine how systems are acquired, architected, deployed, used, and maintained. Because ITGC are often process- or policy-based and involve people performing activities within or to systems, this group typically owns the design and ongoing operation of these controls.
Compliance and Assurance Functions
Compliance and assurance professionals are concerned with ITGC because these controls apply broadly across systems and underpin the reliability of the technology environment. The specific framework alignment, scope, and testing approach vary by organization and engagement, so these functions apply professional judgment when determining how ITGC should be evaluated in a given context.

Inside ITGC

Access to Programs and Data
Controls governing who can access systems, applications, and data, typically covering authentication, authorization, user provisioning and de-provisioning, privileged access, and periodic access reviews. This domain generally aims to enforce segregation of duties and restrict access to what is appropriate for a user's role.
Program Change Management
Controls over how changes to applications and infrastructure are requested, approved, tested, and migrated to production. These typically address authorization of changes, separation of development and production environments, and evidence that changes were tested before deployment.
Program Development
Controls over the acquisition, development, and implementation of new systems, generally covering project approval, testing, data conversion, and authorization to go live. This domain is related to but distinct from ongoing change management.
Computer Operations
Controls over the day-to-day running of systems, typically including job scheduling and monitoring, incident and problem management, backup and recovery, and data processing integrity. The scope and relevance of specific operations controls vary by environment and by the reliance placed on automated processing.

Common questions

Answers to the questions practitioners most commonly ask about ITGC.

Are IT general controls the same as application controls?
No. IT general controls (ITGCs) and application controls are distinct, though related, control types. ITGCs are the pervasive controls over the IT environment, typically covering areas such as access management, change management, IT operations, and program development, that support the reliable functioning of applications. Application controls, by contrast, are embedded within a specific application or business process (for example, input validation, calculation logic, or automated reconciliations) and address the completeness and accuracy of individual transactions. A common view is that effective ITGCs presume, but do not guarantee, that application controls operate reliably; if ITGCs are weak, the assurance that can be placed on automated application controls is generally reduced. The precise scope of each category depends on the framework applied and the judgment of the assessing function.
Does having IT general controls in place mean data and financial reporting are automatically accurate?
Not on their own. ITGCs are generally supporting or foundational controls; they help ensure that the systems processing data function as intended and that unauthorized changes are prevented or detected. They typically do not, by themselves, confirm that individual transactions or reported figures are complete and accurate, that assurance usually depends on application controls and business process controls layered on top. It is also important to distinguish control design from operating effectiveness: ITGCs may be well designed yet fail to operate consistently over a period, or vice versa. Whether reliance can be placed on system-generated information is a matter of professional judgment based on the combined assessment of ITGCs and the related controls.
Which functions typically own and assess IT general controls, and where does accountability sit?
Ownership and assurance are generally separated across the lines of defense, though terminology and structure vary by organization. Management, commonly the IT function and business process owners, typically designs, implements, and operates ITGCs as a first-line responsibility. A second-line function may set policy, standards, and risk oversight for the IT control environment. Internal audit or an equivalent assurance function generally provides independent evaluation of control design and operating effectiveness, without owning the controls themselves. The board, often through an audit committee, typically holds oversight responsibility rather than operational responsibility. External auditors may assess ITGCs to the extent relevant to their engagement scope. The specific allocation should be confirmed against the entity's own governance structure.
How are IT general controls commonly grouped when scoping an assessment?
Assessments frequently organize ITGCs into a small number of domains, though naming and boundaries differ across frameworks and organizations. Typical groupings include access to programs and data (such as user provisioning, authentication, and segregation of duties), program change management (controls over how changes to systems are requested, tested, approved, and migrated), program development (controls over new system implementations), and computer operations (such as job scheduling, backup, and incident management). Scoping generally begins by identifying the systems and data most relevant to the objective, often financial reporting or a specific compliance obligation, and then mapping the ITGC domains to those systems. Scope depends on the entity's risk assessment, the objective of the review, and applicable requirements.
How can control design be distinguished from operating effectiveness when testing ITGCs?
These are two separate evaluation questions and are generally tested in sequence. Assessing design effectiveness typically asks whether a control, if operating as intended, would achieve its objective, for example, whether an approval requirement in a change management process is capable of preventing unauthorized changes. Assessing operating effectiveness typically asks whether the control actually functioned consistently over a defined period, which usually involves examining evidence across a sample of instances rather than a single point in time. A control may be well designed but operate ineffectively (for instance, approvals were bypassed), or it may operate as documented yet be poorly designed for the risk. Both conclusions rest on the evidence gathered and the assessor's judgment.
What are the practical implications when IT general controls are found to be deficient?
When ITGC deficiencies are identified, a common consequence is that reliance on automated controls and system-generated information supported by those ITGCs may need to be reconsidered. For example, weaknesses in change or access controls can undermine confidence that dependent application controls operated reliably, which may lead to expanded testing, compensating controls, or alternative procedures. The significance of a deficiency generally depends on factors such as the affected systems, the potential effect on the relevant objective, and whether other controls mitigate the risk. Evaluating severity, remediation, and any reporting obligations is a matter of professional judgment and, where applicable, framework or regulatory requirements; this entry is educational and not audit, legal, or compliance advice.

Common misconceptions

ITGCs are the same as application controls, so testing one covers the other.
ITGCs and application controls are distinct. ITGCs generally operate at the environment level (across systems and applications) and support the continued effective operation of automated application controls, but they do not test the specific business-process logic that application controls perform. Reliance on automated application controls typically depends on ITGCs being effective, yet each is assessed separately.
Well-designed ITGCs mean the controls are operating effectively.
Control design and operating effectiveness are different attributes. A control can be designed appropriately but fail in operation, for example, if access reviews are defined but not performed consistently. Assurance over ITGCs generally requires evaluating both whether the control is suitably designed and whether it operated as intended over the relevant period.
ITGCs are solely an IT department responsibility.
Design and operation of many ITGCs typically sit with IT and system owners as a management (first line) responsibility, but accountability for the overall control environment rests with management broadly, and assurance functions such as internal and external audit may evaluate them independently. Who owns, operates, and provides assurance over a given ITGC should be clearly distinguished rather than assumed to be a single function.

Best practices

Map ITGCs to the specific automated controls and financially or operationally significant applications they support, so reliance on application-level controls is justified by the underlying general controls.
Assess both control design and operating effectiveness separately, and gather evidence that controls operated throughout the relevant period rather than at a single point in time.
Clarify ownership and accountability for each ITGC domain, distinguishing the management and system owners who operate controls from the assurance functions that evaluate them.
Prioritize access and change management controls, including periodic access reviews, segregation of duties, and separation of development and production environments, as these commonly carry the greatest risk.
Tailor the scope of computer operations controls, such as backup, recovery, and job monitoring, to the actual environment and the degree of reliance placed on automated processing, rather than applying a generic checklist.
Document remediation and compensating controls when a deficiency is identified, and consider the potential impact on any automated controls that depend on the affected ITGC.