IT general controls (ITGCs) in a SOX audit
IT General Controls (ITGCs) are the foundational security and operational policies that ensure the integrity, availability, and confidentiality of data used in financial reporting. In a SOX audit, you must prove that these controls are consistently applied so that auditors can rely on the automated application controls and reports generated by your systems.
What it means
ITGCs do not focus on specific business transactions (like approving an invoice), but rather on the environment in which those transactions occur. If a system's ITGCs are weak—for example, if any developer can change production code without approval—the auditor cannot trust that the financial data produced by that system is accurate or untampered with.
The scope generally covers three primary domains: Access Management (who can get in), Change Management (how software is updated), and System Operations (how the system is maintained). This applies to every layer of the technology stack that supports financial reporting, including the operating system, database, network, and application layers.
How to meet it
- Implement a formal Access Request process: Require written or electronic approval from management before granting any new user access to financial systems.
- Conduct periodic User Access Reviews (UARs): At least quarterly, have managers review lists of users with access to sensitive systems and formally sign off that the access is still required.
- Enforce Segregation of Duties (SoD): Ensure that individuals who write code (Developers) do not have permission to move that code into the production environment (Release Managers).
- Establish a Change Management workflow: Document every change through a ticket that includes the request, the testing results in a non-production environment, and final management approval before deployment.
- Automate backup and monitoring: Configure automated backups for all financial data and implement alerting for system failures or unauthorized access attempts.
- Formalize offboarding procedures: Create a trigger between HR and IT to ensure that system access is revoked immediately (usually within 24-72 hours) upon employee termination.
Evidence an auditor asks for
- User Lists and Provisioning Tickets: A complete list of users compared against the approval tickets showing why they were granted access.
- Change Logs and Approval Trails: Samples of specific changes where you provide the ticket showing the request, the UAT (User Acceptance Testing) sign-off, and the deployment timestamp.
- Signed Access Review Reports: Dated evidence (emails or system logs) proving that managers reviewed user permissions on a recurring schedule.
- Backup Success Logs: System-generated reports proving backups were completed successfully over a specific period and records of periodic restore tests.
Common pitfalls
- The "Developer in Production" gap: Allowing developers to have administrative access to production environments for "troubleshooting," which bypasses change management controls.
- Lack of evidence for the "invisible" work: Performing the necessary security checks or reviews but failing to document them, leaving the auditor with no objective proof that the control occurred.
- Stale user accounts: Failing to remove access for terminated employees promptly, resulting in "ghost users" appearing on audit samples.
- Inconsistent documentation: Using multiple fragmented systems (email, Slack, Jira) for approvals without a centralized way to reconstruct the full lifecycle of a change or access request.