SOX IT controls: what Section 404 auditors find that internal teams miss
Sienna VanceApril 29, 2026
Key takeaways
SOX IT control failures most commonly involve access control drift and stale privileged accounts, not missing encryption — findings that standard compliance documentation does not surface.
Section 404 auditors request evidence of controls operating effectively, not just policy documents describing them. The gap between the two is where most ITGC deficiencies originate.
Change management controls are the most frequently cited ITGC weakness in material weakness disclosures: unauthorized or undocumented changes to financial reporting systems account for a disproportionate share of restatements.
Cloud environments create a specific ITGC evidence problem: agencies and auditors accept SOC 1 reports from cloud providers as coverage, but SOC 1 reports do not document IAM configurations, security group rules, or key management settings at the level SOX auditors are increasingly requesting.
Organizations that scope SOX IT controls based on last year''s system inventory rather than current production state routinely miss systems added during the year that process or store financial data.
TL;DR
SOX IT controls exist to ensure financial data cannot be altered, accessed, or disrupted without detection. Section 404 auditors are not primarily interested in your security posture — they are interested in whether your controls operated effectively during the period under review and whether you have evidence to prove it. Most ITGC findings come down to three things: access that was not reviewed, changes that were not documented, and systems that were not in scope. The regulatory exposure when those findings become material weaknesses is significant, and the remediation cycle is long.
What triggered the material weakness nobody expected
A publicly traded fintech came to us eight weeks before their fiscal year-end SOX audit. Their IT compliance lead had been managing the program for three years and described it as stable. The controls were documented. The evidence packages from the prior year were organized. The external auditor had issued a clean opinion.
We pulled their privileged access inventory for the financial reporting systems — the ERP, the revenue recognition module, the database layer underneath both. The inventory listed 14 accounts with administrative access. When we enumerated what was actually running in production, we found 23. Nine accounts not in scope of any quarterly access review. Three of them belonged to former employees. One had not been touched in fourteen months but was still active with full database rights to the general ledger schema.
The IT compliance lead''s response was one I have heard in different forms across many assessments: ''Those are service accounts, they don''t count as privileged access under our policy.'' The auditor''s view was different. The policy''s definition of privileged access and the actual risk profile of those accounts were not the same thing. The material weakness that resulted from this finding was not about the accounts themselves — it was about the access review process that had been documented as operating quarterly but had not actually covered the full population of accounts it was supposed to cover.
What Section 404 actually requires from IT controls
Section 404 of the Sarbanes-Oxley Act requires management to assess the effectiveness of internal controls over financial reporting and requires the external auditor to attest to that assessment. The IT controls that fall under this obligation are the ones that could, if they failed, allow a material misstatement to occur and go undetected.
The PCAOB''s AS 2201 provides the auditing standard for this attestation. It does not specify which IT controls to implement. What it does specify is that auditors must understand the flow of transactions through IT systems, identify controls that are relevant to the financial reporting risk, and test whether those controls operated effectively during the period — not just whether they were documented.
That last phrase is where most ITGC programs run into trouble. Operating effectively means the control actually did what it was supposed to do, for every transaction, throughout the full audit period. A quarterly access review that was completed twice instead of four times did not operate effectively. A change management process that was followed for planned releases but bypassed for emergency patches did not operate effectively for 100% of changes. A logging system that was configured correctly but had a 23-day outage in Q2 did not produce a complete audit trail.
The regulatory framework is less interested in your security posture than in your ability to demonstrate continuous, documented operation of specific controls. Those are related but not identical objectives.
Example
One client had a change management policy requiring dual approval for all changes to financial reporting systems. The policy was well-written. The ticketing system showed consistent compliance. The SOX auditor sampled 30 change tickets and found that 4 involved emergency changes that had been approved by a single individual under an emergency exception clause — a clause that existed in the policy but had not been flagged as an exception requiring separate documentation and retrospective review. The emergency exception process had been invoked 11 times during the audit period. None of the 11 were documented as exceptions. The control was rated as having a significant deficiency.
For cloud environments, the ITGC evidence problem is structural. Cloud providers produce SOC 1 Type II reports that cover the provider''s own controls. They do not cover the customer''s configuration of services within the provider''s environment. IAM role assignments, security group rules, CloudTrail log retention settings, KMS key policies — these are customer configurations and are not attested in the provider''s SOC 1 report. SOX auditors are increasingly requesting direct evidence of these configurations rather than accepting the provider report as coverage. Organizations that have been treating the SOC 1 report as a complete answer to cloud ITGC evidence are accumulating a gap that will eventually surface in an audit.
What we find in SOX IT control assessments
Assessment base: Vulnox assessment data, 2024-2025, public company and SOX-adjacent environments
Privileged access populations that exceed the documented inventory
In assessments of SOX-scoped environments, the actual count of accounts with privileged access to financial reporting systems consistently exceeds the count reflected in the most recent access review. The delta is typically driven by service accounts created for integrations or automation that were not registered in the access governance process, and by accounts that were not deprovisioned following role changes or departures. The access review process covers the accounts it knows about. It does not cover the ones it does not.
An access review that does not cover the full population of privileged accounts is not an operating control for SOX purposes — it is a partial review that creates a documented false assurance. When auditors enumerate the actual account population and compare it to the access review scope, the discrepancy is straightforward to identify and difficult to explain as anything other than a control failure.
Change management exceptions that were not treated as exceptions
Most change management policies include an emergency change or expedited change process. In practice, this process is used more frequently than the policy intends and is often not accompanied by the retrospective documentation the policy requires. The result is a population of changes that were made under an exception clause but not recorded as exceptions, not reviewed retrospectively, and not visible to the access and change management oversight function.
From a SOX perspective, an undocumented exception to a key control is indistinguishable from a control bypass. The auditor''s sample will include some of these changes. When the documentation is absent and the retrospective approval cannot be reconstructed, the finding is a gap in change management operating effectiveness — the most frequently cited category of ITGC material weakness in public company disclosures.
Financial reporting systems added during the year that were not brought into SOX scope
SOX IT control scope is determined at the beginning of the audit period based on the systems that process or store data relevant to financial reporting. During the year, new systems get added — a new revenue platform, a billing automation tool, a data warehouse that aggregates GL data for reporting. These additions are frequently not accompanied by a formal in-scope determination or an ITGC control implementation before they go live. The system is running in production, processing financial data, and outside the control framework.
When the auditor asks for evidence of IT controls over a system that was not in scope, the organization has a choice between explaining that the system was excluded intentionally — which requires a risk-based justification that will be scrutinized — or acknowledging that the scoping process did not keep pace with the environment. Neither answer is comfortable when the system processes material financial transactions.
The compliance teams that document the most tend to test the least
Common belief
A mature SOX IT control program is one with thorough documentation: detailed narratives, complete risk-control matrices, organized evidence packages. Organizations with extensive documentation are well-prepared for audit.
What we found
In several assessments, the organizations with the most organized compliance documentation had access review processes that had not run on schedule and change management logs with gaps that the documentation narrative did not reflect. The narratives described a well-functioning program. The logs told a different story. The gap between the two was the finding.
Documentation volume and control effectiveness are not correlated. In practice, organizations that invest heavily in compliance documentation often do so because documentation is what their auditors have historically reviewed — not because documentation reflects whether controls are actually operating. The documentation describes the control as designed. What auditors test, and what matters for Section 404, is whether the control operated as designed during the period.
Organizations that maintain clean, voluminous documentation packages sometimes have the weakest actual control operation because the documentation effort consumes the time and attention that would otherwise go into running the controls, monitoring for exceptions, and testing operating effectiveness independently of the audit cycle. The documentation says the control operates. Nobody checked whether it did.
What standard ITGC testing misses
Application-layer access controls below the ITGC scope boundary
SOX ITGC testing typically covers access to operating systems, databases, and network infrastructure. It frequently does not cover application-layer role assignments within the financial reporting application itself. In ERP environments, the segregation of duties analysis at the application layer — who can create a vendor and who can approve a payment, for example — is often treated as a separate application control review conducted by a different team. The boundary between ITGC and application controls can create gaps where neither review owns a specific access risk.
Logging gaps that occur within the audit period
SOX evidence packages include log data demonstrating that monitoring controls operated during the period. What they rarely include is evidence that logging was continuous and complete. A logging system that had a configuration error for three weeks, or a SIEM that stopped ingesting a particular source, produces an evidence gap that looks like compliance unless someone specifically tests whether the log coverage was uninterrupted. Auditors who accept a log extract without validating completeness are accepting evidence that may not represent the full period.
Third-party and service provider access to in-scope systems
Managed service providers, software vendors with remote support access, and implementation partners frequently have access to systems in SOX scope. This access is often governed by vendor agreements rather than the organization''s internal access management process. The vendor''s access is not reviewed in the quarterly privileged access review. It is not always logged in the same system as internal account activity. And it is not always deprovisioned when the engagement ends. SOX auditors are increasingly asking about vendor access specifically because it falls outside the standard ITGC control framework.
Where SOX IT control enforcement is heading
Within three years, the PCAOB will issue interpretive guidance or inspection findings specifically addressing cloud ITGC evidence, requiring auditors to obtain direct configuration evidence rather than accepting SOC 1 reports as complete coverage for customer-controlled settings.
Cloud adoption among public companies has outpaced the audit methodology. The current practice of accepting provider SOC 1 reports as ITGC evidence for customer-side configurations is inconsistent with how the same controls would be tested in an on-premise environment. PCAOB inspection reports have already flagged ITGC evidence quality as an area of concern. As cloud environments become the default infrastructure for financial reporting systems, the gap between current audit practice and adequate evidence standards will become impossible to ignore.
Confidence: highNo PCAOB guidance or inspection finding specifically addressing cloud ITGC evidence standards by end of 2027.RPA and workflow automation tools will become the most common source of new SOX ITGC material weaknesses within five years, displacing access control issues as the leading finding category.
RPA bots and automation platforms are being deployed rapidly within finance functions to handle transaction processing, reconciliation, and reporting tasks. These tools frequently operate with service accounts that have elevated access and are not subject to the same access review, change management, and segregation of duties controls applied to human users. The compliance function has not caught up with the deployment pace. As these tools mature and the financial statement impact of automated processes grows, auditors will focus on them specifically — and find that the control framework has not kept pace.
Confidence: mediumPCAOB inspection data or material weakness disclosure patterns showing access control remains the leading ITGC finding category through 2029.
SOX IT compliance and security are not the same objective
There is a persistent assumption in how compliance programs are run that a strong SOX IT control environment and a secure IT environment are the same thing. They overlap significantly but they are not identical, and the difference matters for how organizations allocate compliance effort.
SOX IT controls are designed to prevent material misstatement in financial reporting. A control that detects unauthorized access to the general ledger is a SOX control. A control that prevents lateral movement through the corporate network toward a non-financial system is a security control. Both matter. But the evidence standards, testing cadences, and documentation requirements are different, and organizations that conflate the two often do neither well.
The compliance function optimizes for what auditors will test. The security function optimizes for what attackers will exploit. These are not the same optimization target. An organization can have immaculate ITGC documentation and a compromised financial reporting system simultaneously — if the attacker''s path went through infrastructure that was outside the ITGC scope boundary.
The implication is not that SOX compliance is insufficient — it is that treating SOX compliance as a proxy for financial system security is a category error. The two programs need to be coordinated, not conflated.
Counterargument
The counterargument is that maintaining two separate frameworks for the same systems creates overhead and inconsistency, and that a well-designed SOX IT control program should encompass the security controls that protect financial reporting systems anyway. That argument is structurally sound. In practice, the scope boundaries, evidence standards, and testing cadences of the two programs diverge enough that ''well-designed coordination'' rarely describes what organizations actually implement.
One action before the next audit cycle
Pull your current SOX IT control scope and compare it against what is actually running in production today — not what was in scope when the program was last updated. Map every system that touches financial data: the ERP, the revenue platform, the data warehouse, the integration middleware, the automation tools. Any system added in the past twelve months that is not in the ITGC scope document is a finding waiting to be discovered. Identifying it now takes a day. Explaining it to an auditor after the fact takes considerably longer.
Further Reading
Digital Footprint
digital footprint analysisGap Analysis
gap analysis frameworkNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionThe 18 CIS Critical Security Controls
CIS critical security controls
Frequently Asked Questions
What are IT general controls under SOX and why do they matter for Section 404?
IT general controls under SOX are the controls over the IT environment that support the reliable operation of application controls over financial reporting. They cover access management, change management, IT operations, and program development. Section 404 requires management to assess these controls and auditors to test whether they operated effectively during the period — not just whether they were documented.
What is the most common SOX ITGC finding during external audits?
Change management is the most frequently cited ITGC weakness in material weakness disclosures. Specifically, emergency and expedited change processes that were invoked without required documentation or retrospective approval, and changes made to financial reporting systems that bypassed the standard approval workflow. The second most common finding is access control drift — privileged account populations that exceed the inventory covered by quarterly access reviews.
How do cloud environments create SOX IT control evidence gaps?
Cloud providers issue SOC 1 reports covering their own infrastructure controls. These reports do not cover customer-side configurations — IAM role assignments, security group rules, key management settings, log retention configurations. SOX auditors are increasingly requesting direct evidence of these configurations rather than accepting the provider SOC 1 report as sufficient coverage. Organizations that have relied on provider reports to satisfy cloud ITGC evidence are accumulating a gap that auditors will eventually test directly.
How should SOX IT control scope be maintained when new systems are added during the year?
Any system added during the fiscal year that processes or stores data material to financial reporting should trigger a formal in-scope determination before it goes live, or as soon as possible after. The determination should be documented, signed off by the compliance function, and followed by implementation of the applicable ITGCs before the system is used for financial transactions. Systems that enter production without this process are outside the control framework for the period they operated without it.
What is the difference between SOX IT controls and general cybersecurity controls?
SOX IT controls are scoped specifically to the systems and processes that could allow a material misstatement in financial reporting if they failed. They carry specific evidence standards, testing cadences, and documentation requirements tied to the audit attestation process. General cybersecurity controls cover a broader scope including systems with no financial reporting relevance. The two overlap significantly but are not identical — treating SOX compliance as a proxy for overall security is a scoping error that leaves gaps in both directions.
How do you identify SOX IT control gaps before the external audit?
Compare your current in-scope system inventory against what is actually running in production. Enumerate all privileged accounts on in-scope systems and compare that list to the population covered by your most recent access review. Pull your change management log and identify any changes made under emergency or exception processes that lack retrospective documentation. These three steps surface the majority of findings that external auditors identify in ITGC testing.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.