SOX ITGC Guide: Access, Change and Operations Controls

Under the Sarbanes-Oxley Act, a weak IT general control can undermine every automated control and system report that a company's financial statements rely on. Auditors do not test ITGCs for their own sake: they test them because automated application controls, calculations and the reports used as audit evidence are only trustworthy if access, change and operations around those systems are controlled. This guide explains what SOX sections 302 and 404 require, how PCAOB AS 2201 shapes IT scoping and testing, how to design logical access, program change and computer operations controls that survive testing, how deficiencies are evaluated, and how to prepare evidence. It is written for IT control owners, IAM teams, internal audit and SOX programme leads at US-listed companies and their subsidiaries, and touches on the UK equivalent. For conflicting duties inside financial processes see the Segregation of Duties Guide.

Key takeaways

ITGCs matter because other controls depend on them. SEC guidance says management only needs to evaluate the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks.
Scoping is top-down. Start from significant accounts and relevant assertions, find the automated controls and key reports that support them, then scope the applications, databases and platforms underneath.
Access, change and operations are the core domains. Most ITGC deficiencies are terminated users with live access, unreviewed privileged accounts, developers who can move their own code to production, and access reviews run on incomplete lists.
Evidence must be complete and accurate. Any system report used in a control is information produced by the entity (IPE) and needs its own accuracy and completeness support; PCAOB inspectors found deficiencies here in about 17% of audits inspected in 2021 and 2022.
An ITGC deficiency is judged by what it touches. Severity depends on the dependent application controls and reports, the existence of compensating controls and whether the access or change was actually misused.

What SOX requires and who sets the rules

The Sarbanes-Oxley Act of 2002 does not mention IT controls by name. IT enters through internal control over financial reporting (ICFR), which management must assess and, for larger issuers, the auditor must attest to.

Requirement	What it says	Why IT is in scope
SOX 302 (15 U.S.C. 7241)	The principal executive and financial officers certify each annual and quarterly report, state they are responsible for internal controls, have evaluated them within 90 days, and have disclosed significant deficiencies, material weaknesses and any fraud involving management to the auditors and audit committee	Officers sign off on controls that run in systems; sub-certification by IT and process owners usually supports this
SOX 404(a) (15 U.S.C. 7262)	The annual report contains management's assessment of the effectiveness of ICFR as of the end of the fiscal year	Management's assessment covers ITGCs that support key controls
SOX 404(b)	The external auditor attests to and reports on management's assessment; emerging growth companies are excluded, and 404(c) exempts issuers that are neither large accelerated nor accelerated filers	The auditor tests ITGCs under PCAOB standards
SEC Regulation S-K Item 308	Management's report must name the framework used, and management may not conclude ICFR is effective if one or more material weaknesses exist; changes in ICFR in the last fiscal quarter must be disclosed	A system migration or major access change can be a reportable change in ICFR
PCAOB AS 2201	The auditing standard for an integrated audit of ICFR: top-down approach, walkthroughs, benchmarking of automated controls, severity definitions	Sets how auditors scope and test ITGCs
COSO Internal Control, Integrated Framework (2013)	The framework most US issuers name under Item 308; five components and 17 principles, with Principle 11 covering general control activities over technology	Gives the control objective ITGCs map to

UK SOX: the informal label for Provision 29 of the UK Corporate Governance Code 2024. The Financial Reporting Council states that Provision 29 applies to financial years beginning on or after 1 January 2026 and asks boards to declare on the effectiveness of their material internal controls, not all controls. It is a comply-or-explain code provision rather than a statutory attestation, but the same ITGC disciplines produce the evidence a board needs.

ITGC domains and IT application controls

IT application controls (ITACs) are automated controls inside a business application: three-way match tolerances, credit limit blocks, automated journal approvals, system calculations, input validation and interface completeness checks. Key reports are system outputs that a person relies on to perform a control, such as an aged receivables listing used in a reserve review. ITGCs are the controls over the environment those applications run in. PCAOB AS 2110 lists the IT risks auditors must understand, and they map directly onto the ITGC domains.

