SOX Compliance Checklist

A SOX compliance checklist turns internal control over financial reporting into assigned, testable work. It gives finance, IT, compliance, process owners, and internal audit one operating plan for scope, control design, evidence, testing, deficiency evaluation, remediation, and management certification.

Use the checklist as a control calendar, not as a last-minute audit request list. Each item should name an owner, due date, reviewer, evidence standard, result, and escalation path. That structure makes it easier to see whether a control worked during the period and to fix failures before year-end.

This guide explains what to include, how to run the annual cycle, how to handle IT general controls, and how to keep proof connected to the work. It is practical guidance, not legal or audit advice. Confirm the exact scope, filing obligations, and testing approach with qualified counsel and your auditors.

In this guide:

• What is a SOX compliance checklist?
• Who should use a SOX compliance checklist?
• What should a SOX compliance checklist include?
• How do you build the annual SOX scope?
• How should you document and test controls?
• What belongs in the ITGC checklist?
• How do you manage evidence and deficiencies?
• When should each SOX activity happen?
• How can Process Street run the SOX compliance checklist?
• Frequently asked questions

What is a SOX compliance checklist?

A SOX compliance checklist is a repeatable sequence for operating a Sarbanes-Oxley program. It connects financial reporting risks to controls, control owners, testing procedures, evidence, review, and remediation. The checklist should make the current state of the program visible without asking people to reconstruct it from email, shared drives, and spreadsheets.

The legal foundation includes executive certification under Section 302 and management reporting on internal control over financial reporting under Section 404. The official Sarbanes-Oxley Act text provides the complete statutory language.

A useful checklist does not attempt to restate every legal requirement. It converts the program into verifiable actions. A reviewer should be able to trace a significant account or disclosure to a risk, a control objective, the control that addresses it, the evidence that shows performance, the test result, and the treatment of any exception.

What the checklist must prove

• The scope reflects the company’s current accounts, disclosures, processes, systems, locations, and service organizations.
• Every key control has a clear objective, owner, frequency, procedure, evidence standard, and reviewer.
• Testing addresses both design and operating effectiveness at the appropriate time.
• Evidence is complete, reliable, dated, and tied to the population and period under review.
• Exceptions and deficiencies are evaluated consistently, escalated to the right people, and remediated on time.
• Management has a defensible basis for its conclusions and certifications.

Who should use a SOX compliance checklist?

Public companies that have applicable reporting obligations need a coordinated SOX program. The checklist is also useful for companies preparing for an initial public offering, building public-company readiness, or strengthening financial controls before a transaction. Applicability and auditor-attestation requirements vary, so the company’s legal and audit advisers should confirm the exact obligations.

The checklist is shared work. Finance and accounting usually own close, consolidation, journal entry, revenue, expenditure, treasury, tax, and reporting controls. IT owns access, change management, computer operations, interfaces, and system reliability. Business process owners perform controls inside the transaction cycle. Internal audit may coordinate or independently test the program. Legal, compliance, the disclosure committee, senior management, and the audit committee each have defined oversight or reporting roles.

Role	Primary checklist responsibility	Evidence to retain
SOX program owner	Calendar, scope, RCM governance, testing coordination, issue tracking	Approved scope, status reports, review notes, issue log
Control owner	Perform the control exactly as designed and explain exceptions	Completed review, source reports, sign-off, exception notes
Control reviewer	Challenge the work and approve or reject the conclusion	Review comments, approval record, follow-up actions
IT owner	Operate access, change, operations, interface, and report controls	Tickets, access reviews, change approvals, logs, reconciliations
Internal audit or tester	Plan tests, obtain evidence, document results, and evaluate findings	Test sheet, sample support, conclusion, deficiency analysis
Management	Assess ICFR and support applicable certifications	Representation, disclosure support, final assessment

What should a SOX compliance checklist include?

The checklist should cover the full control lifecycle. A list that begins with evidence requests and ends with auditor delivery is too narrow. Start with governance and scope, then move through design, operation, testing, deficiency handling, certification support, and continuous improvement.

1. Confirm the reporting calendar, program governance, approvers, escalation path, and auditor coordination points.
2. Update materiality, significant accounts and disclosures, relevant assertions, business processes, locations, systems, reports, and service organizations.
3. Refresh process narratives, flowcharts, risk and control matrices, control descriptions, and ownership records.
4. Walk through material processes and confirm that the documented control matches the way work is performed.
5. Evaluate control design, including precision, segregation of duties, evidence expectations, and dependencies on systems or reports.
6. Plan testing based on control frequency, risk, reliance, prior results, changes, and the timing of management’s assessment.
7. Collect and validate evidence, test controls, document exceptions, and complete independent review.
8. Evaluate deficiencies individually and in combination, define remediation, track milestones, and retest completed fixes.
9. Complete roll-forward and year-end procedures, assemble management reporting support, and close outstanding review points.
10. Capture lessons from testing and audit so the next cycle starts with stronger control design and cleaner evidence.

