SOX compliance for software: What financial apps must follow

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.

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:

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 1Raft

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.

"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."

• 1Raft 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:

1. Change request - what's changing and why
2. Impact assessment - which financial processes or reports could be affected
3. Testing - evidence that the change was tested in a non-production environment
4. Approval - sign-off from someone other than the person making the change
5. 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.

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:

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

1. "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.

2. "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.

3. "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.

4. "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.

5. "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.

6. "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.

7. "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.