IT General Controls

Introduction
IT General Controls (ITGCs) are one of the most frequently examined topics within the CRMA domain of Evaluating Risk Management Processes. Nearly every organization today relies on information systems to process transactions, store data, and produce the reports management uses to make decisions. If the controls surrounding those systems are weak, every control that depends on them is weakened too. This guide explains why ITGCs matter, what they are, how they operate in practice, and how to approach ITGC questions in the CRMA exam.

Why IT General Controls Are Important
ITGCs are foundational controls. Think of them as the floor on which all automated controls stand. If the floor is unstable, nothing built on top of it can be trusted.

Key reasons ITGCs matter:
1. Reliance on automated controls: Application controls (such as a three-way match in a purchasing system or an automated credit limit check) only work consistently if the underlying system is secure, properly changed, and operating as intended. Weak ITGCs undermine the assurance that can be placed on any automated or IT-dependent control.
2. Data integrity and reporting reliability: Financial, operational, and compliance reporting depends on complete and accurate data. ITGCs protect data from unauthorized change, loss, or corruption.
3. Risk management support: From a CRMA perspective, management uses systems to identify, assess, monitor, and report risks. If risk dashboards or key risk indicators are produced by systems with poor controls, the risk information itself may be unreliable.
4. Regulatory and compliance expectations: Frameworks and regulations such as SOX, GDPR, PCI DSS, and HIPAA expect organizations to demonstrate effective control over access, change, and operations.
5. Pervasive impact: A single ITGC weakness (for example, a shared administrator password) can affect many applications and business processes simultaneously. This pervasiveness is what makes ITGC deficiencies potentially severe.

What IT General Controls Are
ITGCs are policies, procedures, and activities that apply to the overall IT environment rather than to a specific application or transaction. They ensure the proper development, implementation, operation, and maintenance of information systems and the data they hold.

Contrast with application controls, which are specific to an individual application and relate to the completeness, accuracy, validity, and authorization of transactions (for example, input edit checks, reasonableness tests, batch totals, and automated reconciliations). A useful mental model: ITGCs protect the environment; application controls protect the transactions.

Both the IIA GTAG (Global Technology Audit Guide) series and COBIT describe ITGCs, and the commonly tested domains are:

1. Access to Programs and Data (Logical and Physical Security)
Purpose: Ensure only authorized individuals can access systems and data, and only to the extent needed for their role.
Typical controls:
- User provisioning: formal request and approval before an account is created.
- Deprovisioning: timely removal of access when employees leave or change roles.
- Periodic user access reviews (recertification) by business owners.
- Authentication controls: password complexity, expiry, lockout, multi-factor authentication.
- Privileged access management: restricting, monitoring, and logging administrator and superuser accounts.
- Segregation of duties within systems (for example, the person who creates a vendor cannot also approve payments).
- Physical security over data centers and server rooms: badge access, visitor logs, CCTV, environmental controls.

2. Program Change Management
Purpose: Ensure changes to applications, databases, operating systems, and infrastructure are authorized, tested, approved, and implemented in a controlled way.
Typical controls:
- Documented change requests with business and IT approval.
- Separation of development, test, and production environments.
- Independent testing and user acceptance testing (UAT) before migration.
- Segregation of duties: developers should not have the ability to move their own code into production.
- Emergency change procedures with retrospective review and approval.
- Version control and audit trails of changes.
- Configuration management and patch management.

3. Program Development and Acquisition (System Development Life Cycle)
Purpose: Ensure new systems or major upgrades meet business requirements, are developed or acquired through a structured methodology, and are implemented with appropriate controls built in.
Typical controls:
- Project governance and steering committee oversight.
- Defined requirements and sign-off from business owners.
- Design reviews including security and control requirements.
- Testing phases (unit, integration, system, UAT).
- Data conversion and migration controls, including reconciliation of migrated data.
- Post-implementation review.
- Vendor due diligence for purchased or cloud solutions.

4. Computer Operations
Purpose: Ensure systems process data completely and accurately, problems are identified and resolved, and data is protected against loss.
Typical controls:
- Job scheduling and batch processing monitoring with exception follow-up.
- Incident and problem management processes (ticketing, root cause analysis).
- Backup and restoration procedures, including periodic restore testing.
- Business continuity and disaster recovery planning and testing.
- Capacity and performance monitoring.
- Environmental controls (power, cooling, fire suppression).

Some frameworks also list IT governance and organization (IT strategy, policies, risk assessment, roles and responsibilities, third-party management) as a fifth overarching area. In an exam, if you see a question about IT policies, IT steering committees, or IT risk assessment, think of this governance layer.

How IT General Controls Work in Practice
Understanding the mechanics of ITGCs helps you answer scenario-based questions.

The dependency chain: Business process risk -> Application control mitigates the risk -> Application control depends on the system working as designed -> ITGCs ensure the system works as designed and is not changed or accessed inappropriately. If the auditor finds ITGCs ineffective, the auditor cannot rely on the automated application control without compensating procedures (such as extended substantive testing or direct re-performance of the control).

Example scenario: An automated control prevents invoices from being paid unless they match an approved purchase order. This control is only reliable if:
- Nobody can turn the matching rule off (access control).
- The rule has not been altered without approval (change management).
- The system was implemented correctly in the first place (development controls).
- The nightly payment run completes fully and failures are investigated (operations).

