SOX IT Compliance: ITGCs, Section 404 and What Vendors Must Provide

SOX IT compliance is about one question: can the numbers in a public company's financial statements be trusted, given the systems that produce them? The Sarbanes-Oxley Act requires US-listed companies to maintain internal control over financial reporting and to assess it every year, with executives personally certifying the results. Because financial data lives in ERP, billing, payroll, revenue and data platforms, much of that control is IT control.

For IT and software companies, SOX shows up in two ways: as an internal requirement if you are, or plan to be, listed in the US, and as a customer requirement if your software or service supports a listed company's financial reporting. This guide explains the relevant sections of the Act, IT general controls and how auditors test them, the role of SOC 1 reports, the documents you need, and the findings auditors raise most often.

What is SOX?

The Sarbanes-Oxley Act of 2002 is a US federal law that set new requirements for public company boards, management and accounting firms. The sections most relevant to IT are:

• Section 302: the CEO and CFO must certify in each annual and quarterly report that they have reviewed it, that it is not misleading, that financial statements fairly present the company's condition, and that they are responsible for establishing and maintaining disclosure controls and internal controls.
• Section 404(a): management must include in the annual report its assessment of the effectiveness of internal control over financial reporting (ICFR).
• Section 404(b): the external auditor must attest to the effectiveness of ICFR, for accelerated and large accelerated filers. Smaller non-accelerated filers are exempt from 404(b), and emerging growth companies have a time-limited exemption.
• Section 802: criminal penalties for destroying, altering or falsifying records in federal investigations, and audit workpaper retention requirements.
• Section 906: criminal penalties for executives who knowingly certify reports that do not comply.

The SEC sets rules for management's assessment, and the Public Company Accounting Oversight Board (PCAOB) sets the auditing standards, principally AS 2201 for integrated audits of ICFR. Most companies use the COSO Internal Control: Integrated Framework (2013) as the framework for ICFR.

History and why SOX was introduced

SOX was passed in July 2002 after major accounting scandals at Enron, WorldCom and other companies had destroyed investor confidence. Investigations found that executives had manipulated financial results, auditors had conflicts of interest, and internal controls were weak or overridden. The Act created the PCAOB to oversee auditors, strengthened auditor independence, made executives personally accountable for financial reports, and required companies to maintain and report on internal controls.

IT controls became central because by 2002 financial reporting depended on information systems. If anyone could change a revenue calculation in production, or a terminated employee could still post journal entries, the financial statements could not be relied on, however good the accounting policies were.

Who must comply?

• US public companies with securities registered with the SEC, including their subsidiaries worldwide. An Indian or European subsidiary of a US-listed group is in scope for the group's ICFR.
• Foreign private issuers listed in the US, which file annual reports on Form 20-F and are subject to section 404.
• Companies preparing for a US IPO, which need to build controls before listing.
• Service organisations whose systems are relevant to customers' ICFR: payroll processors, ERP and billing SaaS, cloud data platforms, IT outsourcers running finance systems. They are not regulated by SOX but must support customers' compliance, usually with a SOC 1 report.

Private companies are generally not subject to SOX, although lenders, investors and acquirers sometimes ask for SOX-style controls.

IT general controls: the core of SOX for IT

IT general controls (ITGCs) are controls over the IT environment that support the reliable operation of automated application controls and the integrity of financial data. Auditors usually group them into four domains:

ITGC domain	What auditors expect	Typical evidence
Access to programs and data	Access granted on approval and based on role; timely removal on termination; periodic user access reviews; restricted privileged and database access; segregation of duties; strong authentication	Access request tickets, termination lists matched to account removals, quarterly review sign-offs, privileged user lists
Program changes	Changes to financially relevant applications, databases and infrastructure are requested, tested, approved and migrated by someone other than the developer; emergency changes are reviewed	Change tickets, test evidence, approvals, deployment logs, a population of all changes from the system
Program development	New systems and major upgrades follow a controlled life cycle with testing, data conversion checks and go-live approval	Project documentation, test sign-off, data migration reconciliations
Computer operations	Batch jobs and interfaces are scheduled, monitored and failures resolved; backups and recovery are performed; incidents are managed	Job schedules and logs, failure tickets, backup reports, restore tests

Auditors also test application controls (automated checks such as three-way matching or calculation logic) and information produced by the entity (reports used in controls, which must be complete and accurate). Effective ITGCs allow auditors to rely on application controls; weak ITGCs force much more manual testing and can lead to deficiencies.

Segregation of duties

One person should not be able to both create and approve a transaction, or both write code and deploy it to a financial system without independent review. In small teams this is hard, so companies design compensating controls, such as independent review of deployment logs or of journal entries posted by administrators.

