.avif)
%201.svg)
HIPAA Compliance Checklist for 2025
A 2024 PCAOB inspection report found that nearly 39% of audits were flagged for control or evidence deficiencies. The controls existed. The documentation didn't hold up.
That gap between having ITGC controls and being able to prove they work is where most enterprises get caught. This guide covers the five ITGC control types, real examples for each, and exactly what auditors inspect when they test them.
TL;DR
- ITGC controls are foundational IT policies that protect financial data integrity and system reliability across SOX, SOC 2, and ISO 27001.
- The five ITGC control types are: logical access, change management, IT operations and backup, physical and environmental security, and SDLC.
- Each type carries a control function: preventive, detective, or corrective. Auditors test all three.
- ITGC controls differ from IT Application Controls (ITACs): ITGC covers the environment; ITACs operate inside specific applications.
- Most audit failures are evidence failures, not control failures. The control ran. The documentation couldn't prove it.
1. ITGC vs. ITAC: A Distinction Auditors Will Test You On
ITGC controls govern the IT environment itself: who can access systems, how changes are managed, how data is backed up, and how operations are monitored.
IT Application Controls (ITACs) are embedded within specific applications, such as input validation, automated calculations, and workflow enforcements inside an ERP or billing platform.
The relationship matters. If ITGC controls are weak, auditors will question the reliability of every ITAC that depends on them. A financial calculation automated inside your ERP is only trustworthy if the access and change management controls around that ERP are sound. ITGC controls are the foundation. ITACs sit on top.
2. The 5 ITGC Controls Types: What They Cover and What Breaks Without Them
1. Logical Access Controls
Logical access controls govern who can access systems, applications, and data, and under what conditions. This is the most scrutinized domain in every SOX and SOC 2 audit.
What it covers: user provisioning and deprovisioning, role-based access, MFA, privileged account management, password policies, and Segregation of Duties (SoD).
Examples:
- An employee moves from finance to marketing. Their ERP access is updated. Old finance permissions are revoked within 24 hours.
- A contractor account is set to auto-expire after 90 days, with an alert if it remains active past the deadline.
- An admin account requires MFA plus manager approval before elevated permissions are granted for a specific task window.
What breaks without it: A terminated employee retaining system access for four months is an access control failure. So is a developer who can both write to production and approve their own changes. According to CloudEagle.ai's IGA Report, 95% of enterprises still rely on manual access reviews. That is where most access control findings originate.
2. Change Management Controls
Change management controls ensure every modification to a financially significant system, whether a patch, configuration change, or code deployment, is documented, approved, tested, and traceable.
What it covers: change request documentation, independent dual approval, pre-production testing, rollback planning, and version control.
Examples:
- A developer submits a change request to update a payroll calculation. A second engineer reviews and approves. QA documents test results. The change is promoted to production with a logged timestamp.
- No single developer can push to production without a peer review on record.
What breaks without it: One developer pushing directly to production without a second sign-off is a finding. Auditors also flag changes where the rollback plan was verbal, testing was undocumented, or ticket records were created after the fact.
3. IT Operations and Backup Controls
This domain covers the reliability of day-to-day IT operations: backup schedules, job monitoring, incident response, and the ability to recover data when something goes wrong.
What it covers: backup completion logs, recovery testing, batch job monitoring, exception reporting, patch management, and incident response documentation.
Examples:
- Daily ERP backups are logged automatically. Monthly restore tests verify recoverability. Results are documented and reviewed by IT management.
- Batch job failures trigger automated alerts. Each exception is logged, investigated, and resolved within a defined SLA.
What breaks without it: Auditors don't check whether backups are scheduled. They check whether they can actually be restored. A backup that has never been tested is an unverified control. That is a finding.
4. Physical and Environmental Security Controls
Physical controls protect the hardware, data centers, and infrastructure that underpin IT systems. In cloud-first environments, these responsibilities largely shift to vendors, but the obligation to verify them stays with the enterprise.
What it covers: data center access (biometrics, key cards, CCTV), environmental monitoring (temperature, fire suppression, power redundancy), hardware disposal procedures, and vendor SOC reports for physical infrastructure.
Examples:
- Server room access is restricted to IT operations staff via a biometric scanner. Access logs are reviewed quarterly.
- A cloud vendor's SOC 2 Type II report is reviewed annually to verify physical controls meet the organization's requirements.
- Decommissioned hardware goes through certified data destruction, with a documented certificate retained for audit.
5. System Development and Acquisition Controls (SDLC)
SDLC controls govern how new software is built, tested, acquired, and released into production, ensuring applications meet security and compliance standards before touching financial data.
What it covers: dev and production environment segregation, code review requirements, UAT documentation, vendor security assessments, and implementation standards.
Examples:
- Development, staging, and production environments are strictly segregated. Developers have no direct access to production data.
- Every new SaaS tool that will process financial data goes through a security assessment before procurement is approved.
What breaks without it: Environments that blur the line between development and production create access control and change management failures simultaneously. A developer who can test and deploy to production is a SoD violation and a change management gap in one account.
3. Preventive, Detective, Corrective: The Function Layer Auditors Check Across Every Type
Every ITGC control also has a function. Organizations often have strong preventive controls but run detective controls inconsistently, and that imbalance is where findings appear.
A fourth function, compensating controls, applies when a primary control cannot be implemented. For example, a small team where SoD is structurally infeasible might implement enhanced logging and management review as compensating controls. Auditors accept these if they are documented, proportionate to the risk, and consistently applied.
Stale Access Is Your Most Common Audit Finding.
4. How SOX, SOC 2, and ISO 27001 Each Use ITGC Controls
The five ITGC control types apply across all three frameworks. What differs is the scope, evidence standard, and the consequences of gaps.
One important distinction: holding ISO 27001 certification does not mean ITGC controls are audit-ready for SOX or SOC 2. ISO 27001 covers the information security management system broadly. SOX and SOC 2 test controls specifically tied to financial reporting integrity. Treat them as complementary.
For a deeper look at SOX-specific ITGC obligations, the SOX 302 Compliance Guide for IT Teams breaks down exactly what Sections 302 and 404 require from IT.
5. How to Test ITGC Controls: Evidence Requirements by Type
The control exists. The test confirms it ran. But most evidence packages fall apart because they prove execution, not design quality. Here is what auditors actually inspect, by type.
Knowing how to test ITGC controls per domain, rather than generically, is what separates evidence that holds up from evidence that gets challenged in fieldwork.
Your Controls Ran. Can You Prove It?
6. What Clean ITGC Controls Programs Actually Look Like
Teams that pass audits without drama aren't the ones with the most controls. They're the ones whose access reviews ran when they were supposed to, whose evidence existed before the auditor asked for it, and whose deficiencies were documented and owned before anyone external saw them.
The difference is rarely design. It is consistency, documentation, and the discipline to treat ITGC controls as a continuous program rather than an annual scramble.
7. FAQs
What are the 5 ITGC control types?
Logical access controls, change management controls, IT operations and backup controls, physical and environmental security controls, and SDLC controls. Each maps to one or more control functions: preventive, detective, or corrective.
What are the 4 domains of ITGC?
Some frameworks group ITGC into four domains: access controls, change management, computer operations, and SDLC. The five-type model adds physical security as a distinct category. Both groupings cover the same underlying controls.
What is the difference between ITGC and ITAC?
ITGC controls govern the IT environment broadly. ITACs are embedded within specific applications and govern inputs, calculations, and automated workflows inside those tools. Weak ITGC controls undermine the reliability of every ITAC that depends on them.
How are ITGC controls tested?
Through inquiry, observation, inspection, re-performance, and CAAT. Most findings are evidence failures: the control ran, but the documentation couldn't prove how, when, or by whom.
What are examples of ITGC controls? What are the most common ITGC controls examples?
MFA enforcement for privileged accounts (preventive, logical access), quarterly user access reviews (detective, logical access), dual approval for production deployments (preventive, change management), monthly backup restore testing (detective, operations), and dev/production environment segregation (preventive, SDLC).
.avif)
.avif)
.avif)
.png)