ITGC domain	AS 2110 risk it addresses	Typical key controls	Evidence auditors ask for
Logical access	Unauthorised access to data; IT personnel with access privileges beyond those necessary; unauthorised changes to master data	Approved provisioning, timely deprovisioning, privileged access restriction, periodic user access reviews, authentication settings	Tickets with approvals, HR leaver list compared to account disable dates, privileged user listings, signed-off reviews
Program change	Unauthorised changes to systems or programs; failure to make necessary changes	Changes authorised, tested, approved and migrated by someone other than the developer; emergency change process; configuration change control	Population of production changes from the system itself, change tickets, deployment logs, developer access listings
Program development and acquisition	Reliance on systems processing data inaccurately	Project governance, data migration reconciliation, user acceptance testing for new systems	Migration reconciliations, go-live approvals
Computer operations	Potential loss of data or inability to access data; inappropriate manual intervention	Batch job scheduling and failure resolution, interface monitoring, backup and restore	Job schedule change logs, failure tickets, backup reports, restore tests

The dependency is what auditors care about. AS 2201 allows benchmarking: an auditor need not re-test a fully automated application control every year if general controls over program changes, access and computer operations are effective and tested, and the control has not changed since its baseline. AS 2201 notes this works especially well for purchased software where the vendor does not allow source code modification. Weak change controls remove that option and multiply testing effort.

SOX scoping: from accounts to systems

AS 2201 requires a top-down approach starting at the financial statements and working down to significant accounts, disclosures and relevant assertions; it also states that identifying IT risks and controls is not a separate evaluation but part of that approach. The SEC's 2007 management guidance takes the same line and says it is unnecessary to evaluate ITGCs that primarily pertain to efficiency or effectiveness of operations.

Map key controls: for each significant process, list the automated controls, key reports and IT-dependent manual controls that address a relevant assertion.
Identify supporting systems: the applications that execute those controls or generate those reports, then the layers underneath where access or change could alter them, usually the database and sometimes the operating system and job scheduler.
Scope the identity layer: where an identity provider or directory controls authentication to in-scope applications, its administrative access and provisioning become ITGC relevant too.
Handle service organisations: for cloud ERP, payroll or hosting providers, obtain a SOC 1 Type 2 report. AS 2201 states that a report on controls placed in operation alone is not sufficient, that the test period must be evaluated against the assessment date, and that complementary user entity controls must be in place at the company. Fill gaps between the report period and year end with a bridge letter and inquiry.
Record rationale: document why each system is in or out of scope; auditors test the scoping logic as much as the controls.

Decision guidance: a first-year issuer, or a non-accelerated filer exempt from 404(b), can keep scope narrow and rely more on manual controls with strong review evidence; an accelerated filer with a heavily automated ERP gains more from investing in strong change controls so automated controls can be benchmarked. In decentralised groups, standardising ITGCs on a shared ERP or identity platform usually costs less than testing many local variants.

Logical access controls and SOX access governance

Logical access is where most ITGC findings land. A defensible design covers these controls, each with an owner, a frequency and defined evidence.

Provisioning: access to in-scope applications is requested, approved by an appropriate manager or role owner, and granted as approved. Birthright roles from HR feeds need their own approval of role content. See the Joiner-Mover-Leaver Guide.
Deprovisioning: leavers lose access within a defined period. Test against the HR termination list, not the ticket queue, and check that activity after the termination date did not occur.
Privileged access: application administrators, database administrators and superusers are limited to IT staff who need them, separated from business users and developers, and their activity is logged and reviewed. See the Privileged Access Management Guide.
SOX access reviews: business or system owners periodically certify user access to in-scope applications and privileged roles. Reviews fail when the population is incomplete, the reviewer cannot understand the entitlements, reviewers approve their own access, or removals are requested but never completed. See the Access Reviews Guide.
Authentication settings: password or SSO and MFA configuration for in-scope applications, including whether local accounts can bypass SSO.
Segregation of duties: conflicting roles inside financial applications are prevented or mitigated; SoD is usually tested as part of the process controls but depends on the same access data.

