Bottom Line Up Front
If your company is public, about to go public, or acquired by a public company, IT is now part of your financial reporting control environment — whether your engineering team likes it or not. This guide gives you a practical sox compliance checklist for IT covering the ITGCs (IT General Controls) auditors expect to see, the evidence you need to collect, and how to avoid the scramble that happens every Q4 when finance realizes IT wasn’t ready.
Building a functional SOX IT control environment from scratch typically takes 12-16 weeks for a mid-sized company with a reasonably modern tech stack. Maintaining it is a permanent, recurring quarterly and annual cycle — not a one-time project. If you’re going through your first SOX audit as a newly public company, budget more time; your external auditors will be calibrating materiality and scope for the first time too.
Before You Start
Prerequisites
You’ll need administrative or read access to your identity provider, financial systems (ERP, general ledger, revenue recognition tools), production infrastructure, and code deployment pipelines. You’ll also need a documented understanding of which applications are considered “in-scope” for SOX — this comes from your financial statement risk assessment, not from IT guessing.
Have a GRC platform or, at minimum, a shared evidence repository ready before you start collecting artifacts. Auditors will ask for the same evidence quarter after quarter, and manually hunting for screenshots in Slack threads is how audit fatigue kills otherwise good control environments.
Stakeholders to Involve
- Internal Audit or Controller’s office — they own the SOX scoping and risk assessment; IT doesn’t get to decide what’s in scope.
- External auditors — engage them early to confirm control design expectations before you build anything.
- Engineering/DevOps leadership — they own most of the actual control execution (access provisioning, change management, deployment pipelines).
- Security team — owns IAM, logging, and vulnerability management evidence.
- Executive sponsor (usually CFO or CTO) — needed to enforce control adherence when engineers push back on “process overhead.”
Scope
This guide covers ITGCs — the control categories auditors test as part of SOX Section 404: access management, change management, and IT operations (backup, job scheduling, incident management). It does not cover entity-level controls, financial statement-level controls, or application-level automated controls (those are usually tested by your finance/controllership team with IT support).
Frameworks This Satisfies
A well-built SOX ITGC environment overlaps heavily with SOC 2 (particularly the Security and Availability trust criteria) and ISO 27001 access control and change management domains. Many companies use the same underlying controls — access reviews, change approval workflows, logging — to satisfy SOX, SOC 2, and ISO 27001 simultaneously, which is the efficient way to do this.
| Control Area | SOX ITGC | SOC 2 Overlap | ISO 27001 Overlap |
|---|---|---|---|
| Access provisioning/deprovisioning | Yes | CC6.1-6.3 | A.5.15-5.18 |
| Change management | Yes | CC8.1 | A.8.32 |
| Backup and recovery | Yes | A1.2 | A.8.13 |
| Logging and monitoring | Partial | CC7.2 | A.8.15-8.16 |
Step-by-Step Process
Step 1: Confirm In-Scope Systems and Control Owners (1-2 weeks)
Get the finalized list of financially relevant systems from Internal Audit — typically your ERP, revenue recognition platform, billing systems, and any application that feeds numbers into the general ledger. Map each system to a named control owner, not a team or department.
What goes wrong: IT builds controls for systems that finance never intended to be in scope, wasting weeks on low-value work, while a critical billing integration gets missed entirely because “nobody thought of it as an IT system.”
Step 2: Build Your user access review (UAR) Process (2-3 weeks)
Establish a quarterly access review for every in-scope system. For each system, generate a full user list with role/permission level, route it to the control owner or business owner, and require explicit sign-off on who should retain access, who should be modified, and who should be removed.
Automate the user list export wherever possible — pulling directly from your IAM/SSO provider via SAML or SCIM reduces manual error. Document segregation of duties (SoD) conflicts explicitly; auditors will specifically test whether one person can both create a vendor and approve a payment.
What goes wrong: Reviewers rubber-stamp the list without actually reviewing it. Auditors catch this by asking pointed questions about specific users during walkthroughs — if your reviewer can’t explain why “jsmith” has admin access, that’s a finding.
Step 3: Formalize Provisioning and Deprovisioning (1-2 weeks)
Document a standard workflow: access requests require manager approval, provisioning happens against a documented role-based access control (RBAC) matrix, and terminations trigger access revocation within a defined SLA — typically same-day for high-risk systems, within 3 business days for others.
Tie this to your HRIS so terminations automatically trigger a deprovisioning ticket. This is the single most commonly tested control in any SOX audit, and it’s also the one most likely to fail because manual processes break under headcount growth.
Step 4: Implement Change Management Controls (2-4 weeks)
Every production change to an in-scope system needs a documented trail: request, approval, testing evidence, and deployment record. If you’re using CI/CD pipelines, this means enforcing mandatory code review, a separate approver from the developer, and automated deployment logs.
Configure your pipeline so merges to production branches require at least one approving review from someone who isn’t the author — most Git platforms support this as a branch protection rule. Preserve deployment logs for the full audit period; don’t rely on ephemeral CI logs that roll off after 30 or 90 days.
What goes wrong: Emergency/hotfix changes bypass the normal approval workflow entirely, and nobody documents an exception process for them. Build a documented emergency change procedure with after-the-fact approval requirements — auditors expect exceptions to exist, but they expect them to be controlled.
Step 5: Document Backup, Recovery, and Job Scheduling Controls (1-2 weeks)
For each in-scope system, document backup frequency, retention period, and evidence that restore testing actually happens — not just that backups run. For batch jobs feeding financial data (nightly ETL, month-end close processes), document monitoring and alerting for job failures.
What goes wrong: Backups run successfully every night for years, but nobody has ever tested a restore. Auditors will ask for evidence of a completed restore test, not just a green checkmark in a backup dashboard.
Step 6: Establish Logging and Monitoring Evidence (1-2 weeks)
Configure centralized logging (SIEM or equivalent) for administrative actions on in-scope systems — privileged access grants, configuration changes, database access. Retain logs for the full audit period, typically a minimum of one year.
This isn’t usually a standalone ITGC, but it’s the evidentiary backbone that proves your access and change controls actually operated as designed throughout the year, not just at the moment someone took a screenshot.
Verification and Evidence
Before your external auditors arrive, run an internal walkthrough of each control with the actual control owner — not the process documentation, the real person doing the work. Ask them to demonstrate the control live rather than describing it from memory.
For each control, your evidence file should include:
- Access reviews: completed review spreadsheets/tickets with reviewer sign-off and remediation evidence for flagged users, for every quarter in the audit period.
- Change management: a sample of tickets showing request, approval, and deployment for each in-scope system, plus your branch protection configuration screenshot.
- Provisioning/deprovisioning: onboarding and termination tickets with timestamps proving SLA adherence.
- Backup/recovery: backup job logs and at least one documented restore test per system per year.
- Logging: a sample export from your SIEM showing retained privileged-action logs.
Auditors test controls using sampling — typically pulling a handful of transactions from throughout the year, not just year-end. If your Q1 evidence looks different from your Q4 evidence, that inconsistency itself becomes a finding.
Common Mistakes
1. Treating SOX as an annual event instead of a continuous control. Controls that only “work” in the month before the audit aren’t controls — they’re theater. Fix: build the review cadence into calendar reminders and ticketing workflows, not a pre-audit fire drill.
2. No segregation of duties in small engineering teams. Startups scaling into SOX scope often have one person with god-mode access across everything. Fix: this is genuinely architectural — you may need compensating controls (like mandatory logging and periodic independent review) until you can properly separate duties.
3. Access reviews without real remediation. Reviewers flag access that should be removed, but nobody follows up. Fix: track remediation as its own ticket with a due date, and report open remediation items to the control owner monthly.
4. Undocumented emergency changes. Fast-moving engineering teams bypass approval “just this once” during incidents. Fix: build a lightweight emergency change template that takes under five minutes to complete, so it actually gets used.
5. Evidence scattered across tools with no central repository. Screenshots in Slack, tickets in three different systems, no consistent naming. Fix: centralize evidence collection in a GRC platform or a structured shared drive with a consistent folder taxonomy by control and quarter.
Maintaining What You Built
Run access reviews quarterly, not annually — auditors increasingly expect this cadence, and it catches access creep before it becomes a finding. Reassess system scope annually alongside your financial statement risk assessment, since new acquisitions, new revenue systems, or platform migrations can pull previously out-of-scope systems into SOX territory.
Any major system change — a new ERP, a cloud migration, a significant re-architecture of your deployment pipeline — should trigger a control redesign review, not just a documentation update. Keep your control narratives and evidence templates in version control alongside a change log, so you can show auditors exactly when and why a control changed.
FAQ
Does SOX apply to private companies?
Generally no — SOX Section 404 applies to publicly traded companies, but private companies preparing for an IPO or acquisition by a public company should start building ITGCs 12-18 months ahead of time. Waiting until the S-1 filing is too late.
What’s the difference between SOX and SOC 2 for IT controls?
SOX focuses narrowly on controls affecting the accuracy of financial reporting, while SOC 2 covers a broader trust services scope including security, availability, and confidentiality regardless of financial impact. Many organizations design shared controls that satisfy both simultaneously.
How many systems are typically in SOX scope?
It varies widely, but most mid-sized public companies have somewhere between 10 and 30 in-scope applications — driven by financial materiality, not by IT’s assessment of system importance. Your Internal Audit function determines this through a formal risk assessment, not IT.
Can automation replace manual access reviews?
Automation can generate the access lists and route approvals, but auditors still expect a documented human decision on each reviewed user. Full automation without human judgment is typically viewed as a control gap, not a control improvement.
What happens if we find a control deficiency mid-year?
Document it immediately, remediate it, and retest before your auditors do — a self-identified and remediated deficiency looks far better than one your auditor finds first. Report material deficiencies to your Audit Committee per your internal escalation policy.
Conclusion
A functional SOX IT control environment isn’t about perfect documentation — it’s about controls that genuinely operate the way you say they do, quarter after quarter, with evidence to prove it. Get the access management, change management, and operations controls right, and you’ll find the audit itself becomes far less painful than the internal process of building the controls in the first place.
If you’re facing your first SOX readiness assessment, scaling controls after an acquisition, or trying to unify SOX with SOC 2 and ISO 27001 without duplicating work three times over, SecureSystems.com builds practical, audit-ready control environments for companies that don’t have a 20-person GRC team to throw at the problem. Book a free compliance assessment and find out exactly where your control gaps are before your auditors do.
