The Sarbanes-Oxley Act was enacted by Congress in 2002 following major corporate scandals to improve the accuracy and reliability of corporate financial reporting. Section 404 is the most complex and expensive section to implement, requiring publicly traded companies to establish, document, test, and maintain internal controls over financial reporting (ICFR).

For 2026, treating SOX Section 404 as an annual checkbox exercise is no longer viable. With SEC’s intensified focus on digital governance and AI operationalization in finance, the definition of internal control has expanded beyond accuracy to encompass velocity and governance.

Section 404 Requirements

404(a) vs 404(b)

Section 404(a) requires management assessment of ICFR effectiveness and applies to all public companies. Section 404(b) requires external auditor attestation of management’s assessment and applies only to accelerated and large accelerated filers.

Filer categories determine requirements. Large accelerated filers with public float of $700M or more must comply with both 404(a) and 404(b). Accelerated filers with public float between $75M and $700M must comply with both unless annual revenues are under $100M. Non-accelerated filers and emerging growth companies only require 404(a) management assessment.

Material Weakness vs Significant Deficiency

A material weakness is a deficiency or combination where there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis. Public SEC filings disclosure is required.

A significant deficiency is less severe than a material weakness but important enough to merit attention by those charged with governance. It must be communicated to the audit committee.

A control deficiency is a design or operating deficiency that could affect the ability to record, process, summarize, or report financial data. Internal documentation is required.

Evaluation factors include presence of compensating controls, potential magnitude of resulting misstatement, risk factors including nature of account and susceptibility to fraud, and whether deficiency warrants attention of governance bodies.

COSO Framework

The COSO Internal Control-Integrated Framework is the gold standard used by regulators and external auditors. The 2013 update includes five components with 17 principles and 87 points of focus.

The five components are Control Environment setting the tone of the organization, Risk Assessment identifying and analyzing risks to achieving objectives, Control Activities as policies and procedures ensuring directives are carried out, Information and Communication ensuring relevant information is identified, captured, and communicated, and Monitoring through ongoing evaluations and separate evaluations.

IT General Controls

IT General Controls are foundational controls that support the integrity, security, and accuracy of financial systems. They ensure financial reporting is reliable and tamper-proof.

Access to Programs and Data

Purpose is to ensure only authorized users can access sensitive systems and data.

Key controls include user authentication with strong password policies and MFA enforcement, user authorization with role-based access aligned with job functions, access reviews with periodic validation of user access appropriateness, and privileged access with special controls for admin and elevated accounts.

Best practices include quarterly access reviews as the gold standard for SOX compliance with semi-annual reviews as the minimum, integration with HR systems for automated provisioning and deprovisioning, and least privilege principle enforcement.

Program Change Management

Purpose is to ensure changes to IT systems are properly authorized, tested, and documented.

The change management lifecycle flows from request through approval, development, testing, approval, deployment, and review.

Key controls include change request documentation with all changes formally requested and justified, impact assessment evaluating effect on financial systems, authorization through appropriate management approval before implementation, testing in non-production environment, segregation of duties where developer cannot migrate to production, and post-implementation review verifying successful deployment.

Documentation requirements include change tickets with business justification, test plans and results, approval evidence with electronic signatures and dates, deployment logs, and rollback procedures.

Computer Operations

Purpose is to ensure systems operate reliably and consistently.

Key control areas include job scheduling with automated scheduling tools, monitoring for failures, and exception handling. Batch processing includes processing verification and reconciliation of input and output. System monitoring covers performance monitoring and capacity planning. Incident management covers problem tracking, root cause analysis, and resolution documentation.

Program Development

Purpose is to ensure new systems and applications are developed with appropriate controls.

Key controls include System Development Life Cycle methodology, requirements documentation and approval, design reviews and approvals, code reviews, security testing before production, user acceptance testing, and migration controls.

Backup and Recovery

Purpose is to ensure data availability and business continuity.

