SOX Compliance Checklist

TL;DR: A SOX compliance checklist is the set of controls a US public or IPO-track company has to run and evidence to satisfy the Sarbanes-Oxley Act: the IT general controls that protect financial systems, and the financial-process controls behind management's reporting. The IT general controls are the ground the automated controls above them stand on, and each control is worth only what its evidence can prove. The regulators weigh that evidence by the period it covers and by how objective its source is, so the controls that hold up are the ones backed by records the systems produce themselves, not artifacts assembled the week before the audit.

everything below is our copy — ship exactly this text

What belongs on a SOX compliance checklist

A complete SOX program runs two kinds of control: the IT general controls that protect the systems financial reporting depends on, and the financial-process controls behind management's own reporting assertions. Here is the full set, with what each control is and what "done" looks like.

1. Access to programs and data. Restrict the financial systems and data that feed reporting to named users by role, and grant, review and remove that access through a defined process. Done looks like a current population of who holds access, with a review record showing entitlements were checked and stale accounts removed. This is one of the SEC's own examples of an IT general control, and management's duty to keep expenditures to authorized transactions rests on it.
2. Segregation of duties. No single person should control a financial transaction end to end; where roles cannot be fully separated, an independent review or approval stands in and is evidenced. Done looks like a record that two different people performed the conflicting steps, not a policy that says it should be two people. The proof lives in the roles, approvals and change trails of the systems, not in a matrix on paper.
3. Change management. Every change to financial software, infrastructure and permissions is requested, reviewed, approved and deployed on a defined route, and the trail exists for the whole period. This covers both program changes and program development, two of the four IT general control areas the SEC names. Done looks like each production change tied to the approval that authorized it, with the people and dates attached.
4. Backup and recovery. The financial systems in scope are covered by a backup plan, and that plan has been proven by an actual restore, not just configured. Done looks like the record of a restore that ran; a backup you have never recovered from is a plan on paper, not a working control. This sits inside what the SEC calls computer operations.
5. Monitoring and activity logging. Activity on financial systems (logins, access attempts and changes to sensitive data) is logged, and someone reviews the log with an outcome that leaves a record. Done looks like a review that ends in a finding or a clean result on file, not a log that accumulates unread. The SEC counts this as on-going monitoring, and it weighs the objectivity of whoever performs the review.
6. Financial-process controls behind management's ICFR assertions. These are the controls over the transactions, reconciliations and reporting themselves: records that accurately reflect transactions, expenditures made only on authorization, and safeguards against unauthorized use of assets, the substance of internal control over financial reporting (ICFR). They are not IT controls, and a complete SOX program needs both them and the IT general controls above. The SEC says IT general controls alone ordinarily do not adequately address financial-reporting risks.
7. Scope the list to your own financial-reporting risks. Put a control on your list because it traces to a financial-reporting risk and a system that reporting depends on, not because a generic checklist named it. The SEC tells management to evaluate the IT general controls necessary for the reliable operation of controls that address those risks, and to skip the ones that only touch efficiency. Done looks like each control mapped to the risk and the system it protects.
8. Test the controls and evaluate the evidence. Management evaluates the effectiveness of internal control over financial reporting as of fiscal year-end, using a suitable, recognized framework, and the depth of testing follows the risk of each control. Done looks like evidence that covers the period rather than a single screenshot, and that an independent reviewer can inspect rather than take on trust. Inspecting the record beats asking whether the control ran.
9. Document the controls and the framework used. The annual report states management's responsibility for internal control over financial reporting and names the framework used to evaluate it, and each control carries the documentation the assessment rests on. Done looks like a control record that links its policy, its owner and its evidence, so the assessment can be traced. Documentation is what the assessment rests on; on its own it is not proof that a control operated.
10. Remediate deficiencies, and disclose what is not fixed. Deficiencies get an owner, a fix and a re-test, and management cannot conclude that internal control over financial reporting is effective while one or more material weaknesses remain. Done looks like a closed finding with the evidence that the fix held, and disclosure of what did not close. Re-testing after a fix needs its own evidence, and evidence closer to the assessment date carries more weight.

Start from your own financial-reporting risks

