SOX compliance for software: What financial apps must follow
- Riya Thambiraj
- Industry Playbooks
- Last updated on
Key Takeaways
SOX applies to any software that touches financial reporting data - not just the finance team's tools
Section 404 requires IT General Controls to be documented, tested, and audited every single year - no exceptions
Immutable audit trails are the foundation - who changed what, when, with what approval, and who reviewed it
Segregation of duties means the person who enters a transaction can't be the same person who approves it - your app's access controls must enforce this
Building SOX controls into a financial app from the start adds 15-20% to development cost; retrofitting an existing system can take 6-12 months and cost 4x more
In 2017, the SEC charged a software company's CFO for certifying financial statements he knew were inaccurate. The company had been using its own internal platform to report revenue. The platform had no audit trail. Data had been changed manually. Nobody could prove who changed what or when.
The CFO faced a personal fine of $1.5 million and a bar from serving as an officer or director of any public company.
That's the story most people miss about SOX. It's not just about accounting. It's about the software those accountants use. If your financial reporting system can't prove who touched the numbers - and when - you have a SOX problem.
TL;DR
SOX (Sarbanes-Oxley Act) requires publicly traded companies to document and test their IT General Controls (ITGCs) every year. For software that touches financial reporting, this means immutable audit trails, strict access controls with segregation of duties, documented change management, and disaster recovery. CEO and CFO personally certify these controls under Section 302 and 404 - with up to 20 years in prison for false certification. Building SOX controls from the start adds 15-20% to development cost. Retrofitting costs 4x more.
What SOX is (and why it was passed)
Sarbanes-Oxley was passed in 2002. Not because of abstract risk. Because of Enron and WorldCom.
Enron's collapse wiped out $74 billion in shareholder value. WorldCom had fraudulently inflated its assets by $11 billion. In both cases, executives had certified financial statements they knew were false. Auditors had signed off without adequate scrutiny.
SOX compliance hasn't gotten cheaper. The KPMG 2025 SOX Survey - covering 146 companies - found the average annual SOX program cost hit $2.3 million in FY24, up from $1.6 million in FY22. That's a 44% increase in two years. Hours spent on SOX compliance grew 32% over the same period.
IT controls are the biggest driver of that growth. Protiviti's 2023 SOX compliance survey - covering 560+ respondents - found IT access controls and security ranked as the #1 area where audit and finance leaders encounter deficiencies. Segregation of duties conflicts, gaps in user access review, and termination procedures were the most common root causes.
Congress passed SOX to make executives personally accountable for the accuracy of their company's financial reporting. The law created criminal liability for false certifications and required companies to demonstrate - with documented evidence - that their internal controls actually worked.
IT systems became part of that equation the moment auditors realized that financial statements were generated by software. If the software could be manipulated without a trace, the financial statements couldn't be trusted.
Who needs to comply
SOX applies to:
US public companies registered with the SEC - any company listed on NYSE, NASDAQ, or other US exchanges
Foreign private issuers listing on US exchanges - they follow modified SOX requirements
Subsidiaries of public companies where financial results are consolidated into parent company filings
Companies preparing for an IPO - SOX readiness is evaluated in the months before listing
The indirect reach: If your software company provides a financial reporting platform, revenue recognition tool, ERP integration, or any system that feeds a public company's financial statements - that system will be examined in their SOX audit. You don't have to be a public company for your software to be in scope.
Companies that process their clients' financial data should expect annual security and control questionnaires from those clients' audit teams.
The two sections that matter for software
Section 302 - personal certification
The CEO and CFO must sign a certification with every quarterly and annual financial filing. That certification states:
The financial statements don't contain material misstatements
They've evaluated the effectiveness of the company's disclosure controls
They've disclosed to the auditors any significant deficiencies or material weaknesses in internal controls
This isn't just a formality. A CFO who signs Section 302 and later the controls are found to be defective can face personal liability. If the false certification was knowing, that's up to $1 million in fines and 10 years in prison. If it was willful, it's up to $5 million and 20 years.
That personal liability changes how executives think about their software systems. When your CFO asks whether the financial reporting platform has an audit trail, they're not being paranoid - they're protecting themselves.
Section 404 - internal controls assessment
Section 404 is where software teams feel SOX most directly.
Management must document and assess the effectiveness of internal controls over financial reporting (ICFR) every year. For accelerated filers, the external auditor must independently attest to that assessment.
For IT systems, Section 404 assessment covers what the PCAOB (Public Company Accounting Oversight Board) calls IT General Controls (ITGCs) - the baseline controls that govern every IT system involved in financial reporting.
IT general controls - what auditors actually check
When auditors examine a financial software system, they look at four control categories:
| ITGC Category | What It Covers | Example Controls |
|---|---|---|
| Access Management | Who can access financial data and what they can do with it | User provisioning, role-based permissions, access reviews, terminated employee offboarding |
| Change Management | How software changes are tested and deployed | Code review requirements, separation of dev/test/prod environments, change tickets, deployment approvals |
| Computer Operations | System reliability and job monitoring | Scheduled job completion monitoring, exception handling, escalation procedures |
| Backup and Recovery | Data protection and restoration capability | Backup frequency, restoration testing, recovery time objectives, off-site storage |
Every system that feeds financial statements gets tested against all four categories. That includes your general ledger, ERP, revenue recognition software, consolidation tool, financial reporting platform, and any integrations between them.
A weakness in any one of these categories can be a SOX finding. If a finding is significant enough, it becomes a "material weakness" - which must be disclosed publicly in the company's annual filing. That disclosure can tank the stock price.
"We've built financial reporting tools for companies preparing for an IPO. The audit team shows up before listing and if they find that developers had direct production access, or that the audit log has gaps - those are findings that can delay the IPO or force a material weakness disclosure. That's a very expensive problem to fix at the wrong moment."
Ashit Vora, Captain at RaftLabs
What SOX requires your financial app to do
Immutable audit trails
This is the most critical requirement. Every financial transaction, configuration change, and user action that could affect financial reporting must be logged in a way that can't be altered.
The log must capture:
Who performed the action (individual user ID, not a shared account)
What was changed (before and after values)
When it happened (timestamp with timezone)
Why it was approved (approval record or workflow reference)
"Who changed this figure?" should always have an answer. If the answer is "we can't tell," that's a finding.
Shared admin accounts are a SOX red flag. If three people share an "admin" login, the audit trail becomes useless. Every user needs their own credentials.
ℹ️ Immutable means immutable
Audit logs must be stored in a system that prevents modification - including by system administrators. Logs stored in a table that a DBA can update don't satisfy this requirement. Use append-only storage, write-once log systems, or a separate logging service where the application can write but never delete or update records.
"The most common SOX finding we see in inherited codebases is a shared admin account. It's always the same story: 'We only had three people in the early days.' But the audit trail is now useless for proving who made a specific change. Individual accounts, assigned from day one, are non-negotiable for any financial system."
RaftLabs Engineering Team
Segregation of duties
SOX requires that no single person controls more than one step in a critical financial process. This is called segregation of duties (SoD).
Common SoD requirements:
The person who creates a journal entry can't be the person who posts it
The person who sets up a vendor can't be the person who approves payments to that vendor
The developer who writes financial reporting code can't be the person who deploys it to production
The person who has access to modify transaction records can't be the same person who reconciles those records
Your app's permission system must enforce these boundaries at the role level. It's not enough to have a policy saying users shouldn't do both things - the system must make it impossible.
Role conflict analysis is part of the SOX audit process. Auditors run queries looking for users who hold combinations of permissions that create SoD violations.
Change management
Every change to a financial system - code, configuration, infrastructure - must go through a documented process:
- Change request - what's changing and why
- Impact assessment - which financial processes or reports could be affected
- Testing - evidence that the change was tested in a non-production environment
- Approval - sign-off from someone other than the person making the change
- Deployment record - who deployed it, when, and whether it succeeded
Emergency changes ("break-glass" access to production) need to be documented even more carefully, with a post-change review.
Developers who can push code directly to production without any approval process are a SOX finding.
Access reviews
User access must be reviewed periodically - at minimum quarterly for high-privilege accounts, and at least annually for all accounts. When an employee changes roles or leaves, their access must be revoked promptly.
The review isn't just "confirm this person still works here." It's "confirm this person still needs this specific level of access for their current role."
Your app needs a way to generate access reports that auditors can review. Typically: a list of all users, their roles, when the role was last reviewed, and who approved it.
The automation gap makes this worse. The same KPMG survey found that only 17% of SOX controls are automated - down from 21% in FY22 - even as the average number of in-scope IT systems jumped from 17 to 40 over the same period. More systems, less automation, and manual controls at 45% of the total. That's why SOX compliance hours keep growing.
When IT controls fail, the consequences show up in public filings. KPMG's 2024 analysis of 3,502 annual reports found 8% of companies disclosed a material weakness. IT, software, security, and access issues ranked as the 3rd most common driver - and the rate has been rising steadily since 2021. A disclosed material weakness is public information that can move a stock price.
SOX vs SOC 2 - what's the difference
These two frameworks often come up together in financial software conversations. They're not the same thing.
| SOX | SOC 2 | |
|---|---|---|
| What it is | US federal law | Voluntary audit standard |
| Who it applies to | Publicly traded companies | Service providers handling customer data |
| Who enforces it | SEC, PCAOB, DOJ | Your customers (via vendor contracts) |
| Focus | Financial reporting accuracy | Data security and availability |
| Audit frequency | Annual (mandatory) | Annual (by choice) |
| Personal liability | Yes - CEO/CFO criminally liable | No |
| Report type | Internal assessment + auditor attestation | SOC 2 Type I or Type II report |
In practice, a B2B SaaS company selling to public companies often needs both. SOC 2 to win the contract (enterprise procurement requires it). SOX compliance for the specific controls that touch financial data.
About 40% of the controls overlap. An access management system built for SOC 2 likely satisfies most of the SOX ITGC access requirements too.
How SOX affects your app architecture
These requirements translate directly into technical decisions:
| SOX Requirement | Architecture Impact |
|---|---|
| Immutable audit trails | Append-only audit log table or separate log service. No update/delete permissions on log records. Separate storage from transactional database. |
| Segregation of duties | Granular role-based access control (RBAC). Automated conflict detection when assigning roles. Cannot bypass roles through shared accounts or direct DB access. |
| Change management | Separate development, testing, and production environments with no direct production access for developers. CI/CD pipeline with mandatory approval gates. |
| Access reviews | Admin dashboard to generate user access reports. Automated alerts for accounts inactive over 90 days. Formal access review workflow with sign-off tracking. |
| Backup and recovery | Documented RTO/RPO with regular restoration tests. Evidence that backups actually work, not just that they run. |
| Data retention | 7-year retention for financial records and IT logs. Automated retention enforcement with documented deletion procedures. |
The shared admin account problem
This comes up constantly in SOX audits of older systems. A system was built with one "admin" user. Everyone on the finance team knows the password. The audit trail shows "admin" changed a figure on March 14 at 2:47 PM.
Who was it? Unknown.
That's a finding. The fix requires either separate accounts for each user, or a privileged access management (PAM) system that requires individual authentication before accessing shared credentials, and logs that authentication.
Questions to ask your development partner
-
"How do you implement immutable audit trails?" - Look for append-only log storage, separate from the transactional database, with no update or delete permissions. "We log to a table" is not the right answer if that table can be modified.
-
"How does your role and permission system handle segregation of duties?" - They should describe granular RBAC with the ability to detect and block conflicting role assignments. Ask for an example of a SoD rule they've enforced in a previous financial system.
-
"How do developers deploy changes to production?" - Any answer that includes "they have direct access" is a red flag. Look for mandatory peer review, separate deployment accounts, and approval workflows before anything reaches production.
-
"What does the access review process look like?" - The system should be able to generate a complete list of users, roles, and last review dates. Ideally with a built-in review workflow, not a manual Excel export process.
-
"How do you handle emergency access to production?" - "We give temporary access when needed" isn't enough. Look for break-glass procedures with automatic logging, time-limited access, and mandatory post-incident review.
-
"Have you built systems that have been through a SOX ITGC audit?" - Experience matters enormously here. A team that has built SOX-compliant systems knows what auditors actually look for, not just what the frameworks say.
-
"How do you separate the development and production environments?" - There should be no path from a developer's workstation to production data without going through a controlled deployment process. Test data should never include real financial data.
Your SOX compliance checklist
Before development starts:
Map every IT system that touches financial reporting data
Document data flows from source transactions to financial statements
Identify which users will have access to financial data and what roles they'll need
Confirm there are separate development, testing, and production environments planned
Engage legal and audit counsel to define the ITGC scope
During development:
Build individual user accounts - no shared admin credentials
Implement granular RBAC with documented role definitions
Build SoD conflict detection into the role assignment process
Build immutable audit logging for all financial data changes (append-only, no delete)
Capture before/after values, user ID, timestamp, and approval reference in every log record
Build user access reporting for periodic access reviews
Set up mandatory code review and approval gates in the deployment pipeline
Document change management procedures and enforce them in the CI/CD workflow
Implement automated backup with documented restoration testing procedures
Before go-live:
Complete a user access review with documented sign-offs
Test restoration from backup (not just confirm backups are running)
Run a segregation of duties analysis on all planned user roles
Document the ITGC controls in a format auditors can review
Conduct a walkthrough with the internal audit team before the external audit
Establish a process for quarterly access reviews going forward
Test the emergency access (break-glass) procedure and confirm logging works
SOX audits happen every year. The controls you build today will be tested again in 12 months. Build them right once, maintain them consistently, and the annual audit becomes a routine exercise instead of a scramble.
The data supports the investment: IBM's 2024 Cost of a Data Breach Report found that organizations using AI and automation across their security and compliance workflows incurred $2.2 million less in breach costs than those without. Strong ITGCs don't just satisfy auditors - they reduce real financial exposure.
Frequently Asked Questions
Not directly - SOX binds publicly traded companies registered with the SEC. But if your software processes or reports financial data for a public company, that company's SOX audit will cover your system too. Auditors examine every system that feeds financial statements. If your product is a vendor to a public company, expect SOX audit questionnaires and may need to provide evidence of your own controls.
ITGCs are the four control categories auditors examine for every IT system involved in financial reporting. Access management covers who can view or change financial data. Change management covers how code and configurations are updated without introducing errors. Operations covers system backups, job scheduling, and availability. Backup and recovery covers how data is protected and restored after failures. All four must be documented and tested annually.
SOX requires financial records and audit-related documents to be kept for at least 7 years. That includes your IT system logs, access logs, change records, and approval workflows. Deleting or altering these records intentionally is a criminal offense under Section 802, which carries up to 20 years in prison.
SOX is a US federal law that applies to publicly traded companies and governs the accuracy of financial reporting. SOC 2 is a voluntary auditing framework for service providers that assesses data security practices. They serve different purposes but often overlap in practice. A company might need SOC 2 to sell to enterprise customers, and SOX because they're publicly traded. About 40% of the controls are complementary.
The CEO and CFO. Under Section 302, they must personally sign certifications that financial reports are accurate and that they've evaluated the effectiveness of internal controls. Under Section 906, knowingly certifying a false report carries fines up to $1 million and 10 years in prison. Willful violations carry fines up to $5 million and up to 20 years in prison. This personal liability is what makes SOX different from most compliance frameworks.
Segregation of duties (SoD) means no single person should control more than one critical step in a financial process. The person who creates a vendor payment can't be the same person who approves it. The developer who writes code can't be the person who deploys it to production. Your app's role and permission system must enforce these boundaries. Users with conflicting access rights create a SoD violation, even if they haven't done anything wrong.
For companies with over $75 million in float (accelerated filers), the IT controls are tested as part of the annual financial audit - but by a separate IT audit team. Smaller companies (non-accelerated filers) are exempt from the external auditor's Section 404(b) attestation, though management must still assess and certify controls under 404(a). Either way, IT systems that feed financial reports will be examined.