Where identity fits: non-human accounts

Auditors increasingly ask about service accounts, interface users, batch job owners, RPA bots and API credentials, because they often hold write access to financial data and are excluded from reviews. Treat them as in-scope users: give each an accountable owner, include them in access reviews and privileged listings, prevent interactive logon, and show that credential rotation does not depend on the person who left. See the Service Account Security Guide.

Program change controls

Program change controls show that changes to in-scope applications, configurations, interfaces, reports and database objects were authorised, tested, approved and implemented in a controlled way.

Complete population: the change population must come from the system itself (transport logs, deployment pipeline history, database change logs), not from the ticketing tool, so auditors can see changes that bypassed the process.
Separation of developer and deployer: developers should not be able to move their own changes to production. Where small teams make this impossible, a detective review of all production changes by an independent person is the standard compensating control.
Configuration counts: in SaaS and ERP platforms, configuration such as approval thresholds, tolerance keys or posting rules changes control behaviour without code. Bring it under change control.
Emergency changes: allow them, but require retrospective approval within a defined period and track the count.
Pipelines: in CI/CD, the control becomes enforced code review by someone other than the author and protected branches, with pipeline service credentials limited so they cannot be used to push changes outside the pipeline.
Direct data changes: data fixes in production databases are changes too; log and approve them.

Computer operations controls

Job scheduling: changes to scheduled jobs that post, calculate or interface financial data are authorised, and access to the scheduler is restricted.
Job and interface monitoring: failures are detected, investigated and resolved, with evidence that reruns were complete.
Backup and recovery: backups of in-scope data run and are monitored, and restores are tested. Scope this to the data and systems that financial reporting actually depends on.

Testing ITGCs: walkthroughs, evidence and IPE

AS 2201 says walkthroughs "will frequently be the most effective way" to understand flows and confirm controls are designed and in place: the auditor follows a transaction from origination and questions staff at each processing point. Prepare control owners to walk through the real process, not the policy. After design, auditors test operating effectiveness over the period, with sample sizes scaling with control frequency and risk, and AS 2201 notes that testing closer to the assessment date provides more evidence, which is why interim testing is followed by roll-forward work.

Information produced by the entity: AS 1105 requires auditors using company information as evidence to test its accuracy and completeness, or the controls over it (including ITGCs and automated application controls where applicable), and to evaluate whether it is sufficiently precise and detailed. For every key report and every user listing used in a review, keep the report logic or parameters, the run date, and a completeness check such as a record count reconciled to source. In April 2024 the PCAOB reported that about 17% of audits inspected in its 2021 and 2022 cycles had deficiencies in testing such information.
SOX evidence quality: system-generated, timestamped, showing who performed and who approved. Screenshots without dates or parameters are the most common rejection.
Reliance by the external auditor: AS 2201 lets auditors use the work of internal audit and others after assessing their competence and objectivity, with more of their own work on higher-risk controls. Consistent test scripts and evidence standards across management testing make reliance more likely.

Evaluating ITGC deficiencies

Term (AS 2201 Appendix A)	Definition in short	Illustrative ITGC example (severity is always a judgement)
Deficiency	Design or operation of a control does not allow timely prevention or detection of misstatements	A few leavers disabled late, no evidence of use
Significant deficiency	Less severe than a material weakness, yet "important enough to merit attention by those responsible for oversight"	Access reviews for a key application not performed for two quarters
Material weakness	A deficiency or combination such that there is a reasonable possibility a material misstatement will not be prevented or detected on a timely basis	Pervasive ITGC failures across the ERP, with no compensating controls, affecting automated controls over revenue