The fastest way to build the wrong SOX program is to copy a checklist whole. A generic list names controls that may have nothing to do with how your numbers are produced, and it stays silent on the system dependency that makes one of your controls matter more than the rest.

The SEC's guidance on management's report on internal control over financial reporting tells management to work the other way. Evaluate the IT general controls that are necessary for the proper and consistent operation of the controls that address financial-reporting risks, it says, and treat it as unnecessary to evaluate general controls that pertain to efficiency but are not relevant to those risks. The auditor is told to do the same thing from the top down, starting at the financial statement level and the overall risks to reporting, then working down to the significant accounts and the systems behind them.

So the first item on the list is not a control at all. It is the judgment that decides which controls belong: each one on your checklist should trace to a financial-reporting risk and a system that reporting depends on. That is the difference between a checklist you inherited and a control set you can defend.

A control is worth what its evidence can prove

A checklist can tell you which controls to run. It cannot tell you whether the evidence behind each one would survive an audit, and that is what the auditor tests. The regulators are unusually specific about what makes evidence strong, and their tests are worth reading before you gather a single artifact.

The PCAOB's auditing standard for an integrated ICFR audit ranks the ways a control can be tested, from weakest to strongest: inquiry, observation, inspection of documentation, and re-performance (AS 2201.50). Asking whether a control ran sits at the bottom. The same standard ties evidentiary weight to time: testing a control over a greater period of time provides more evidence than testing over a shorter one, and testing closer to the assessment date provides more still (AS 2201.52). The SEC's guidance adds a second axis, objectivity: evidence from a self-assessment performed by the person who operates the control provides less, due to the evaluator's lower degree of objectivity.

Read those two tests together and a pattern falls out. The auditor is told to value more of the period and a source with some distance from the control. That is exactly what an artifact assembled in the two weeks before the audit cannot supply. A screenshot taken the morning the assessor arrives describes one morning. The SEC's guidance already names an alternative: on-going monitoring, the normal, recurring activity that produces information about how controls operate across the year. A record read straight out of the source system, with the time it was collected and the population it covered attached, is on-going monitoring in that sense. Because a system produced it, it does not carry the objectivity discount that lands on a control owner grading their own work.

There is a third test, and it decides how much the IT side matters. The auditor's standard says an automated control "would generally be expected to be lower risk if relevant information technology general controls are effective" (AS 2201.47). The conditional is the whole point. The automated control your finance team relies on depends on the access, change and operations controls underneath it. That dependency is the defensible version of the idea that SOX turns on its IT general controls, and it comes from the auditor's own standard rather than from a vendor.

What SOX asks, and who owes which part

SOX is a US federal statute, and its demands on a public company run through two sections. Section 302 puts named officers on the hook: they certify each periodic report and the state of the internal controls and disclosures behind it, and they disclose any significant deficiency or fraud to the auditors and the audit committee. Section 404 is the one the checklist mostly serves. Management must assess the effectiveness of internal control over financial reporting as of fiscal year-end, and, for larger filers, the audit firm attests to that assessment. ICFR itself is defined broadly, as reasonable assurance about the reliability of financial reporting, covering records that accurately reflect transactions, expenditures made only on authorization, and the prevention or timely detection of unauthorized use of assets (17 CFR 240.13a-15(f)). The rule requires a suitable, recognized control framework to evaluate it, without naming a particular one.

Not every issuer owes the same thing. The Section 404(b) auditor attestation falls only on accelerated and large accelerated filers, and never on an emerging growth company; it comes from whichever registered public accounting firm issues the audit report, not from a particular tier of firm. A company can be past the $75M public-float threshold that defines an accelerated filer and still sit outside 404(b), because the revenue test keeps a company with annual revenue under $100M a smaller reporting company. Everyone filing an annual report still owes the 404(a) management assessment.

Companies on the way to an IPO get a defined on-ramp. A newly public company can omit the ICFR report from its first annual report, so the second is usually its first full 404(a) assessment, and an emerging growth company can stay outside 404(b) for up to five fiscal years after its first registered equity sale unless it trips another threshold first. Teams making sure SOX ITGC is in place before the first audit are working against that clock, not the annual one.