Testing ITGCs: Assurance providers typically test ITGCs by:
- Inquiry: interviewing IT and business staff about processes.
- Observation: watching a process being performed (for example, a backup job).
- Inspection: examining evidence such as approved change tickets, access review sign-offs, or termination lists compared against active accounts.
- Re-performance: independently repeating the control (for example, attempting to log in with a terminated user account).
- Data analytics: comparing HR termination data against system access lists to identify timing gaps.

Risk-based evaluation: In a CRMA context, the evaluation of ITGCs should be proportional to the risk. Systems supporting financial reporting, critical operations, or sensitive data warrant deeper testing. The risk practitioner also considers compensating controls; for example, a small organization where developers can access production may compensate with detailed post-implementation log reviews by an independent manager.

Common ITGC Deficiencies Seen in Exam Scenarios
- Terminated employees retaining active accounts.
- Developers having direct update access to production data or code.
- Generic or shared accounts with no accountability.
- Changes implemented without documented testing or approval.
- Backups taken but never tested for restorability.
- No periodic review of privileged users.
- Excessive access granted on the basis of convenience rather than job need.
- Disaster recovery plan exists but has never been exercised.

Relationship to Frameworks
- COSO Internal Control - Integrated Framework: Principle 11 states that the organization selects and develops general control activities over technology. This explicitly places ITGCs within the Control Activities component.
- COBIT: Provides detailed governance and management objectives (for example, Manage Changes, Manage Security Services, Manage Continuity) that map directly to ITGC domains.
- IIA GTAG 1 and GTAG 8: Provide guidance on IT controls and auditing application controls, reinforcing the layered relationship between general and application controls.
- COSO ERM: Technology risk is an enterprise risk; ITGCs are a response strategy that reduces the likelihood and impact of IT-related risk events.

Exam Tips: Answering Questions on IT General Controls

Tip 1 - Classify first. When you read a scenario, immediately ask: is this an ITGC or an application control? If the control is about the environment (who can log in, how changes are made, whether backups run), it is an ITGC. If it is about a specific transaction (validating a field, matching a document, calculating a total), it is an application control. Many questions hinge on this distinction.

Tip 2 - Identify the ITGC domain. Map the scenario to one of the four core domains: access, change management, development/acquisition, or operations. The correct answer usually sits within the same domain as the weakness described. For instance, a question about a programmer moving code to production is a change management and segregation of duties issue, not an operations issue.

Tip 3 - Remember the dependency principle. If a question asks about the effect of an ITGC weakness, the answer almost always relates to reduced reliance on automated and IT-dependent controls, or the need for additional or compensating testing. ITGC weaknesses do not directly cause misstatements; they reduce assurance that other controls are effective.

Tip 4 - Watch for segregation of duties language. Phrases such as developers can migrate their own changes, the database administrator also approves user access, or the same person creates and approves are red flags for SoD violations. Expect the best answer to involve separation of roles or an independent review as a compensating control.

Tip 5 - Prefer preventive over detective, but recognize compensating controls. The exam often favors answers that prevent the problem (restricting access) over those that merely detect it (reviewing logs). However, when the scenario describes a small organization with limited staff, the best answer may be a detective compensating control such as independent log review.

Tip 6 - Evidence matters. Questions about how to test an ITGC expect you to choose the most persuasive evidence. Inspection of documentary evidence (approved tickets, signed access reviews) and re-performance are stronger than inquiry alone. If the question asks for the most reliable procedure, inquiry is rarely correct.

Tip 7 - Timeliness is a recurring theme. Access removal that occurs weeks after termination is a deficiency even if it eventually happens. Backups that are taken but never restore-tested are a deficiency. Look for words like periodically, promptly, and tested in the correct answer options.

Tip 8 - Think in terms of risk, not technology. The CRMA exam is not an IT certification. You will not be asked about firewall configuration syntax. You will be asked about the risk a weakness creates, the control objective, and the appropriate management or assurance response. Always ask: what could go wrong, and what control would reasonably address it?

Tip 9 - Eliminate distractors systematically. Wrong answers often: (a) describe an application control when an ITGC is needed, (b) address a different ITGC domain than the one in the scenario, (c) propose a control that is excessive or impractical for the organization described, or (d) solve a symptom rather than the root cause.

Tip 10 - Know the frameworks at a high level. Be ready to recognize that COSO Principle 11 addresses general controls over technology, that COBIT is the detailed IT governance framework, and that GTAGs are IIA guidance on IT topics. You do not need to memorize detailed control objective numbers, but you should know what each framework is for.

Tip 11 - Link ITGCs to risk management processes. Because this topic sits under Evaluating Risk Management Processes, expect questions that connect ITGCs to the reliability of risk information, the effectiveness of management responses to IT risk, or the role of IT controls within the organization's overall risk appetite and control framework. The strongest answers show awareness that technology risk is an enterprise risk, and that ITGCs are a key management response.

Quick Reference Summary
- ITGCs = controls over the IT environment; application controls = controls over specific transactions.
- Four core domains: Access to programs and data; Program change; Program development and acquisition; Computer operations.
- Weak ITGCs reduce reliance on automated controls and increase the need for compensating or substantive procedures.
- Segregation of duties, timely access removal, approved and tested changes, and tested backups are the most heavily examined themes.
- Evaluate ITGCs on a risk basis, focusing on systems that support critical processes and reporting.
- In the exam: classify the control, identify the domain, consider the risk, and select the answer that addresses root cause with appropriate and proportionate control.

Mastering ITGCs gives you a strong foundation not only for this section of the CRMA but also for understanding how control environments function in any modern organization.