To evaluate an ITGC deficiency, identify every application control and key report that depends on it; ask whether the failure could actually have affected them (was there privileged activity, was any unauthorised change made); look for compensating controls such as an independent review of all production changes or a detective review of privileged activity; and consider aggregation across ITGCs on the same system. AS 2201 indicators of a material weakness include fraud by senior management, restatements, auditor-identified misstatements the controls would not have caught, and ineffective audit committee oversight. Remediated controls need to operate for long enough before year end to be tested.

SOX readiness and audit prep

Risk assessment and scoping: agree significant accounts with finance, map key controls and systems, and share the scoping memo with the external auditor early.
Control design: write a control description for each ITGC with objective, owner, frequency, population source and evidence, aligned to COSO Principle 11.
Dry run: walk through and test a small sample in the first cycle to find design gaps before the audited period. Treat failures as findings to fix, not to hide.
Remediate and automate: close design gaps, then automate populations and evidence capture (account listings, change logs, review sign-offs) where it reduces IPE effort.
Operate and monitor: quarterly management testing, sub-certifications supporting 302 sign-offs, and change monitoring so a system migration is assessed as a potential change in ICFR.
Year end: roll-forward testing, deficiency evaluation with the auditor, and remediation plans for anything open.

Measuring ITGC health and framework mapping

Leaver timeliness: percentage of in-scope accounts disabled within the defined window after HR termination (target 100%).
Change compliance: production changes with matching approval and independent deployer, from the system population (target 100%).
Review completion: access reviews completed on time with removals actioned within the agreed period.
Privileged and non-human accounts: share of privileged and service accounts with a named owner and included in reviews.
Deficiency trend: ITGC deficiencies found by management before the external auditor, by quarter.

ITGC domain	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022	CIS Controls v8.1
Logical access	AC-2, AC-5, AC-6, IA-2	A.5.15, A.5.18, A.8.2, A.8.5	5, 6
Program change	CM-3, CM-5, SA-10	A.8.32, A.8.4	16 Application Software Security
Computer operations	CP-9, CP-10, AU-6	A.8.13, A.8.15	11 Data Recovery, 8 Audit Log Management
Service organisations	SA-9	A.5.19, A.5.22	15 Service Provider Management

Common failure patterns

Review populations from the wrong source: access reviews built from a spreadsheet instead of a system listing with completeness evidence, so the whole review fails as IPE.
Database and OS layers forgotten: application access is tight, but DBAs and generic database accounts can change financial tables directly with no monitoring.
Developers with production access: justified as support, never reviewed, with no independent change review to compensate.
Service accounts outside scope: interface and batch users with write access to the ledger, shared passwords and no owner.
SOC 1 reports filed, not read: exceptions, period gaps and complementary user entity controls are ignored.
Late remediation: controls fixed in the fourth quarter cannot operate long enough to be tested, so the deficiency stands at year end.

Practitioner checklist

Scope ITGCs top-down from key controls and reports, and document the rationale for each in-scope system and layer.
Write each ITGC with owner, frequency, population source and evidence standard.
Test deprovisioning against the HR termination list and check for post-termination activity.
Restrict and review privileged access at application, database and identity provider layers.
Include service, interface and bot accounts in access reviews with named owners.
Pull change populations from the system and enforce developer and deployer separation or an independent review.
Keep accuracy and completeness evidence for every key report and review listing.
Read every SOC 1 Type 2 report, map its exceptions and complementary user entity controls, and obtain bridge letters.
Remediate deficiencies early enough for the fixed control to operate and be tested before year end.

Standards and references

Related NHI Mgmt Group resources: Segregation of Duties Guide · Access Reviews Guide · Privileged Access Management Guide · Compliance Automation Guide. This guide summarises SOX ITGC requirements and is not legal advice.