Requirements include backup procedures with regular documented schedules, off-site storage with secure storage away from primary location, encryption with backups protected from unauthorized access, testing with periodic restoration testing to verify recoverability, disaster recovery plan with documented and tested DR procedures, and retention aligned with regulatory requirements.

End-User Computing Controls

Purpose is to control risks from spreadsheets and other user-developed applications.

Key controls include identification and inventory of financially significant EUC applications, input validation controls, access restrictions to formulas and macros, version control, review and approval of changes, and reconciliation of EUC outputs to source systems.

IT Application Controls

Application controls operate at the transactional level within specific software systems, ensuring inputs, processing, and outputs are accurate and authorized.

Input Controls

Purpose is to ensure data entering the system is complete, accurate, and authorized.

Control types include data validation verifying data meets defined criteria through format and range checks, authorization checks ensuring transactions are properly approved through approval workflows, completeness verification ensuring all required data is captured through mandatory field validation, duplicate detection preventing duplicate entries through invoice number uniqueness, and edit checks validating data relationships through cross-field validation.

Processing Controls

Purpose is to ensure data is processed correctly and completely.

Control types include calculation accuracy with automated calculations verified for correctness, data matching ensuring related records are properly linked, exception handling identifying and routing anomalies for review, sequence checking verifying transactions processed in correct order, and batch totals with control totals to verify complete processing.

Output Controls

Purpose is to ensure output is complete, accurate, and distributed appropriately.

Controls include report accuracy verification through reconciliation of report totals to source, distribution controls ensuring appropriate recipients and secure delivery, output reconciliation matching outputs to inputs, and retention controls for proper archiving of outputs.

Interface Controls

Purpose is to ensure data transferred between systems maintains integrity.

Controls include transmission controls verifying complete transmission of data, reconciliation matching records sent with records received, error handling for identifying and resolving interface failures, and timing controls ensuring interfaces run in correct sequence.

Key Control Procedures

User Access Management

Provisioning procedures include formal access request submitted by manager, business justification documented, role and access level determined based on job function, segregation of duties conflict check, appropriate approval obtained, access granted per approved request, and confirmation sent to requester and user.

Access review procedures include quarterly review by system owner or manager with signed certification, review upon role change by HR and manager with transfer form and access modification, and continuous review through automated tools with exception reports.

Termination procedures include HR notification triggering access revocation workflow, immediate disable of all system access, review of privileged access and shared accounts, recovery of physical access devices, documentation of termination completion, and post-termination verification.

Privileged Access Management

Core requirements include least privilege granting minimum necessary access, just-in-time access providing temporary time-bound elevated access, multi-factor authentication required for all privileged accounts, session recording of all privileged sessions, password vaulting with centralized secured credential storage, and break-glass procedures for emergency access with full audit trail.

Monitoring and auditing includes continuous logging of all privileged account activity, regular audit of privilege usage logs, alerts for anomalous privileged activity, and periodic certification of privileged access rights.

Segregation of Duties

The four-function model includes authorization for approval of transactions, custody for physical access to assets, recordkeeping for recording transactions, and reconciliation for verifying records match reality.

IT-specific SoD requirements include developers cannot migrate code to production, DBAs cannot access business applications, security administrators cannot perform business transactions, and access administrators cannot approve their own access requests.

Audit Preparation

Evidence Collection

Documentation requirements include audit workpapers retained 5 years minimum, control documentation retained for life of control plus 5 years, transaction evidence retained 7 years, access records retained 7 years, and change records retained 7 years.

Evidence types ranked by strength from weakest to strongest include inquiry through discussions with personnel, observation through witnessing control performance, inspection through examining documents and records, and re-performance through independently executing control.

Control Testing

Test of Design evaluates whether control is suitably designed to address identified risk, reviews control documentation, and includes interviews with control owners.

