SOX compliance and IT general controls: a practical guide for mid-market finance teams

What are IT general controls - and why do they matter for SOX?

Most mid-market finance teams approach SOX compliance as a financial controls exercise. They document their close processes, map controls to financial statement assertions, and prepare for walkthroughs with their external auditors. What catches them off guard is the IT general controls component - a set of technology-layer controls that underpin the reliability of every financial application in scope.

Under SOX Section 404, management must assess the effectiveness of internal control over financial reporting (ICFR). IT general controls - or ITGCs - are not optional extras. They are the foundation on which application controls rest. If your ITGCs are deficient, your auditor will typically conclude that your application controls cannot be relied upon, regardless of how well designed the financial controls themselves are.

For mid-market companies going through their first SOX audit, or scaling up after an acquisition, ITGCs are consistently the area where deficiencies emerge - and where the gap between what management believes is in place and what auditors actually find is widest.

The four ITGC domains auditors focus on

ITGC frameworks vary by audit firm and standard, but in practice they converge on four core domains. Understanding what auditors are testing in each area is the starting point for building a defensible control environment.

Where mid-market companies most commonly fail

Access reviews are not happening - or are not evidenced

The most common ITGC deficiency across mid-market companies is user access review. SOX requires periodic review of who has access to in-scope systems. In practice, many mid-market businesses rely on informal processes - a manager reviewing a list once a year and signing off verbally, with no documented evidence that inappropriate access was identified and removed.

Auditors need to see a documented, systematic review with evidence of who approved what, when, and what action was taken on exceptions. Informal processes fail this test.

Segregation of duties is theoretical rather than enforced

SOD conflicts - where one person can initiate and approve a transaction, or access both the financial system and its underlying database - are endemic in small IT and finance teams. Mid-market businesses often have documented policies that require separation, but system-level enforcement has not kept pace with headcount changes and system upgrades.

Auditors will test SOD at the system level, not the policy level. A policy that says the DBA should not have access to the finance application is not a control - a technical configuration that prevents it is.

Change management applies to production IT, not to financial applications specifically

Many mid-market companies have an IT change management process that covers infrastructure and network changes. What they often lack is a process that specifically captures changes to in-scope financial applications and their associated configurations. Auditors will ask for a population of all changes to in-scope systems during the audit period. If that population cannot be produced accurately, the change management ITGC fails.

Evidence is retrospective rather than contemporaneous

Controls need to produce evidence as they operate - not when the auditor arrives. Mid-market teams often document controls accurately, but the evidence (screenshots, approval records, review sign-offs) is assembled after the fact rather than captured at the time the control executed. Auditors distinguish between the two.

ERP systems and SOX: what your finance system needs to support

The ERP or finance system in scope for SOX needs to support three things from an ITGC perspective: role-based access controls that enforce segregation of duties, a complete and auditable change log, and a reliable audit trail for financial transactions.

Role-based access and segregation

Most enterprise ERP systems (NetSuite, SAP, Oracle, Sage Intacct) have SOD conflict matrices available. The challenge in mid-market environments is that these are often not configured at deployment, and role creep - where users accumulate access over time as their responsibilities change - is not managed systematically. Remediation typically requires a project to review and rebuild roles, which is disruptive and time-consuming to do under audit pressure.

Audit trails

SOX auditors will request transaction-level audit trails to test the completeness and accuracy of financial data. Many mid-market ERP implementations have audit trail functionality available but not enabled, or enabled but with a retention period that does not cover the full audit window. This is usually a configuration issue that is straightforward to fix - but only if identified before the audit period opens.

Change logging

Changes to financial application configurations - chart of accounts changes, user provisioning, workflow modifications - need to be logged and tied back to an approved change request. In smaller environments, these changes are often made directly by the finance team without going through IT change management. Auditors will test this.

Remediating ITGC deficiencies before your audit

If an ITGC assessment identifies deficiencies, the window for remediation matters. Auditors typically require evidence that a remediated control has been operating effectively for a minimum period before they will place reliance on it. A control remediated two weeks before year-end will not generally pass. Deficiencies identified in Q3 can often be remediated in time for year-end if action is immediate.

Remediation priority should be set by the financial reporting risk the deficiency creates:

• Material weaknesses — deficiencies where there is a reasonable possibility of material misstatement. These require immediate management attention and, once identified, must be disclosed in public filings for SEC registrants.
• Significant deficiencies — less severe than a material weakness, but still require reporting to the audit committee.
• Control deficiencies — identified gaps that do not rise to the above thresholds but still need a remediation plan.

The distinction matters because remediation timelines and management's response obligations differ at each level. Engaging technology advisory support to assess and prioritise ITGC gaps is typically more cost-effective than discovering the severity classification through the external audit.

Making ITGCs a year-round discipline

Mid-market companies that manage ITGCs effectively treat them as an ongoing discipline rather than a pre-audit activity. In practice this means:

• Quarterly access reviews with documented output - not an annual exercise
• A change management log covering financial applications, updated in real time
• Periodic SOD conflict analysis run against current system configurations, not just at implementation
• Evidence retention discipline - approvals, reviews, and exception handling captured at the time of the control execution
• ITGC scope awareness when new systems are implemented or cloud applications are added to the financial reporting stack

The business case for this investment is straightforward. The cost of ITGC remediation under audit pressure - including external advisory, audit time overruns, and potential re-testing requirements - consistently exceeds the cost of maintaining a year-round control environment by a factor of three to five.