Many organizations use the COSO Internal Control Integrated Framework as the recognized framework for designing and evaluating internal control. Its principles help teams look beyond individual checkboxes to the control environment, risk assessment, control activities, information and communication, and monitoring.

How do you build the annual SOX scope?

Scoping is the foundation of the program. If the scope is stale, even perfectly executed tests can focus on the wrong controls. Update the scope when the business changes, not only when the annual calendar says it is time. Acquisitions, divestitures, new systems, reorganizations, material process changes, new service providers, and significant accounting changes can all alter the risk picture.

Build the risk and control map

Start with significant accounts and disclosures, then identify the relevant assertions and the processes that create, authorize, record, process, and report the underlying transactions. Map systems, interfaces, reports, spreadsheets, service organizations, and end-user computing tools that support those processes. Then identify the controls that address a reasonable possibility of material misstatement.

The PCAOB AS 2201 standard describes a top-down, risk-based approach in which risk assessment drives the selection of controls and the evidence needed. Use that logic to challenge inherited key-control lists. A control should remain key because it addresses an important risk, not because it appeared in last year’s matrix.

• Reconcile the entity and location scope to current financial reporting and organizational data.
• Document quantitative and qualitative materiality considerations.
• Identify significant accounts, disclosures, assertions, and fraud risks.
• Map transaction flows, period-end reporting, systems, interfaces, reports, and service providers.
• Confirm entity-level controls and the oversight performed by management and the audit committee.
• Rationalize duplicate, redundant, or low-value controls without leaving risks uncovered.
• Record the rationale for every in-scope and out-of-scope decision that requires judgment.

How should you document and test internal controls?

A control description should be specific enough that a new owner, tester, or auditor can understand what happens and what proves it. Name who performs the control, what population or information they use, the exact review or action, how exceptions are resolved, how often it happens, and what evidence is retained. Avoid descriptions such as management reviews the report. State what management checks, the threshold or criteria applied, and how the conclusion is recorded.

Evaluate design before operating effectiveness

Design testing asks whether the control, if performed as described, can prevent or detect the relevant misstatement on time. Walkthroughs should trace a transaction from initiation through recording and reporting, corroborate inquiry with observation and inspection, and identify handoffs where the documented process differs from actual practice.

Operating-effectiveness testing asks whether the control operated as designed, by an appropriate person, throughout the relevant period. Define the population, assess its completeness, select items according to the approved methodology, inspect the evidence, record exceptions, and obtain review. Inquiry alone rarely provides enough proof for a control conclusion.

Assemble the evidence packet

Build the evidence packet as the control happens. The packet should include the source population, the selected item or period, the performer record, reviewer approval, supporting documents, the criteria applied, exception follow-up, and the final conclusion. If a system-generated report is used, retain the parameters and support for report completeness and accuracy when that reliability matters to the control.

Evidence question	What good evidence shows	Common failure
Who performed it?	Named owner with a dated completion record	Shared login or no identifiable performer
What was reviewed?	Source population, report, transaction, or reconciliation	Screenshot with no period, scope, or source
Which criteria were applied?	Threshold, expected result, checklist, or documented judgment	Sign-off with no visible review procedure
What exceptions appeared?	Exception list, disposition, approver, and follow-up	Clean conclusion that ignores unresolved items
Who reviewed it?	Independent approval with comments or challenge where needed	Reviewer approval recorded before the work was complete
Can it be reproduced?	Inputs, parameters, version, and retained support	Evidence that cannot be tied back to the population

What belongs in the ITGC checklist?

Information technology general controls support the systems, data, reports, and automated controls used in financial reporting. The exact scope depends on how technology affects the relevant processes and assertions. Start from the financial reporting risk and work back to the systems and technology controls that matter. Do not copy a universal IT checklist into scope without that connection.

Test access, change, and operations controls

• Logical access: user provisioning, modification, termination, privileged access, authentication, periodic access review, and segregation of duties.
• Program change: authorized requests, testing, approval, migration, emergency changes, developer access, and separation between development and production.
• Computer operations: scheduled jobs, interface monitoring, incident handling, backup and recovery where relevant, and timely resolution of processing failures.
• System implementation: data conversion, configuration, testing, approvals, access, and go-live controls for new or materially changed systems.
• Reports and interfaces: completeness and accuracy of information used in controls, including report parameters, source data, transformations, and user-developed logic.
• Service organizations: current reports, scope and period coverage, exceptions, subservice organizations, complementary user-entity controls, and bridge support where needed.

