SOX Compliance Checklist: How identity automation helps pass audits

A practical SOX compliance checklist covering access certification, segregation of duties, audit trail requirements, and how IGA automation replaces manual processes at audit time.

by
 
Oleria
April 14, 2026
 
 
 

Featured event: A CISO’s take

Join Jim Alkove and Ramy Houssaini to learn how forward-thinking security teams are addressing Enterprise AI Copilot risks.

Many SOX audit failures come down to access control failures, not accounting problems: The wrong person had access to a financial system, that access was never reviewed, and no one can prove otherwise. That's a material weakness. That's a finding.

The Sarbanes-Oxley Act gives auditors a clear mandate: show us your internal controls work. For IT and security teams, that question lives and dies on identity. Who has access to financial systems? How was that access granted? How do you know it's still appropriate? Can you prove it?

For organizations still running access reviews on spreadsheets and assembling audit evidence by hand, those questions are harder to answer than they should be. This post breaks down what SOX actually requires on the identity and access side and what it takes to stop treating audit season as a fire drill.

What is SOX compliance?

The Sarbanes-Oxley Act of 2002 was passed in the wake of the Enron scandal, in order to better hold public companies accountable for the accuracy of their financial reporting. It applies to all U.S. publicly traded companies and foreign private issuers listed on U.S. exchanges, as well as their subsidiaries.

SOX compliance means maintaining and demonstrating effective internal controls over financial reporting (ICFR). But the law doesn't prescribe specific technology — it prescribes outcomes. It’s up to management to assess whether controls work. External auditors must attest to that assessment. Material weaknesses must be disclosed.

The sections that matter most to IT and security teams are:

  • Section 302 — Senior executives must personally certify the accuracy of financial statements and disclosure controls. That certification has teeth: intentional misrepresentation carries criminal penalties.
  • Section 404 — Companies must document and test internal controls over financial reporting annually. This is where access controls, segregation of duties, and audit trails live.
  • Section 409 — Requires timely disclosure of material changes that could affect financial condition — now reinforced by the SEC's 4-business-day Form 8-K cyber incident reporting rule.

The compliance burden is significant. According to Protiviti's 2024 SOX compliance report, 24% of respondents report a significant expansion in SOX scope over the past year, 39% report moderate increases, and more than half note rising internal costs over the last two years. Additionally, 44% identify IT access controls as the area with the most audit challenges and deficiencies, particularly under Section 404.

SOX 404 and internal controls for access

Section 404 is where most of the IT and security work takes place. Section 404(a) requires management to assess the effectiveness of internal controls over financial reporting at fiscal year-end. Section 404(b) requires external auditors to independently attest to that assessment.

In practice, SOX 404 compliance means you need to:

  1. Document your controls. Not just that they exist, but how they work, who owns them, and how you test them.
  2. Test controls regularly using walk-throughs, substantive tests, and evidence of control effectiveness. Auditors require documented proof, not assumptions about control performance.
  3. Remediate gaps as significant deficiencies must be addressed. Material weaknesses must be disclosed to the audit committee, external auditors, and in public filings.

For identity and access, SOX 404 requires organizations to determine who can access financial data and to justify that access. The most common IT general controls cited in SOX 404 audits are logical access controls, change management controls, and computer operations controls. Logical access remains the highest-risk area. If a user retains access to a financial system after a role change or departure, this is a control failure with potential audit implications.

Access certification requirements for SOX

Access certification, also known as access reviews, involves periodically verifying that user access to financial systems remains appropriate. While SOX does not mandate a specific frequency, auditors expect regular reviews, and annual certification is often inadequate for high-risk systems.

What SOX auditors look for in access certifications:

  • Coverage: Were all users with access to in-scope financial systems reviewed, including service accounts and privileged users?
  • Evidence: Can you produce timestamped records showing who reviewed each access decision, what they approved or revoked, and when?
  • Context: Were reviewers working from actual access data, or from static reports that may have been weeks old?
  • Follow-through: Were revocations executed promptly? Can you tie the certification outcome to the actual change in the system?

Here’s the most familiar failure mode: a quarterly spreadsheet is circulated to managers who rubber-stamp it because they lack sufficient context to evaluate it confidently. Access doesn't get revoked. No one follows up. The certification is technically complete, but it doesn't reflect reality — and auditors can tell.

Segregation of duties (SoD) for SOX compliance

Segregation of duties is the principle that no single person should control an entire financial process from start to finish. The person who approves a payment shouldn't be the same person who records it. The person who creates a vendor shouldn't be the same person who authorizes payments to that vendor.

SOX did not introduce SoD, but it does enforce it — imposing penalties on executives who certify ineffective controls.

