SOX ITGCs: access, change, and IT operations that external audit will sample

SOX ITGCs are controls over technology that supports internal control over financial reporting. The usual families are logical access, change management, and IT operations, with attention to reports, interfaces, batches, backups, and other technology-dependent evidence used in financial controls.

Scope starts from financial reporting, not from the IT asset inventory. Significant accounts, relevant assertions, business processes, systems, interfaces, databases, and information produced by the entity determine which technology controls matter for SOX.

The controls are only useful when they connect to financial assertions. Access controls help prevent unauthorized changes to financial data, change controls protect the integrity of applications and reports, and operations controls support completeness and availability of processing. If that link is not clear, evidence collection becomes busywork that audit cannot rely on. A strong SOX ITGC program keeps a traceable map from significant accounts to processes, systems, reports, controls, owners, and evidence so audit requests are not rebuilt from memory.

The checklist cannot decide which systems are in scope. Finance, internal audit, process owners, and IT need to trace significant accounts and controls to applications, databases, reports, interfaces, and infrastructure. Starting from every cloud account or every laptop creates noise; starting too narrowly creates audit risk.

It also cannot decide whether a control is precise enough. Access reviews, change approvals, and IPE validation must be designed to catch the errors that could affect financial reporting. A generic screenshot may not show the reviewer had the right population or criteria.

The checklist will not decide how to rely on a vendor SOC 1. The organization must review report scope, period, subservice organizations, exceptions, and complementary user entity controls, then map CUECs to internal controls.

A common failure is ownership confusion. Finance owns the SOX opinion, but IT owns much of the evidence. If nobody bridges that gap, access exports, change tickets, job logs, and IPE support arrive late or in the wrong form.

Developers retaining production access remains a classic deficiency. Teams may have branch protection and approvals, but if developers can directly change production data or code outside the controlled path, the change-management control may not be operating as described.

IPE and vendor reliance create subtler failures. Reports used in financial controls are not tested for completeness and accuracy, or a payroll vendor's SOC 1 is filed away without mapping CUECs to the company's access reviews, reconciliations, or configuration responsibilities.

Evidence quality often breaks at population completeness. Auditors may ask for the full set of changes, users, privileged roles, jobs, or reports for a period, and the system owner can only export a partial list. If the population is unreliable, even well-designed controls become difficult to test.

Use the checklist after SOX scope is mapped from financial processes to systems. For each in-scope application or infrastructure component, identify access controls, change controls, job or interface controls, reports, key spreadsheets, and vendor dependencies.

Gather evidence in the form audit will sample. Access reviews need populations, reviewer signoff, criteria, and follow-up. Change controls need approvals, testing evidence, deployment records, and emergency-change handling. IPE needs source, logic, parameters, and completeness checks.

Use the checklist during the year, not only at audit time. Quarterly access reviews, change sampling, SOC 1 review, CUEC mapping, and IPE validation should be scheduled activities so evidence reflects operation rather than reconstruction. When evidence is generated close to the control activity, reviewers can test quality instead of debating memory months later. That discipline also reduces audit fatigue for IT teams during year-end testing. It gives finance better visibility into control issues before they become deficiencies or late remediation projects with external audit teams and management review. Keep remediation owners tied to financial process owners and reporting deadlines.