One distinction organizes the whole list. IT general controls govern the environment (access, change and operations) that financial systems run on; the financial-process controls govern the numbers themselves. Because IT general controls alone ordinarily do not adequately address financial-reporting risks, a program needs both, and the deeper treatment of the IT side is its own subject that lives on our guide to SOX compliance for IT.

Where the evidence comes from, control by control

Each control on the list has a record that proves it, and a point where that record stops and a person takes over. The sections below give both: the mechanism and the limit next to it. Auditors already run SOX ITGC audits from evidence collected this way, working from the same records the team sees rather than a separate set.

Access to programs and data

The evidence an auditor wants here is the population of who holds access and a review record showing it was checked. A user access review built from the systems themselves does that: it collects the user lists from connected systems and runs a pre-configured rule that flags any account whose email is not on the employee list. The review reaches an approved state only when a fresh collection confirms that the accounts which had to go were removed, so the closing evidence is a re-reading of the system, not a note that someone was asked to remove them. One limit: the rule flags the gap and holds the review open, but closing the gap happens in the source system, and addressing gaps in-product is still on the roadmap.

Segregation of duties

A segregation-of-duties finding turns on a record that two different people performed the conflicting steps. The platform does not decide which duties conflict, and it does not detect conflicts on its own; what it does is collect the records a conflict test needs. From a code repository, the merged-change evidence names who created, who reviewed and who merged each pull request, with the approval and merge dates. From a financial system such as Oracle Fusion, the journal-batch records carry Created By and Approved By, and the users-and-roles list carries the roles that define the conflict in the first place. The test is yours to define; the raw material for it is collected.

Change management