SOX controls in modern cloud and DevOps environments

Many ITGC practices were designed when finance ran on a single on-premises ERP with a separate operations team. Cloud and DevOps change how controls look, not whether they are needed:

• Change management through pipelines. Instead of a change advisory board approving each release, auditors can rely on pipeline controls: protected branches, mandatory peer review, automated tests, and deployment only by the pipeline service account. The evidence is the pipeline configuration plus a complete list of deployments with linked reviews.
• Infrastructure as code. Changes to databases, networks and permissions in the cloud become code changes with the same review trail, which helps both the program change and access domains.
• Just-in-time privileged access. Temporary, approved and logged elevation for engineers replaces standing production access and addresses segregation of duties in small teams.
• SaaS financial applications. When billing, revenue or payroll runs in SaaS, the company's ITGCs shift to user access and configuration within the SaaS tool, while the vendor's SOC 1 covers the platform.
• Data pipelines and reports. Revenue and analytics data warehouses that feed financial reporting need change control on transformation code and controls on the completeness of reports.

Talk to auditors early when changing tools. A well-designed automated control is usually easier to test than a manual approval, but auditors need to understand it before the year-end testing window.

Deficiencies and material weaknesses

Control failures are classified by severity. A deficiency exists when a control does not allow timely prevention or detection of misstatements. A significant deficiency is less severe than a material weakness but important enough to merit attention by those overseeing financial reporting. A material weakness is a deficiency, or combination, such that there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis. A material weakness must be disclosed, management cannot conclude ICFR is effective, and it often affects share price and auditor fees. ITGC failures alone are rarely material weaknesses, but pervasive access or change failures can contribute to one.

Service organisations and SOC 1 reports

When a listed company relies on a service provider for a process relevant to financial reporting, it must understand and evaluate the provider's controls. The usual evidence is a SOC 1 Type II report, in which an independent auditor reports on the design and operating effectiveness of the provider's controls relevant to customers' ICFR over a period. The customer then tests the complementary user entity controls listed in the report, such as reviewing its own users' access to the SaaS product. A SOC 2 report covers security and related criteria and does not replace a SOC 1 for SOX purposes, though auditors may use parts of it.

Vendors without a SOC 1 report can expect customers' auditors to request direct testing, questionnaires or onsite reviews, which are disruptive for both sides.

How to implement SOX IT controls step by step

1. Scope financially relevant systems: from significant accounts and processes, identify the applications, databases, infrastructure and interfaces that support them, and the reports used in controls.
2. Assess risks for each system: what could go wrong that would lead to a misstatement.
3. Design ITGCs for access, change, development and operations, and identify key application controls.
4. Document controls in a risk and control matrix: control description, owner, frequency, evidence.
5. Implement in tools: approval workflows, role-based access, deployment pipelines with review, job monitoring and alerting.
6. Collect complete populations: auditors sample from system-generated lists of all changes, users and terminations, so the lists must be complete and reliable.
7. Test controls through internal audit or a SOX team before external audit.
8. Manage service providers: obtain and review SOC 1 reports and test complementary user entity controls.
9. Remediate deficiencies early so controls operate long enough before year end to be tested.
10. Support management certification and the external audit.

Documentation required

• Scoping documentation linking significant accounts to systems.
• Risk and control matrix covering ITGCs and application controls.
• Process narratives or flowcharts for key processes.
• Access management, change management, SDLC and operations policies and procedures.
• Evidence of controls operating: tickets, approvals, review sign-offs, logs.
• System-generated populations and evidence of their completeness.
• Service provider SOC 1 reports and bridge letters, with documented reviews.
• Deficiency evaluations and remediation plans.
• Management's assessment and supporting test results.

Audit and assessment

There is no SOX certification. Management assesses ICFR each year and reports on it in the annual report (Form 10-K, or Form 20-F for foreign private issuers). For accelerated and large accelerated filers, the external auditor performs an integrated audit under PCAOB AS 2201 and issues an opinion on ICFR. Internal audit and SOX programme teams typically test controls throughout the year.

Timeline and cost considerations

SOX is an annual cycle. Companies preparing for an IPO usually build their control environment over the year or more before listing, because 404(a) management assessment applies from the second annual report and 404(b) attestation applies when the company is no longer exempt. Cost drivers include the number of systems in scope, manual versus automated controls, the volume of changes and users, internal audit and SOX programme staff, external audit fees, GRC tools, and remediation. Automating controls in tools (role-based access, enforced pipelines) usually lowers testing effort over time.

Benefits and consequences of non-compliance

