A SOX compliance checklist is only useful if it reflects what your external auditor will actually test. Most checklists circulating online are generic control inventories that list every conceivable IT control without indicating which ones matter for financial reporting, which systems fall in scope, or what evidence has to exist before testing begins. Teams work through them diligently, arrive at the audit, and discover the gap was never in the control design. It was in scoping and evidence.
This checklist is organized the way an integrated audit is organized: scope first, then the three IT general control domains that carry most of the testing weight, then the evidence requirements that determine whether a well-designed control can actually be relied upon. It is written for the IT side of Sarbanes-Oxley, which is where technology teams own the work.
For background on the regulation itself and how it applies to information technology, our SOX compliance guide covers the statutory framework, and our SOX compliance services page outlines how assessment and remediation engagements are structured.
What a SOX Compliance Checklist Actually Has to Cover
The Sarbanes-Oxley Act of 2002 imposes two obligations that drive nearly all IT work. Section 302 requires executives to certify the accuracy of financial reports and the effectiveness of disclosure controls each reporting period. Section 404 requires management to assess and report on the effectiveness of internal control over financial reporting, with an external auditor attesting to that assessment for accelerated filers.
Neither section mentions servers, access reviews, or change tickets. The IT obligation is derived: financial reports are produced by systems, so the reliability of those reports depends on the reliability of the systems producing them. The controls that establish that reliability are IT general controls, and they are what your auditor tests.
Two authoritative references shape how that testing is performed. The COSO Internal Control Integrated Framework is the control framework management overwhelmingly uses to structure its assessment. PCAOB Auditing Standard AS 2201 governs how the external auditor conducts an audit of internal control over financial reporting integrated with the financial statement audit, including the risk-based approach that determines how much testing a given control receives.
The practical consequence is that a SOX compliance checklist has to be built around risk to financial reporting, not around general security best practice. A control that materially improves your security posture but has no path to the financial statements is out of scope. A mundane control governing who can post a journal entry is squarely in scope. Teams from a security background consistently over-scope in one direction and under-scope in the other.
Step One: Determine Which Systems Are In Scope
Scoping errors are the single most expensive mistake in SOX IT work, and they compound. Every system incorrectly pulled into scope generates control documentation, testing, and evidence collection that produces no audit value. Every system incorrectly excluded becomes a finding when the auditor traces a balance back to a source you never tested.
Work through scoping in this order.
- Identify the significant accounts and disclosures in the financial statements, working from materiality thresholds set with your auditor.
- Trace each significant account to the business processes that generate its transactions.
- Map each of those processes to the applications that record, calculate, or report the transactions.
- For each in-scope application, identify the supporting infrastructure it depends on: databases, operating systems, and the network and identity layers beneath it.
- Document any spreadsheets or end-user computing tools that perform a material calculation or feed a financial statement line. These are consistently missed and consistently found.
- Identify third-party and cloud-hosted systems in scope and determine how you will obtain assurance over them.
That last item deserves particular attention. Where an in-scope process runs at a service provider, you generally rely on a SOC 1 Type II report covering internal control over financial reporting. Obtaining one is not the end of the exercise. You must confirm the report covers the correct period, covers the services you actually consume, and carries an unqualified opinion. You must also implement and test the complementary user entity controls the report identifies as your responsibility. Those controls are listed in the report specifically because the provider is not performing them, and organizations routinely file the report without reading that section. If your reliance extends to SOC 2 reporting for security commitments, our SOC 2 compliance resources cover how the two report types differ in purpose and scope.
SOX Compliance Checklist: Access to Programs and Data
Access controls attract more audit attention and generate more deficiencies than any other IT general control domain. The reason is straightforward: access is where segregation of duties is enforced, and segregation of duties is the control that prevents one person from both creating and concealing a misstatement.
- A documented, approved process exists for granting access to in-scope systems, with approval by someone independent of the requester.
- Access provisioning is role-based, and role definitions are documented and periodically reviewed for appropriateness.
- Terminated users are removed from all in-scope systems within a defined interval, and removal is evidenced with a date.
- Transfers are treated as a distinct event, with old access revoked rather than accumulated alongside new access. Accumulated access from internal transfers is one of the most common segregation-of-duties findings.
- Privileged and administrative accounts are inventoried, individually attributable, restricted to the minimum population, and monitored.
- Generic, shared, service, and default accounts are inventoried, justified, and have compensating controls where individual attribution is impossible.
- Periodic user access reviews are performed at a defined frequency by business owners who understand what the access permits, not by IT staff confirming the list matches the system.
- Access review results are evidenced, including who reviewed, when, what was concluded, and how any identified inappropriate access was remediated and confirmed.
- Segregation of duties conflicts are defined at the transaction level, tested, and either prevented by system configuration or detected and mitigated.
- Authentication controls meet policy, with multi-factor authentication applied to remote and privileged access.
- Direct access to production databases outside the application layer is restricted, logged, and reviewed.
The most frequent deficiency in this domain is a user access review that was genuinely performed but cannot be evidenced. A reviewer who scanned a list and made no exceptions leaves no artifact. From the auditor's perspective, a control that produces no evidence did not operate.
SOX Compliance Checklist: Change Management
Change controls establish that the system tested at a point in time is the system that ran throughout the period. Without them, the auditor cannot rely on any application control, because nothing establishes the application was not modified mid-period.
- All changes to in-scope applications, databases, and supporting infrastructure follow a documented change management process.
- Changes are requested and authorized before development begins, with the approval evidenced and attributable.
- Testing is performed and documented before production migration, with results retained.
- User acceptance or business approval is obtained for changes affecting financial processing logic.
- Segregation exists between the individuals who develop a change and those who move it to production. Where team size makes this impossible, a compensating detective control exists and is tested.
- Development, test, and production environments are separated, and production data used in lower environments is handled under a documented policy.
- Emergency changes follow a defined expedited path with mandatory retrospective review and approval within a specified window.
- A complete population of changes for the period can be extracted from the system of record, and it reconciles to the ticketing system.
- Automated deployment pipelines enforce the same approval and segregation requirements as manual migrations, with pipeline configuration itself under change control.
That population completeness requirement causes more difficulty than any single control in this list. Auditors select samples from a population, and they must first satisfy themselves the population is complete. If changes can reach production through a path that bypasses the ticketing system, the population is unreliable and sampling from it proves nothing. Organizations running modern continuous deployment frequently find their pipeline is a legitimate control point but was never documented as one.
SOX Compliance Checklist: IT Operations
Operations controls establish that financial data survives intact and that processing completes accurately.
- Scheduled jobs supporting financial processing are inventoried, and job failures are detected, escalated, and resolved under a documented process.
- Job failure resolution is evidenced, including what failed, what was done, and confirmation the reprocessing was correct and complete.
- Backups of in-scope systems run on a defined schedule, and backup success or failure is monitored.
- Restoration is tested periodically. A backup that has never been restored is an assumption rather than a control.
- Incidents affecting in-scope systems are logged, categorized, and resolved under a documented process, with financially significant incidents escalated appropriately.
- Data transfers and interfaces between in-scope systems are monitored for completeness and accuracy, with reconciliation controls over interface failures.
- Physical and environmental controls over infrastructure are in place, or inherited from a provider under a SOC 1 report with the complementary user entity controls implemented.
Evidence: What Your Auditor Will Actually Ask For
A control that operated but cannot be evidenced is treated as a control that did not operate. This is the gap between organizations that pass comfortably and organizations that scramble, and it is almost never a matter of control design.
For every control on your checklist, confirm the following before testing season rather than during it.
- The evidence demonstrates the control operated throughout the period, not merely on the date the screenshot was captured.
- System-generated evidence carries a visible date, the system identity, and the parameters used to generate it.
- Evidence of review shows who reviewed, when, what was examined, and what conclusion was reached. An initial on a page proves someone touched it, not that they evaluated it.
- Exceptions identified by a control show the follow-through: what was found, what was done, when, and confirmation the resolution was verified.
- Populations from which the auditor will sample can be extracted with a documented, repeatable method that establishes completeness.
- Evidence is retained for the full required period and remains retrievable after system upgrades and personnel changes.
Design a control so it produces its own evidence as a byproduct of operating. Controls that require someone to remember to document them are the ones that generate deficiencies, because the documentation step is the first thing dropped when the team is busy. Our compliance audit checklist covers the general evidence-preparation pattern that applies across frameworks.
Common SOX Compliance Checklist Failures
These patterns account for a large share of IT deficiencies, and every one is avoidable.
Treating the checklist as the objective. The checklist is a tool for organizing work against risk. Teams that complete every line without tracing controls back to financial statement risk produce a large volume of documentation that does not answer the auditor's actual question.
Scoping by security importance rather than financial relevance. The most security-critical system in the environment may be entirely out of SOX scope, and a dull reporting database may be squarely in it.
Performing access reviews without evidencing judgment. Covered above, and worth repeating because it is the most common single finding.
Ignoring end-user computing. Spreadsheets performing material calculations are in scope, need version and access control, and are consistently overlooked until an auditor traces a balance into one.
Filing the SOC 1 report without implementing complementary user entity controls. Obtaining the report is the first half of the work.
Discovering the population problem during testing. If the complete population of changes or access grants cannot be produced on demand, remediation mid-audit is expensive and highly visible.
Remediating a deficiency too late to demonstrate operating effectiveness. A control fixed in the final weeks of the period has not operated long enough for the auditor to conclude it is effective. Timing matters as much as the fix.
Frequently Asked Questions
Does SOX apply to private companies?
The internal control reporting requirements of Section 404 apply to public companies. Private companies encounter SOX-equivalent expectations in several situations: preparing for an initial public offering, operating as a subsidiary of a public parent, or facing contractual requirements from lenders, investors, or acquirers. Private companies planning an offering benefit substantially from building these controls early, because retrofitting control evidence across a prior period is considerably harder than generating it as you go.
How often do user access reviews need to be performed?
The statute does not prescribe a frequency. Quarterly is the common practice for privileged access and high-risk applications, with semiannual or annual reviews acceptable for lower-risk systems. The defensible position is a frequency set by documented risk assessment and then performed consistently. A quarterly commitment performed twice is worse than a semiannual commitment performed reliably.
What is the difference between IT general controls and application controls?
IT general controls operate across the environment and establish that systems are reliable: access management, change management, and operations. Application controls are embedded in a specific process and enforce accuracy in transactions, such as a three-way match or an approval limit. The relationship matters because application controls can only be relied upon if the general controls beneath them are effective. Weak change management undermines every automated application control in the system it governs.
Can a small IT team achieve segregation of duties?
Complete preventive segregation is often impossible when a small number of people administer everything. The accepted approach is a compensating detective control: privileged activity is logged and independently reviewed by someone who did not perform it, with the review evidenced. Auditors accept properly designed and evidenced compensating controls. What they do not accept is the absence of segregation with no compensating control identified.
What happens if a deficiency is identified?
Deficiencies are evaluated by severity. A control deficiency is the lowest tier. A significant deficiency is important enough to merit attention by those responsible for financial reporting oversight. A material weakness represents a reasonable possibility that a material misstatement would not be prevented or detected on a timely basis, and it requires public disclosure for accelerated filers. Severity depends on the magnitude of potential misstatement and the likelihood of occurrence, not on how difficult the fix is.
How early should we start preparing?
Controls must operate for a sufficient portion of the period for the auditor to conclude on operating effectiveness. Beginning work in the final quarter leaves insufficient runway for any newly implemented control. Scoping and design should be settled well before the period begins, with the year used to accumulate evidence.
Getting Your SOX Compliance Checklist Assessed
Petronella Technology Group, Inc. has supported regulated organizations with IT compliance and assessment work since 2002. Craig Petronella is a CMMC Registered Practitioner and the author of multiple books on cybersecurity, and our IT general control engagements are structured around what an external auditor will test rather than around a generic control inventory.
A readiness assessment typically covers scope validation against your significant accounts, control design review across the three IT general control domains, an evidence-quality review of what your current controls actually produce, and a remediation plan sequenced so that controls have time to demonstrate operating effectiveness before testing begins. That sequencing is usually the difference between a clean opinion and a deficiency that was identified too late to remediate.
Contact our team to discuss a SOX IT general controls readiness assessment for your environment.
Free, practical, and specific to regulated environments. We will email it to you.
No spam. Unsubscribe anytime.