Change management is where the automated-control conditional bites, because a control the auditor is prepared to treat as low risk depends on the change trail underneath it holding. For a code repository, the collected evidence shows the branch protection rules, the repository rulesets with their enforcement level and their bypass actors (who may override the rule, which is the control's real weak point), the deployments, and the merged pull requests with creator, reviewer, merger and dates. One limit worth designing around: the automated merged-change evidence is a rolling one-week window, so the population for the full period comes from a custom collection over the timeframe you choose, not from the weekly feed.

Backup and recovery

Backup is the control where the checklist and the evidence most often diverge. The documented evidence for a cloud backup service covers the backup plans and their configuration, the protected resources, and the recovery points. What it does not cover is the result of a restore test, and that is the part the control turns on: the configuration proves a backup is set to run, and only a restore that someone has performed proves the data can be brought back. Collect the configuration from the system, and keep the restore-test result as evidence a person still has to produce.

Monitoring and activity logging

Monitoring evidence is easy to overstate, because a green status is not the same as a reviewed log. Analysis rules mark each record in an evidence table as a gap or a warning, and an evidence view resolves to a status of Gap, Auditable or Not Set. Read that status precisely: "Auditable" means no gaps were detected in one collection, inside one filtered scope, under the rules that were scoped to that view. It describes that collection, not the year, which is exactly why the period-coverage test matters. The cadence behind it is a weekly schedule, or an on-demand collection when you need a fresh reading.

The financial-process controls, and where they are owned

The financial-process half of the checklist, item six, is not IT, and it is the part of the list a system cannot produce on its own. ICFR requires reasonable assurance that records reflect transactions accurately, that expenditures happen only on authorization, and that unauthorized use of assets is prevented or caught (17 CFR 240.13a-15(f)). The SEC's warning that IT general controls alone ordinarily do not adequately address financial-reporting risks is why this half cannot be dropped. It is also outside what an evidence-collection platform is built for: the first-line controls over transactions and reconciliations are owned inside the finance organization, not automated from system data. What system data does reach is the access, role and approval records in and around financial systems, which is where the IT and financial halves meet.

Turn the checklist into a program

A list of controls becomes a program when three things happen to each control: it is tested, it is documented, and its failures are fixed and disclosed.

Testing is where evidence quality is decided. Management evaluates internal control over financial reporting as of fiscal year-end using a suitable, recognized framework (17 CFR 240.13a-15(c)), and because the auditor leans on the completeness and accuracy of the data your systems produce, that data has to be checkable. The PCAOB has reported that in about 17% of the audits it inspected, the auditor had not adequately tested the accuracy and completeness of information produced by the company, including reports from its IT systems. Evidence read from a source system can carry its own provenance to answer that: a collection timestamp, a record count, the history of prior collections, and the raw response behind the table, which is what supports an information-produced-by-the-entity review. Collections include all available items unless the evidence is flagged as a defined sample, so a lower count reflects a chosen sample rather than missing data. The reading is refreshed on a weekly schedule, or on demand.

Documentation is what the assessment rests on, and it is not the same as proof that a control operated. A finding record can hold the title, owner and severity, link the finding to the controls, requirements, policies and evidence around it, and carry the tasks and approvals through remediation. Today that record is created and managed by hand, which is worth knowing before you plan the work around it.

Remediation closes the loop, and disclosure is the part with teeth: management is not permitted to conclude that internal control over financial reporting is effective while one or more material weaknesses remain (17 CFR 229.308). Re-testing a fixed control needs its own evidence, and evidence closer to the assessment date carries more weight, so the cleanest proof that a fix held is a fresh reading of the system that shows the exception gone, the same move that closes an access review.

When you have worked the list, make one more pass. Next to each control, write the date the evidence behind it was produced, not the date you answered. The spread you find, with the technical controls usually resting on the oldest records, is the real output of the exercise. It tells you how much of your SOX position is a current measurement and how much is a memory.

Key takeaways

• A SOX checklist names two kinds of control: the IT general controls that protect financial systems, and the financial-process controls behind management's reporting. A complete program needs both, though the IT general controls are the half this page works through control by control.
• Scope the list to your own financial-reporting risks. The SEC tells management to evaluate the general controls that matter to reliable reporting and skip the rest, so a copied checklist is the wrong instrument.
• A control is worth what its evidence can prove. Read together, the auditor's standard and the SEC's guidance weigh evidence by the period it covers, its objectivity, and the general controls beneath any automated control, and a last-minute artifact scores badly on all three.
• The strongest evidence is a reading of the source system, with its collection time and population attached, refreshed across the period rather than assembled at the deadline.
• Know where the line is. Restore results, first-line financial-process controls and policy judgments still need people, and naming those limits plainly is what makes the rest credible.

Frequently asked questions

What is a SOX compliance checklist?

A SOX compliance checklist is the structured list of internal controls a US public or IPO-track company has to implement and evidence to satisfy the Sarbanes-Oxley Act. It covers the IT general controls that protect the systems financial reporting depends on and the financial-process controls behind management's assessment of internal control over financial reporting (ICFR). A complete assessment also reaches the documentation and reporting duties around those controls, so the list is where a program starts rather than the whole of SOX.

What controls does a SOX compliance checklist cover?

It covers the core IT general controls (logical access and user provisioning, segregation of duties, change management, backup and recovery, and monitoring and activity logging), alongside the financial-process controls that support management's ICFR assertions. Those five areas are the vocabulary the market uses; the SEC's own examples of IT general controls are program development, program changes, computer operations, and access to programs and data, which map onto the same ground. Which specific controls apply to you follows from your financial-reporting risks, not from the list alone.

Who has to follow SOX?

SOX applies to US public companies, meaning issuers registered with the SEC, including foreign private issuers listed in the US, and to companies preparing for an IPO. It governs their financial reporting and the IT systems behind it, through Section 302's certification by named officers and Section 404's annual assessment of internal control over financial reporting. A newly public company gets a short transition: its first annual report can omit the ICFR report, so the second is usually the first full Section 404(a) assessment.

What is the difference between SOX ITGC and financial-process controls?

IT general controls govern the IT environment (access, change and operations) that financial systems run on. Financial-process controls govern the transactions, reconciliations and reporting themselves. A complete SOX program needs both, and the distinction matters because the SEC says IT general controls alone ordinarily do not adequately address financial-reporting risks: they make the automated controls above them trustworthy, but they do not replace the controls over the numbers.

How is a SOX checklist different from SOX compliance software?

The checklist is the set of controls you have to satisfy. Software is one way to run them: to collect the evidence behind each control, test whether it is operating, and keep the records current between audits rather than rebuilding them at year-end. The checklist tells you what has to be true; software is about how you keep it true and provable, and a program can work the list with or without it.

‍