Effective controls give investors and boards confidence in financial results and reduce the risk of fraud and error. For vendors, a clean SOC 1 report becomes a competitive advantage with listed customers.

Consequences of failures include disclosure of material weaknesses, qualified auditor opinions on ICFR, SEC enforcement, delisting risk in serious cases, and personal criminal liability for executives who knowingly certify false reports under section 906, with fines of up to 1 million dollars and imprisonment of up to 10 years, rising to 5 million dollars and 20 years for wilful violations.

Common mistakes and challenges for IT companies

• Incomplete populations. If the change list or user list is not complete and accurate, sample testing is meaningless.
• Developers with production access to financial systems without independent monitoring.
• Late access removal for terminated users, especially in SaaS tools outside single sign-on.
• Undocumented emergency changes.
• Shared or generic admin accounts that make actions untraceable.
• Ignoring complementary user entity controls listed in vendors' SOC 1 reports.
• Spreadsheets as key reports without controls over their completeness and accuracy.

Best practices, tools and technologies

• Use single sign-on and automated provisioning and de-provisioning for all financially relevant applications.
• Enforce change management in the pipeline: no direct production changes, mandatory review, deployment by automation.
• Generate audit-ready reports from systems: lists of users, roles, changes and deployments with timestamps.
• Build segregation of duties into application roles, with conflict checks.
• Log administrative actions and data changes in financial applications.
• Use COBIT objectives to structure ITGCs and a GRC tool to manage testing.

We build approval workflows, role design and audit logs into ERP and CRM systems and finance-related applications.

How SOX relates to other frameworks

Framework	Relationship
COSO	The internal control framework most companies use for ICFR under SOX.
COBIT	Common reference for designing and testing IT general controls.
SOC 1	The report service providers give customers for SOX reliance.
SEC cybersecurity disclosure rules	Separate SEC requirements to disclose material cybersecurity incidents and describe cyber risk management.
ISO/IEC 27001 and SOC 2	Security programmes whose access and change controls overlap with ITGCs.

Real-world implementation examples

Annual reports filed with the SEC are public, and companies that disclose material weaknesses describe them, often including IT general control failures in user access or change management at specific systems. Reading these disclosures shows which control failures auditors treat as serious.

An illustrative case for a SaaS billing vendor: several listed customers' auditors send questionnaires each year. The vendor obtains a SOC 1 Type II report covering access, change management and the billing calculation controls, lists complementary user entity controls clearly, and provides a bridge letter for customers with December year ends. Customer audit requests fall to a handful of follow-up questions.

Next steps

1. Identify whether SOX applies to you directly or through customers.
2. Scope financially relevant systems and processes.
3. Build or tighten access, change and operations controls in your tools.
4. If you are a vendor, plan a SOC 1 report.
5. Test controls before the external auditor does.

Frequently asked questions

Does SOX apply to private companies?

Generally no. It applies to companies with securities registered with the SEC. Private companies may adopt SOX-style controls before an IPO or at investors' request.

Does SOX apply to foreign companies?

Yes, to foreign private issuers listed in the US, and to foreign subsidiaries of US-listed groups as part of the group's internal control.

What are SOX ITGCs?

IT general controls over access to programs and data, program changes, program development and computer operations for systems relevant to financial reporting.

What is the difference between section 302 and section 404?

Section 302 requires CEO and CFO certifications in each periodic report. Section 404 requires an annual management assessment of internal control and, for larger filers, auditor attestation.

Do SaaS vendors need SOX compliance?

Not directly, unless they are listed. Vendors whose systems support customers' financial reporting typically provide SOC 1 reports so customers can rely on their controls.

Is a SOC 2 report enough for SOX?

Usually not. SOX reliance is based on SOC 1 reports, which cover controls relevant to financial reporting. Auditors may use parts of a SOC 2 for ITGC-type controls.

What is a material weakness?

A deficiency, or combination of deficiencies, in internal control such that there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis.

Who enforces SOX?

The SEC enforces the Act and its rules; the PCAOB oversees auditors; the Department of Justice prosecutes criminal violations.

Are smaller companies exempt from SOX 404?

Non-accelerated filers are exempt from the auditor attestation in section 404(b) but still must perform management's assessment under 404(a). Emerging growth companies have a time-limited exemption from 404(b).

Which framework do companies use for SOX?

Most use the COSO Internal Control: Integrated Framework (2013), with COBIT often used for IT controls.

What are the penalties for false SOX certifications?

Under section 906, executives who knowingly certify non-compliant reports face fines up to 1 million dollars and up to 10 years in prison, and up to 5 million dollars and 20 years for wilful certification.