Test of Operating Effectiveness includes inquiry used for all controls combined with other methods, observation for manual controls with point-in-time observation, inspection of documentary evidence with sample size based on frequency and risk, and re-performance for automated controls with system-generated evidence.

Sample size guidance for annual controls is 1, quarterly controls is 2, monthly controls is 2-5, weekly controls is 5-15, daily controls is 20-40, and multiple times daily is 25-60.

Common Audit Findings

Access management findings include improper provisioning, SoD violations, untimely terminations, and inadequate access reviews.

Change management findings include missing approvals, inadequate testing evidence, and SoD violations in migration.

System configuration findings include lack of understanding around key configurations and undocumented changes.

Audit log findings include logs not reviewed, review not documented, and incomplete logging.

Management review control findings include insufficient evidence of review and lack of investigation of anomalies.

Cloud and Modern Systems

SOC Reports

SOC 1 Type 1 covers ICFR controls design at point in time with limited SOX relevance due to no operating effectiveness testing. SOC 1 Type 2 covers ICFR controls design and operating effectiveness over period and is the primary report for SOX reliance. SOC 2 Type 2 covers security, availability, processing integrity, confidentiality, and privacy and supports ITGC assessment.

Using SOC reports requires obtaining current SOC 1 Type 2 report, reviewing auditor’s opinion, evaluating exceptions and management responses, reviewing Complementary User Entity Controls, implementing required CUECs within your organization, and documenting reliance and bridge procedures.

Cloud Shared Responsibility

For IaaS, provider handles physical security while network security, operating system, application, data, access management, and configuration are customer responsibilities with network security being shared.

For PaaS, provider handles physical security, network security, and operating system while application is customer responsibility and data, access management, and configuration are customer responsibilities.

For SaaS, provider handles physical security, network security, operating system, and application while data, access management, and configuration are shared between provider and customer.

Customer responsibilities always include data classification and protection, user access management within applications, compliance monitoring, incident response planning, and vendor management and oversight.

DevOps Considerations

One of the main tenets of SOX compliance is ensuring no single employee can unilaterally deploy a code change into production.

Implementing compliant CI/CD requires code commit with developer identity verification and code review requirements, build with automated build from approved source, test with automated testing gates and security scans, approval with integrated change management approval check, deploy with separation between developer and deployer roles, and audit trail with complete traceability from commit to production.

An auditor should be able to pick any change in production and easily trace it back to the original code commit, the approval ticket, and the specific pipeline execution that deployed it.

Penalties and Consequences

Personal Liability

Section 302 civil provisions require CEO and CFO to certify they have reviewed periodic reports, certify reports contain no material misstatements or omissions, certify financial statements fairly present the company’s condition, and certify they have established and maintained internal controls.

Section 906 criminal provisions impose knowing certification of false report penalties up to $1,000,000 fine and up to 10 years imprisonment. Willful certification knowing report does not comply penalties are up to $5,000,000 fine and up to 20 years imprisonment.

Clawback provisions require that if the company restates financials due to misconduct, the CEO and CFO must forfeit bonus compensation received during the 12 months following the filing, incentive-based compensation received during that period, and profits realized from stock sales during that period.

Audit Opinion Impacts

Opinion types include unqualified meaning no material weaknesses identified with clean report, and adverse meaning material weaknesses exist and not remediated with negative market impact. An auditor cannot issue a qualified opinion with exceptions; if a material weakness exists, the opinion must be adverse.

Effects of adverse opinion include higher perceived risk of financial statement misstatement, higher risk of future restatements, higher information asymmetry, lower financial statement transparency, higher risk premium and cost of capital, lower earnings predictability, poorer analyst forecast accuracy, and greater analyst forecast dispersion.

SOX IT controls require ongoing attention as technology and regulatory expectations evolve. Organizations that invest in comprehensive ITGC and application control frameworks, supported by effective audit preparation and cloud governance, maintain the control environment necessary for accurate financial reporting.