[ Blog ] SOX · ITGC · Pre-IPO
The SOX ITGC checklist
every pre-IPO company
needs in Year 1.
March 2026 · 10 min read · Lumina Risk Advisory
Year 1 of SOX is the hardest audit your IT team will face. Your external auditors are scoping everything for the first time. Your controls may have existed informally for years but never been documented. And your evidence library doesn't exist yet. This checklist gives you the starting framework.
Before you use this checklist
This is a directional starting framework — not a substitute for a scoping engagement. Your actual ITGC scope depends on your in-scope systems, your auditor's risk assessment, and your company's specific technology stack. Use this to understand the shape of the work; use a proper scoping engagement to define the actual scope.
What are ITGCs, and why do they matter for SOX?
IT General Controls (ITGCs) are the foundational controls that govern how systems are accessed, changed, operated, and developed. They are "general" because they apply to all applications — unlike application controls, which are specific to a single system.
Under SOX Section 404, management must assess the design and operating effectiveness of internal controls over financial reporting (ICFR). ITGCs underpin that assessment: if your ITGCs are weak, your financial application controls can't be relied upon — which means your entire ICFR assessment is at risk.
External auditors test ITGCs because they need to confirm that the systems producing financial data are reliable. If access controls are weak, someone could have manipulated financial data. If change management controls are weak, unauthorized changes could have introduced errors. The auditors need comfort on both fronts before they'll sign off on the financial statements.
The four ITGC domains — with evidence requirements
Your auditors will test across all four of these domains. For each control, we've listed the control objective, what evidence auditors will ask for, and what risk it addresses.
Access to Programs & Data
User provisioning process
Risk: Unauthorized access to financial systems
Evidence auditors will request
IT tickets or access request forms showing approval before access granted
User de-provisioning process
Risk: Former employees retaining system access
Evidence auditors will request
Terminated user list cross-referenced to system access removal within defined SLA
Privileged access management
Risk: Excessive privilege creating segregation of duties violations
Evidence auditors will request
List of admin/privileged users with documented approval; quarterly access review sign-off
Periodic access reviews
Risk: Accumulated access over time not reviewed or recertified
Evidence auditors will request
Signed access review certifications by system owners at least quarterly
Segregation of duties
Risk: One person controlling an entire financial process
Evidence auditors will request
Role matrix showing no individual has conflicting access (e.g., create and approve journal entries)
Authentication controls
Risk: Weak authentication enabling unauthorized access
Evidence auditors will request
MFA enrollment evidence, password policy configuration screenshots
Change Management
Change request and approval process
Risk: Unauthorized changes to financial reporting systems or data
Evidence auditors will request
Ticketing system showing change requested, tested, approved by separate approver, and deployed
Segregation between development and production
Risk: Untested changes deployed directly to production
Evidence auditors will request
Evidence that developers cannot directly deploy to production; CI/CD pipeline controls or access matrix
Testing requirements
Risk: Untested changes causing system errors in financial processing
Evidence auditors will request
Test plan and results documented for significant changes before production deployment
Emergency change procedures
Risk: Emergency changes circumventing standard controls without compensating review
Evidence auditors will request
Documented emergency change process; examples showing retroactive approval within defined timeframe
Computer Operations
Job scheduling and monitoring
Risk: Batch processing failures going undetected and affecting financial balances
Evidence auditors will request
Batch job schedules, automated alerts, exception reports reviewed and signed off
Backup and recovery
Risk: Data loss due to system failure with no recovery capability
Evidence auditors will request
Backup schedule, backup completion logs, periodic recovery test results
Incident management
Risk: System incidents affecting financial reporting not tracked or resolved timely
Evidence auditors will request
Incident log showing issues detected, escalated, resolved within SLA; post-incident reviews for material incidents
System monitoring
Risk: Performance or availability issues not detected until they affect financial processing
Evidence auditors will request
Monitoring tool configuration, alert thresholds, evidence of alerts reviewed
System Development (SDLC)
SDLC methodology
Risk: New systems implemented without adequate controls or testing
Evidence auditors will request
Documented development process showing requirements, design, testing, and deployment phases
User acceptance testing
Risk: Systems placed in production that don't meet requirements or contain errors
Evidence auditors will request
UAT sign-off from business owners before new systems or significant changes go live
Post-implementation review
Risk: Implementation issues not identified and corrected after go-live
Evidence auditors will request
Evidence of review conducted after significant implementations to confirm expected outcomes
The most common Year 1 findings
In our experience, these are the findings that show up most often in first-year SOX IT audits:
- —Access reviews not completed on schedule or lacking documented sign-off from system owners
- —Terminated employees' access not removed within the policy-defined timeframe (often set too generously at "within 30 days")
- —Developers with direct production access — common at pre-IPO companies where the engineering team hasn't yet been segregated
- —Change management tickets missing approver, missing test evidence, or closed without documentation of what was deployed
- —No formal user acceptance testing process — changes tested informally but not documented
- —Backup testing not performed or not documented — backup processes exist but recovery has never been tested
- —Admin/privileged accounts not formally approved and reviewed quarterly
What "significant deficiency" and "material weakness" actually mean
Not all audit findings are equal. External auditors classify IT control deficiencies on a spectrum:
- Control deficiency A weakness in the design or operation of a control that could affect financial reporting but is unlikely to be material. Common in Year 1. Noted in the management letter but not in the audit opinion.
- Significant deficiency A deficiency, or combination of deficiencies, that is less severe than a material weakness but important enough to merit attention by those responsible for oversight. Disclosed in the SOX 404 report.
- Material weakness A deficiency that creates a reasonable possibility that a material misstatement of financial statements will not be prevented or detected on a timely basis. Must be disclosed in your 10-K. Sends a signal to investors and auditors. This is the one to avoid.
The best defense against all three is remediating before the audit window opens — not after the auditor finds it.
Need help scoping and prioritizing your Year 1 ITGC work? A scoping call will tell you where to focus first and what the audit window looks like from here.