You can run SOX IT general controls from spreadsheets if you have a small in-scope application set. Track each ITGC by area (access, change, operations), owner, frequency, test steps and evidence. Move to automation when populations, such as user lists or changes, get too large to sample by hand each quarter.
SOX is the US Sarbanes-Oxley Act. Section 404(a) has management of public companies assess internal control over financial reporting, and 404(b) has the external auditor attest to it for larger companies. We tried the SEC and PCAOB primary pages and both returned errors, so the points below come from secondary summaries returned by search. Verify against SEC guidance and PCAOB AS 2201, and ask your auditor what they require. This is not legal advice.
What are ITGCs?
Secondary sources consistently describe four areas: access to programs and data, program changes, program development and computer operations. ITGCs usually do not address financial reporting risk directly. They matter because automated controls and system generated reports depend on them working.
What does each area cover?
- Access: provisioning, removal, privileged access, segregation of duties, periodic access reviews.
- Program changes: request, approval, testing and deployment, and controls on moving code to production.
- Program development: controls over new systems and major implementations.
- Computer operations: job monitoring, backups, incident handling.
What does a workable workbook look like?
- Scoping. Financial applications and their supporting databases, operating systems and infrastructure, with the reason each is in scope.
- Control matrix. One row per control: ID, description, area, owner, frequency, risk addressed.
- Test plan. For each control: population, sample method, test steps (inquiry, observation, inspection, reperformance), expected result.
- Evidence index. Item, date, source, preparer, reviewer, link.
- Deficiency log. Issue, severity assessment, remediation, retest result.
- Population exports. Dated lists of users, changes and jobs, kept as read only files.
Where does manual testing break?
- Access reviews. The reviewer approves a list nobody verified was complete.
- Change populations. Sampling from a hand made list invites the question of whether it was complete.
- Evidence timing. Screenshots taken after the period ends do not show what happened during it.
- Reviewer independence. The person who runs the control also tests it.
- Scale. Dozens of applications mean dozens of quarterly exports.
Secondary sources also say privileged access, unreviewed changes and missing access reviews recur as ITGC deficiencies year after year.
When should you automate?
When populations are large, or when the system itself can produce a complete, timestamped record: access lists from your identity provider, merge history from your repository, job results from your scheduler. Automate evidence capture and completeness first. Keep management judgment, such as approving access, with people.
What to do
- Agree the in-scope application list with finance and your auditor.
- Build the control matrix and assign owners outside IT where possible, for independence.
- Pull complete populations directly from systems, never from memory.
- Date and lock each export when you take it.
- Test on a calendar, with a reviewer who did not run the control.
- Log every deficiency and retest after the fix.
Quick check
Is there a SOX certification?
No. Management assesses internal control and, for larger public companies, the external auditor attests. No framework body issues a SOX certificate.
Which areas make up ITGCs?
Secondary sources list access to programs and data, program changes, program development and computer operations. Confirm your own structure with your auditor.
How Safeguard helps automate this
SOX ITGC evidence has to be complete, dated and repeatable. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, leaving time for other work. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability, which supports change and development controls. Autonomous remediation 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. Your external auditor still performs the testing. Book a call to see it.
Sources
- SEC and PCAOB primary pages (SEC 2007 interpretive guidance, PCAOB AS 2201): fetch failed with HTTP 403 and 404 on 18 October 2026, so we did not read them
- Secondary web search summaries on ITGC areas, 18 October 2026; verify against the primary texts
Last reviewed: 18 October 2026.