Document the dependency between each ITGC and the business or automated controls that rely on it. When an ITGC fails, evaluate the impact on those dependent controls and determine whether compensating procedures provide enough evidence. A failed access or change control is not an isolated technology issue when it affects the reliability of financial reporting.

How do you manage evidence, exceptions, and deficiencies?

Treat evidence and issue management as part of control execution. Each request should identify the control, period, population, required artifact, owner, reviewer, due date, and accepted format. When evidence is incomplete, route it back with a reason rather than marking the task complete and leaving the explanation in email.

Separate an exception from a deficiency

An exception is a test result that requires evaluation. A deficiency is a conclusion about the design or operation of internal control. Record the facts first: what failed, which control objective and assertion are affected, the population and period involved, how the issue was detected, and whether other controls address the risk. Then apply the approved deficiency-evaluation framework.

AS 2201 distinguishes a design deficiency from an operating deficiency and explains that severity depends on the reasonable possibility and potential magnitude of misstatement. Evaluate related deficiencies together, consider compensating controls at the necessary precision, and involve the appropriate management, audit, and governance stakeholders.

Track remediation to verified closure

1. Assign one accountable owner and define the root cause, not only the failed sample.
2. Write the remediation plan as a control-design change with milestones and a target date.
3. Assess whether an interim or compensating control is needed while the fix is in progress.
4. Collect implementation evidence and confirm the revised control is understandable to the owner.
5. Allow enough operating history for a meaningful retest when the control frequency requires it.
6. Retest independently, document the conclusion, and close only after review and approval.
7. Update narratives, matrices, training, system configuration, and future test plans so the fix persists.

When should each SOX activity happen?

A rolling calendar reduces the year-end surge and gives the company time to remediate. The exact dates depend on the fiscal year, filing calendar, control frequency, auditor plan, and program maturity. Use the cadence below as an operating pattern, then tailor it with the people responsible for the assessment and audit.

Phase	Core activities	Exit criteria
Plan and scope	Governance, materiality, significant accounts, locations, systems, service providers, fraud risks	Approved scope and responsibility map
Document and walk through	Narratives, flowcharts, RCM, walkthroughs, design assessment, change analysis	Current documentation and resolved design gaps
Interim test	Population validation, sample testing, ITGC testing, issue evaluation	Reviewed results and owned remediation plans
Remediate and retest	Root cause, control redesign, implementation, operating history, retest	Verified closure or clear year-end treatment
Roll forward	Changes since interim testing, remaining periods, new incidents, updated populations	Support through the assessment date
Conclude and certify	Aggregate deficiencies, management assessment, disclosure support, auditor requests	Approved conclusion and retained support
Improve	Lessons learned, control rationalization, automation candidates, calendar reset	Prioritized changes for the next cycle

Quarterly control-health review

Between major testing windows, review late controls, rejected evidence, access changes, system changes, incidents, recurring exceptions, unresolved deficiencies, and overdue remediation. Reassess scope when a business event changes the financial reporting risk. A short quarterly review keeps the annual assessment from depending on assumptions that became stale months earlier.

How can Process Street run the SOX compliance checklist?

Process Street can turn the checklist into an executable control workflow. Teams can assign owners, require form fields and file uploads, set due dates, route approvals, use conditional paths for exceptions, and keep the resulting activity history attached to each workflow run. The workflow automation compliance guide explains how required steps, approvals, evidence capture, and audit trails fit together.

Run the control workflow in Process Street

1. Create one governed workflow for each repeatable control or tightly related control family.
2. Define the control objective, owner, frequency, source population, procedure, evidence, and reviewer inside the workflow.
3. Require the evidence fields and files needed to support the conclusion before the task can advance.
4. Route reviewer approval inside the workflow and return incomplete work with a visible reason.
5. Branch exceptions into follow-up tasks with owners, due dates, severity inputs, and escalation rules.
6. Launch remediation and retest workflows from failed results so the issue record remains connected.
7. Use scheduled runs and dashboards to monitor upcoming, late, rejected, and completed controls across the calendar.

Start with the SOX Compliance Checklist template, then tailor it to the company’s scope and testing methodology. Connect related work through the audit management workflow so requests, evidence, findings, and remediation do not become separate tracking systems.

Keep professional judgment in the loop

Workflow structure improves consistency, but it cannot decide the company’s legal obligations, replace the control owner’s judgment, determine deficiency severity by itself, or substitute for independent audit work. Use the system to enforce the agreed procedure and preserve proof. Keep consequential judgments with qualified people and record the basis for their decisions.

Frequently asked questions