In modern enterprises, SoD violations are primarily identity-related. Access can accumulate across ERP systems, financial applications, and cloud platforms, often going unnoticed without appropriate tools. As users change roles or inherit access, a single identity may gain the ability to both initiate and approve transactions.

The core requirements for SOX SoD compliance:

  • Define SoD rules for financial systems: Document which combinations of access rights create conflicts, and which conflicts are material to financial reporting.
  • Detect violations: Identify users whose current access creates SoD conflicts, including access accumulated across multiple systems.
  • Remediate or compensate: Either revoke conflicting access or implement compensating controls where business requirements prevent immediate revocation.
  • Document everything: Auditors will ask for your SoD ruleset, your violation list, your remediation decisions, and the rationale for any compensating controls.

A frequent mistake is treating SoD as a one-time task. Because access changes frequently, continuous SoD monitoring is necessary to maintain reliable controls for certification.

Audit trail and evidence collection

SOX requires a clear, verifiable record of every access decision, transaction, and system change involving financial data. Auditors require evidence and will independently verify controls.

The evidence they'll ask for: access logs, provisioning records, change logs, certification records, and SoD conflict documentation — each with timestamps, approver identity, and outcome.

A key challenge is aggregating data from various sources. Financial data spans ERP platforms, databases, cloud applications, and third-party systems, each with unique logging formats and retention policies. Manual evidence collection requires reconciling these differences and increases the risk of missing information.

For SOX, audit trail requirements extend beyond maintaining logs. Organizations must be able to answer specific access questions about individual users at particular times, supported by documentation, upon request.

Organizations that integrate evidence collection into routine operations perform better than those that assemble evidence only during audits. Centralized and queryable identity and access data is more effective than data scattered across multiple systems.

Automating SOX compliance with IGA

Identity Governance and Administration (IGA) is the category of tooling built to manage exactly the controls SOX 404 requires: access certification, SoD enforcement, lifecycle management, and audit evidence collection. The case for IGA in a SOX context maps directly to the audit requirements:

SOX Requirement Manual Approach IGA-Automated Approach
Access certification Spreadsheet circulated quarterly Continuous workflows with live access data
SoD enforcement Pre-audit manual review Real-time conflict detection and alerting
Provisioning controls Ticket-based, inconsistently documented Automated provisioning with policy enforcement and audit trail
Audit evidence Manual log collection across systems Centralized, queryable, exportable on request
Joiner-mover-leaver Manual HR-to-IT handoffs, delays common Automated triggers from HR system, same-day execution

Manual processes introduce not only inefficiency but also audit risk. Delayed deprovisioning, missed certifications, or undocumented SoD exceptions each represent potential control failures. Accumulating these issues can result in significant deficiencies, and if they affect financially material systems, they may lead to material weaknesses reported in the 10-K.

What modern IGA looks like in a SOX-ready program

Automated access reviews with decision context

Instead of relying on spreadsheets, the system presents each access decision with relevant context such as last login, entitlement risk level, and consistency with peer roles and actual usage stats. This enables reviewers to make faster, more informed decisions and reduces superficial approvals.

Continuous SoD monitoring

Instead of conducting SoD analysis only before audits, the system continuously detects conflicts as they arise during provisioning, role changes, or access requests. Exceptions are documented with business justification and compensating controls in advance of auditor review.

Lifecycle automation tied to HR

New employees receive access according to policy, role changes trigger access adjustments, and departing employees have access revoked immediately upon termination. Each step is logged, timestamped, and auditable.

Centralized audit evidence

A single platform stores access certification records, provisioning history, SoD conflict logs, and remediation decisions, all searchable by user, application, date, or control. Evidence that previously required weeks to assemble can now be gathered in hours.

The most effective starting point is access certification for Tier 1 financial systems such as ERP, financial consolidation platforms, and data warehouses or lakes containing financial data. These areas typically generate the most audit findings, present the greatest manual challenges, and benefit most from automation.

SOX compliance checklist: identity and access controls

SOX compliance checklist

Identity and access controls

Use this checklist to validate your controls before audit season — and identify where automation can close gaps.

Access controls
Access certification
Segregation of duties
Audit trail
See how Oleria automates access certification, SoD enforcement, and audit evidence — so you're always ready when auditors ask.
See how Oleria helps

Passing a SOX audit isn’t about having perfect controls — it’s about proving your controls work. That means knowing who has access, catching risks early, and documenting every decision. Oleria gives you the visibility to see access clearly, the intelligence to flag issues as they emerge, and the workflows to remediate and document — so you’re always ready when auditors ask.

Media contact
For media inquiries, contact pr@oleria.com

See adaptive, automated
identity security in action