SOX IT general controls (ITGCs) are the technology controls that make financial reporting systems trustworthy. Auditors usually test access to programs and data, program change management and computer operations. For each, keep complete populations, sampled evidence of approvals and reviews, and records of exceptions. Preparation is mostly about proving the control ran every time.
Where does the requirement come from?
Section 404 of the Sarbanes-Oxley Act, codified at 15 U.S.C. 7262, requires annual reports to state management's responsibility for an adequate internal control structure and procedures for financial reporting, and to contain management's assessment of their effectiveness at fiscal year end. For issuers that are not exempt, the registered public accounting firm attests to and reports on that assessment. Issuers that are neither large accelerated nor accelerated filers are exempt from the attestation under subsection (c), and emerging growth companies are carved out too.
The statute does not mention ITGCs. They come from how management and auditors scope internal control over financial reporting: systems that produce or hold financial data inherit risk, and ITGCs are the controls that support them. The PCAOB's auditing standard page was blocked when we tried to fetch it on 18 October 2026, so the control categories below reflect common practice. Confirm the exact scope with your external auditor and finance leadership.
Which controls are tested?
Most programmes group ITGCs into three areas.
Access to programs and data. New access is requested and approved, access is removed when people leave or change roles, privileged access is restricted and reviewed, and passwords or authentication meet policy. Typical evidence: access request tickets, termination lists matched to removal dates, quarterly user access review sign offs and privileged account lists.
Change management. Changes to in scope applications and infrastructure are authorised, tested and approved before production, and developers cannot push unreviewed changes. Evidence: change tickets, pull requests with reviewers, test results and deployment logs that link back to approvals.
Computer operations. Batch jobs and interfaces run and failures are handled, backups run and can be restored, and incidents affecting financial systems are logged and resolved. Evidence: job monitoring records, backup reports, restore tests and incident tickets.
Some programmes add program development or data migration when a new financial system is implemented.
How does testing work?
Auditors typically ask for a complete population for the period, such as every user added, every user removed or every production change. Then they select samples and trace each one. Because the sample is chosen after you hand over the population, an incomplete or inaccurate list is itself a problem. They may also test the report or query that produced the list.
How do you prepare?
Run your own test before the auditors do. For each key control, pull the population, choose a sample, trace it and record the result. Where something fails, document what happened, why and what you changed. Deficiencies are usually classified by severity, and the earlier you find and fix them, the better your position.
Define owners: IT for access and operations evidence, engineering for change records, finance for deciding which systems are in scope, and internal audit or compliance for coordination.
What mistakes create findings?
- Terminated employees with active accounts, even briefly.
- Access reviews signed without reviewing anything, or performed by the person whose access is being reviewed.
- Emergency changes with no retrospective approval.
- Shared administrator accounts that hide who did what.
- Populations pulled from a system the auditor cannot validate.
- A tool migration mid year with no evidence of continuity.
- Scope surprises: a spreadsheet or a script that feeds the general ledger and was never counted.
What to do
- Agree the in scope systems with finance and your external auditor, in writing.
- List key ITGCs per system and name an owner for each.
- Define the evidence for each control, with a population source.
- Run quarterly access reviews with documented decisions and removals.
- Link every production change to an approved ticket and reviewer.
- Track backup success and test restores at least once in the period.
- Self test each key control twice a year and record exceptions.
- Keep an issue log with remediation dates and evidence.
Quick check
Do all companies need an external SOX ITGC audit?
Under 15 U.S.C. 7262, the auditor attestation is required for issuers other than emerging growth companies, and does not apply to issuers that are neither large accelerated nor accelerated filers. Management's own assessment is still required. Confirm your status with counsel.
Are ITGCs named in the Sarbanes-Oxley Act?
No. The statute requires internal control over financial reporting. ITGCs are a way of scoping the technology controls that support it, and your auditor defines the details.
Sources
- 15 U.S. Code 7262, management assessment of internal controls, Legal Information Institute copy fetched 18 October 2026.
- PCAOB, AS 2201: blocked on fetch, so not relied on here.
How Safeguard helps automate this
ITGC evidence is repetitive: every access change, every deployment, every backup. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than by screenshot, and monitoring runs between audits. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. The remediation agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Safeguard helps you prepare and keep evidence ready. Your external auditor performs the audit. Book a call.
Last reviewed: 18 October 2026.
