SOX compliance: IT general controls checklist
SOX compliance, for IT teams, means proving the systems behind your financial reporting are controlled. Section 404 of the Sarbanes-Oxley Act requires management of SEC-reporting companies to assess internal control over financial reporting each year, and for most larger companies the external auditor attests to that assessment. The IT general controls (ITGCs) that auditors look at are usually grouped as access to programs and data, program change management, and computer operations.
Score your own controls below. Last reviewed 3 November 2026. General information for US issuers, not legal or audit advice.
Coverage = Met counts 1, Partial counts 0.5, Gap counts 0. N/A and unanswered items are left out. This is a self-assessment: it sees no evidence and is not an audit opinion.
Access to programs and data
Who can reach the in-scope applications, databases, operating systems and networks, and how that is approved, reviewed and removed.
A1New access to in-scope systems is requested and approved by an authorized person before it is granted.
Typical evidence: Access tickets showing requester, approver and grant date for a sample of new users.
A2Access of leavers and transfers is removed or changed promptly.
Typical evidence: HR leaver list matched to account status, with removal dates.
A3User access to in-scope applications, databases and operating systems is reviewed periodically by the owner, and exceptions are acted on.
Typical evidence: Review sign-offs, the lists reviewed, and tickets for each removal or change.
A4Privileged and administrator access is limited to people who need it, and its use is logged and reviewed.
Typical evidence: Privileged account inventory, approvals, and review of administrator activity logs.
A5Segregation of duties conflicts are defined for key financial processes and enforced or compensated.
Typical evidence: Conflict rule set, periodic conflict report and documented resolutions.
A6Authentication settings on in-scope systems follow policy, including multi-factor authentication where required.
Typical evidence: Configuration exports or screenshots with dates, and the policy they are tested against.
A7Shared, generic and service accounts have a named owner, restricted use and managed credentials.
Typical evidence: Service account inventory with owners and credential rotation or vault records.
Program change management
How changes to in-scope applications and infrastructure are requested, approved, tested, released and reconciled.
C1Every change to in-scope systems has a documented request and an authorized approval before release.
Typical evidence: Change tickets with requester, approver and release date for a sample of changes.
C2Changes are tested and the test result is signed off before they go to production.
Typical evidence: Test evidence and sign-off linked to the change ticket.
C3Developers cannot push changes to production without an independent approval or review step.
Typical evidence: Branch protection and deployment pipeline settings, and a list of who has production deploy rights.
C4Emergency changes follow a defined path with after-the-fact review and approval.
Typical evidence: Emergency change log with retrospective approvals.
C5Deployed changes are reconciled to approved changes so unauthorized changes are detected.
Typical evidence: Reconciliation of system release or audit logs to the approved change list, with exceptions followed up.
C6Data migrations and conversions for financial systems are planned, validated and approved.
Typical evidence: Migration plan, reconciliation of record counts and balances, and sign-off.
Computer operations
How in-scope jobs, interfaces, backups and incidents are run, monitored and resolved.
O1Backups of in-scope systems and data run on schedule, are monitored, and failures are followed up.
Typical evidence: Backup job reports and tickets for failed jobs.
O2Restores are tested periodically to show that backups are usable.
Typical evidence: Restore test records with date, scope and result.
O3Batch jobs and interfaces that feed financial data are scheduled, monitored, and failures are investigated and resolved.
Typical evidence: Job schedule, monitoring alerts and incident tickets for failed or late jobs.
O4Incidents and problems affecting in-scope systems are logged, prioritized and resolved.
Typical evidence: Incident tickets with priority, owner and resolution.
O5Third-party service providers that process financial data are assessed, and their assurance reports or equivalent evidence are reviewed.
Typical evidence: Provider list, review notes on each report, and follow-up on any exceptions.
Your gap list
Mark items Partial or Gap and they appear here, gaps first.
Answers stay in this page and are never uploaded.
What SOX 404 requires
- 404(a), management: the annual report must state management's responsibility for adequate internal control over financial reporting and contain an assessment of its effectiveness as of fiscal year-end (15 U.S.C. 7262(a)).
- 404(b), auditor: the registered public accounting firm that audits the financial statements attests to and reports on management's assessment. The statute excludes emerging growth companies, and 404(c) excludes issuers that are neither large accelerated nor accelerated filers.
- The rule: SEC Rule 13a-15 requires management to evaluate ICFR each fiscal year using a suitable, recognized control framework established through due process and public comment. The COSO Internal Control Integrated Framework is a well-known example.
- What ICFR is: a process, run by management and the board, designed to give reasonable assurance about the reliability of financial reporting. It includes policies that keep records accurate, ensure transactions are recorded and authorized as needed, and provide reasonable assurance about preventing or timely detecting unauthorized use or disposition of assets that could materially affect the financial statements (17 CFR 240.13a-15(f)).
How ITGCs fit in the audit
PCAOB standards integrate IT into the top-down audit approach. According to a PCAOB staff presentation citing the standards, the auditor must understand how IT affects the flow of transactions (AS 2201.36), obtain an understanding of the extent of manual and automated controls including the IT general controls important to the effective operation of the automated controls (AS 2110.B1), and consider the effectiveness of relevant ITGCs when deciding how much to test an automated control (AS 2301.27). The same presentation notes that benchmarking of automated application controls in later years is permitted (AS 2201.60).
In practice that means ITGC failures spread: if access or change controls over a financial application are weak, the auditor cannot rely on that application's automated controls or reports without more work, and a serious deficiency can become a significant deficiency or a material weakness. The definitions are in Regulation S-X (17 CFR 210.1-02(a)(4)).
The rule text and PCAOB material we read do not prescribe a list of ITGCs. Access, change management and operations is the grouping practitioners commonly use, and some firms add a fourth area for system development or acquisition. Treat the controls above as examples to compare with your own control matrix, then confirm scope with your auditor.
Where to go next
Many ITGC fixes are access and change process work. Design roles and check segregation of duties with the RBAC matrix builder, rehearse approval decisions in the change advisory board lab, and check your backups with the restore test policy builder. If customers also ask for assurance on your services, compare with the SOC 2 readiness checklist.
Questions people ask
What is SOX compliance?
SOX compliance means meeting the requirements of the Sarbanes-Oxley Act of 2002 that apply to companies with securities registered with the SEC. For IT, the key requirement is Section 404: management must report on the effectiveness of internal control over financial reporting (ICFR), and for most larger companies the external auditor must attest to that assessment.
What does SOX Section 404 require?
Section 404(a) (15 U.S.C. 7262(a)) requires each annual report to contain an internal control report that states management’s responsibility for adequate internal control over financial reporting and contains an assessment, as of the end of the most recent fiscal year, of its effectiveness. Section 404(b) requires the registered public accounting firm that audits the financial statements to attest to and report on that assessment, with exceptions.
Who is exempt from the auditor attestation in 404(b)?
By the statute’s text, 404(b) does not apply to emerging growth companies, and under 404(c) it does not apply to an issuer that is neither a large accelerated filer nor an accelerated filer, as defined in SEC Rule 12b-2. Management’s own 404(a) assessment still applies to those issuers. Check your filer status with your counsel.
What are IT general controls (ITGCs)?
ITGCs are the controls over the IT environment that the financial systems run in, as opposed to controls inside a single business process. A PCAOB staff presentation describes auditors considering the IT general controls that are important to the effective operation of automated controls. Practitioners usually group ITGCs into access to programs and data, program change management and computer operations.
Does SOX list which IT controls I must have?
Not in the rule text and PCAOB material we read. The SEC rule defines internal control over financial reporting and requires management to use a suitable, recognized control framework; it does not prescribe a list of IT controls. The three-area grouping on this page is common practice, and your auditor and management decide which controls matter for your systems.
Why do ITGCs matter to the auditor?
PCAOB standards say the auditor must understand how IT affects the flow of transactions, and that the effectiveness of relevant IT general controls affects how much testing an automated control needs. An automated control is generally lower risk if the relevant ITGCs are effective, and the auditor can sometimes benchmark it in later years. If ITGCs fail, more testing is needed or reliance is lost.
What is a material weakness?
SEC Regulation S-X defines a material weakness as a deficiency, or a combination of deficiencies, in internal control over financial reporting such that there is a reasonable possibility that a material misstatement of the annual or interim financial statements will not be prevented or detected on a timely basis. A significant deficiency is less severe but important enough to merit attention by those overseeing financial reporting.
How is SOX different from SOC 2?
SOX 404 concerns internal control over financial reporting at companies that report to the SEC. SOC 2 is an AICPA examination of a service organization’s controls against the Trust Services Criteria, usually requested by customers. A vendor’s SOC 2 report is not a SOX assessment, though overlapping controls such as access reviews and change approvals can serve both. See the SOC 2 readiness checklist.
How does this checklist work, and is it free?
It lists 18 example controls in three areas. Mark each Met, Partial, Gap or N/A and see coverage per area and a gap list. It runs in your browser, nothing is uploaded, and it is free to use. It is a self-assessment, not an audit or legal advice.
Sources
- 15 U.S.C. 7262 (Sarbanes-Oxley Act section 404), Legal Information Institute, accessed 3 November 2026
- 17 CFR 240.13a-15, Controls and procedures (management evaluation, framework, definition of internal control over financial reporting), eCFR, accessed 3 November 2026
- 17 CFR 210.1-02(a)(4), Regulation S-X definitions of material weakness and significant deficiency, eCFR, accessed 3 November 2026
- PCAOB staff presentation: Consideration of a Company's Information Technology Risks and Control Environment, 11 November 2024 (cites AS 2110, AS 2201 and AS 2301 requirements on IT and ITGCs)
- PCAOB AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements (standard text; the PCAOB site blocked our automated fetch, so we relied on the PCAOB staff presentation above for paragraph references)
Last reviewed 3 November 2026. The example controls are PlayCISO's practitioner-style wording, not text from the SEC or PCAOB. Not legal or audit advice.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.