To implement SOX IT general controls yourself, scope the systems that affect financial reporting, design controls in four areas (access, program changes, program development and computer operations), run them, test them, fix failures, and keep dated evidence. External auditors then test design and operation, usually by sampling across the year.
What are ITGCs for?
SOX concerns internal control over financial reporting for US public companies. IT general controls support the systems that produce financial data, so that automated controls and reports can be relied on. Our search for primary sources returned mostly practitioner material, not PCAOB or SEC pages, so treat the structure here as common practice and confirm details with your auditors. Sources describe COSO 2013 as the usual control framework, and PCAOB Auditing Standard 2201 as the standard under which the auditor audits internal control integrated with the financial statement audit.
Step 1: scope the systems
Start from the financial statements: which applications produce or feed significant numbers (ERP, billing, payroll, consolidation, data warehouse, spreadsheets that matter), and which infrastructure sits beneath them (databases, operating systems, networks, cloud accounts). Agree the list with finance and your auditors. Smaller scope is cheaper, but only if it is defensible.
Step 2: choose the control families
Practitioner sources commonly describe four domains.
Access to programs and data. Provisioning with approval, timely removal at leaving or role change, periodic access reviews, privileged access limits, password and authentication rules, and segregation of duties.
Program change management. Changes to code, configuration and infrastructure are requested, approved, tested and released by different people. Emergency changes get retroactive approval. Developers cannot push to production alone.
Program development. New systems and major implementations have documented requirements, testing, data migration checks and sign off.
Computer operations. Job scheduling and monitoring, failure handling, backups and restore tests, incident management.
Step 3: write control descriptions
For each control state what is done, by whom, how often, in which system and what evidence results. Auditors test the control you describe, so describe what really happens and keep wording tight.
Step 4: build the evidence trail into the work
Make the system produce proof: pull request approvals as change evidence, tickets for access requests, scheduled reports for access reviews, backup job logs. Evidence generated by the workflow beats evidence assembled later.
Step 5: self test
Test your own controls before the auditors do. Choose samples, check the evidence and record results. Sources describe auditors testing design (would the control prevent or detect misstatement) and operating effectiveness (did it run consistently over the period), with sampling over the fiscal year.
Step 6: remediate and re-test
Log each deficiency with cause, owner and fix date. Retest after the fix. Know the difference between a one off miss and a pattern, and discuss significant ones with finance and audit early.
Step 7: run the calendar
Quarterly access reviews, change sampling each month, restore tests, annual policy review. Keep a control owner list and a sign off for each period.
Mistakes to avoid
- Scoping out a system that quietly feeds the reports.
- Shared or generic admin accounts on financial systems.
- Developers with production access and no compensating review.
- Access reviews that approve everything with no change.
- Evidence created after the fact.
What to do
- Agree the in-scope systems with finance and auditors.
- Pick controls in the four domains and write precise descriptions.
- Wire evidence into tickets, pull requests and scheduled reports.
- Self test with samples across the period.
- Log deficiencies, fix them and retest.
- Set the recurring calendar and owners.
- Meet your auditors early and again before year end.
Quick check
What are the four ITGC domains?
Access to programs and data, program changes, program development and computer operations, as commonly described by practitioners. Confirm with your auditors.
Do auditors test design or operation?
Both. Design asks whether the control would work as described. Operating effectiveness asks whether it ran consistently over the period, usually through sampling.
How Safeguard helps automate this
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. ITGC evidence repeats every quarter, so it benefits most from collection that does not rely on screenshots.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, which supports change management and secure development records. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. SOX testing is done by your internal and external auditors. Safeguard helps prepare and keep evidence ready, and does not replace them.
Want to see it on your own stack? Book a call.
Sources
- Practitioner overview of SOX ITGC domains (secondary source)
- PCAOB, standards (check AS 2201 directly)
Last reviewed: 18 October 2026.
