Continue your mission
IT General Controls are the foundational IT controls tested in every major audit framework: SOX 404, SOC 1, SOC 2, and most compliance certifications. They govern access, change management, computer operations, and software development across the entire IT environment.
# IT General Controls (ITGC)
IT General Controls (ITGCs) are the foundational controls that govern how IT systems are accessed, changed, operated, and developed across an organization. Unlike application controls, which are specific to a single business process or application (such as the three-way match in accounts payable), ITGCs apply broadly to the entire IT environment. They are the baseline layer of IT discipline that every other control depends on.
ITGCs matter because they are the controls tested in virtually every major audit framework. SOX Section 404 audits, which affect all U.S. public companies, require management and external auditors to assess and opine on the effectiveness of internal controls over financial reporting. A significant portion of that assessment is ITGC testing, because financial systems depend on the IT environment, and if the IT environment is not controlled, the outputs of financial systems cannot be relied upon. SOC 1 audits (service organization controls relevant to financial reporting) similarly center ITGC testing. SOC 2 audits (trust services criteria for security, availability, processing integrity, confidentiality, and privacy) test ITGC-equivalent controls across the Trust Services Criteria.
The term originates in the auditing world, where AICPA and ISACA began formalizing ITGC guidance in the 1980s. The conceptual framework has remained stable as underlying technology evolved from mainframe batch processing to cloud-native microservices.
Within the Planetary Defense Model, ITGCs span two primary domains: RGA (Risk Governance and Assurance) and IAT (Identity Access and Trust). The access control category of ITGCs is the practical implementation of IAT's Zero Possession Architecture methodology. The change management and computer operations categories are governance-layer controls that live squarely in RGA. The SDLC (software development lifecycle) controls bridge both domains, governing how new capabilities are built and deployed into the controlled environment.
ITGCs are organized into four categories: Access Controls, Change Management, Computer Operations, and Program Development. Auditors test controls in all four categories during SOX 404, SOC 1, and most SOC 2 engagements.
Category 1: Access Controls
Access controls govern who can access IT systems, under what conditions, and with what level of privilege. This is the ITGC category with the most direct connection to the Identity Access and Trust domain of the Planetary Defense Model.
User provisioning controls ensure that access rights granted to new employees or contractors are appropriate to the job function requiring them. The auditor's test is: select a sample of new user accounts created during the audit period. Verify that each account was provisioned following a formal request, that the request was approved by the appropriate manager, and that the access granted matches what was requested and approved. Provisioning without documented, manager-approved requests is a finding.
Deprovisioning controls ensure that access is removed promptly when employees leave the organization or change roles. This is one of the most commonly tested and most commonly failed ITGCs. Auditors select a sample of employees who terminated during the audit period and verify that their accounts were disabled within the timeframe specified in policy (commonly 24 hours for voluntary terminations, immediately for involuntary). Organizations that disable network accounts but leave application accounts active, or that retain service account credentials associated with departed employees, receive findings for incomplete deprovisioning.
Privileged access management controls address the elevated-risk population of administrator accounts, root accounts, service accounts, and other high-privilege credentials. Auditors test that privileged access is granted only to individuals with a documented business need, that the inventory of privileged accounts is maintained and reviewed, that privileged activity is logged and monitored, and that break-glass or emergency access procedures are documented and followed. Undocumented privileged accounts, shared administrator credentials, and privileged users without activity monitoring are all common findings.
Periodic access reviews (also called user access recertifications) are the process of regularly reviewing and certifying that existing access rights remain appropriate. Auditors verify that access reviews were completed on schedule (commonly quarterly for high-risk systems and annually for others), that the reviews were conducted by an appropriate certifier (typically the direct manager or system owner), that inappropriate access identified during the review was removed, and that the completed reviews are documented. Access reviews not completed on schedule, or completed as rubber-stamp exercises without genuine evaluation, are among the most frequent ITGC findings.
Category 2: Change Management
Change management controls govern how modifications to production systems, applications, and configurations are authorized, tested, and deployed. The auditor's fundamental question in change management is: could an unauthorized or untested change be made to a production system?
The change approval process requires that every change to a production system be documented in a change request, reviewed and approved by an appropriate authority (typically a change advisory board or designated approver), and executed against the approved scope. Auditors sample production changes during the audit period and verify that each has a corresponding approved change ticket. Changes deployed without tickets, or tickets approved after deployment (retroactive approval), are findings.
Separation of duties is the principle that the person who writes code or configures a system should not be the same person who deploys that change to production. This prevents a single individual from introducing unauthorized changes without oversight. In practice, separation of duties in software development means developers have read access to production environments for troubleshooting but cannot directly deploy to production. Only authorized release engineers or automated deployment pipelines with appropriate controls can execute production deployments. Organizations where developers deploy directly to production, particularly cloud environments where IAM policies have not been configured to enforce this separation, frequently receive separation of duties findings.
Emergency change procedures address the reality that urgent production fixes sometimes need to be deployed outside the standard change process. Auditors test that emergency changes are documented, that post-hoc approval was obtained within a defined timeframe, that the number of emergency changes is reasonable and not a workaround for weak standard change controls, and that emergency access granted for the change was revoked after it was completed.
Category 3: Computer Operations
Computer operations controls address the day-to-day running of IT systems, with particular focus on the reliability and recoverability of systems supporting financial processes.
Job scheduling controls verify that critical batch processes (end-of-day financial closes, data feeds from operational systems to financial systems, reporting jobs) run as expected and that failures are detected and resolved. Auditors look for evidence that job completion is monitored, that failure alerts are sent to appropriate teams, and that there is a documented escalation path for critical job failures.
Backup and recovery controls verify that data is backed up according to policy and that backup integrity is tested through periodic restoration exercises. This is an area where many organizations have the backup process running but lack documentation of restoration testing. Auditors want to see evidence that backups were tested, that the test validated that data could actually be recovered, and that the test results were reviewed by an appropriate authority. Backups that run but have never been tested for restorability do not provide the assurance the control is intended to deliver.
Incident management controls verify that security and operational incidents are identified, escalated, and resolved through a documented process. Auditors sample incident tickets from the audit period and verify that incidents were categorized, that escalation followed documented procedures, and that resolution was documented. Incidents resolved without documentation, or where the same incident recurs repeatedly without root cause analysis, raise concerns about the effectiveness of the incident management process.
Category 4: Program Development (SDLC)
SDLC controls govern how new systems, applications, and major enhancements are built, tested, and deployed. Auditors verify that new systems are authorized, tested, and documented before processing financial transactions or other in-scope data. Testing requirements mandate that defined phases (unit, integration, user acceptance) complete before production deployment, with results reviewed, approved, and defects resolved. Systems moved to production without documented UAT completion, or with open critical defects, are findings. Documentation requirements verify that new systems are supported by sufficient technical records (system descriptions, data flows, user access models) for audit and operational use. Projects completed without documentation that matches what was actually built create evidence gaps auditors flag.
ITGCs are foundational in the most literal sense: they are the layer of IT discipline that every other control depends on. An access control in an accounting application means nothing if ITGC access management is so weak that accounts can be created without oversight. An application-level segregation of duties control is irrelevant if the change management ITGC allows developers to deploy arbitrary changes without review.
For public companies, ITGC failures have direct legal consequences. A material weakness in internal controls over financial reporting, disclosed in a 10-K under SOX 404, signals to investors and regulators that financial statements may not be reliable. Material weaknesses in ITGC categories (most commonly access management and change management) have produced SEC enforcement actions, securities litigation, and significant reputational damage.
For service organizations, ITGC failures in a SOC 1 Type II audit undermine the opinion customers rely on to reduce vendor risk. A qualified opinion or significant exceptions in the ITGC categories tells customers that controls over systems processing their data are not operating as described.
Common Failure Patterns
The same ITGC failures appear with striking consistency across organizations. Access reviews not completed on schedule are the single most common finding across every audit framework. Terminated employee accounts not disabled within policy timeframes appear in findings at organizations of every size. Production changes deployed without documented approval are typical in engineering-driven cultures that have not integrated change management discipline into their workflows. Backup testing not documented (backups run but restorability never verified) is endemic when operations teams run and test their own backups without independent oversight. Privileged account inventories drift out of accuracy in cloud environments where administrators provision dynamic resources without updating the registry.
ITGC testing follows a consistent pattern: auditors identify the population of control-relevant events during the audit period, select a sample, and test each item against the control requirement. PCAOB AS 2315 and AICPA SOC standards govern sample sizes: high-frequency controls (daily job scheduling) yield populations of 250-plus and auditors typically sample 25 to 40 items; low-frequency controls (quarterly access reviews) produce populations of 4, and auditors test all of them. When a primary ITGC fails on sample items, auditors assess whether compensating controls (monitoring, anomaly detection) provide equivalent assurance. Compensating controls are legitimate but require documented justification from both management and the auditor.
Continuous Controls Monitoring
GRC platform integrations extend naturally to continuous ITGC monitoring. Access review completions are tracked in real time. Terminated employee account disable timelines are measured automatically. Change ticket approval timestamps are cross-referenced against deployment timestamps to flag bypassed approvals. This continuous monitoring converts ITGC compliance from a periodic exercise into an ongoing operational discipline, catching control failures when they occur rather than when auditors arrive.
Key Frameworks
COBIT (maintained by ISACA) is the governance framework most commonly used to structure ITGC programs, mapping IT governance objectives to control practices and providing a maturity model. NIST SP 800-53 provides the technical control catalog, particularly for access control and configuration management.
CDA's Perpetual Compliance Assurance methodology treats ITGC compliance as a continuous operational function, not a pre-audit exercise. Access controls are monitored through automated identity provider integrations: provisioning and deprovisioning actions are logged continuously, access review completions are tracked in real time, and privileged account inventories are synchronized with the IAM system rather than reconciled manually on a quarterly basis. Change management controls are verified through CI/CD pipeline integration: every production deployment is cross-referenced against an approved change ticket, and any deployment bypassing the approval workflow triggers an immediate alert.
The connection to the IAT domain is direct and architectural. Zero Possession Architecture, CDA's IAT methodology, is operationalized partly through ITGC access controls. ZPA's principle of "Trust nothing. Possess nothing. Verify everything" requires exactly the provisioning, deprovisioning, access review, and privileged access management discipline that ITGC auditors test. Organizations implementing ZPA build the ITGC access control framework as a natural outcome.
For organizations under SOX, ITGC maturity is not optional. A strong ZPA implementation at the IAT layer combined with PCA monitoring at the RGA layer gives public companies the foundation to assert effective controls at year-end, backed by 12 months of automatically collected evidence rather than a six-week pre-audit reconstruction.
CDA Theater missions that address topics covered in this article.
A GRC platform is software that centralizes governance, risk, and compliance operations into a single system of record.
Internal audit is an independent, objective assurance function that evaluates whether an organization's controls are designed appropriately and operating effectively.
Board-level cybersecurity reporting is the practice of translating an organization's security posture, risk profile, and material incidents into the language of governance: financial exposure, liability, regulatory standing, and competitive position.
Written by Evan Morgan
Found an issue? Help improve this article.