Unicorn? Soonicorn? Make Sure SOX ITGC is in Your Sights

TL;DR: SOX ITGC are the IT general controls that support reliable financial reporting: access to programs and data, program changes, program development, and computer operations. They protect the systems that financial controls depend on. Scope follows the company's financial-reporting risks, and a vendor's software does not replace the issuer's responsibility for those controls.

The obligation behind SOX ITGC sits with the company, not with any tool it buys. Under Section 404 of the Sarbanes-Oxley Act, management assesses the effectiveness of internal control over financial reporting (ICFR) and reports that assessment when the requirement applies. Financial reporting runs on IT systems, so the controls over those systems form part of the assessment.

A financial application can calculate the right number today and produce an unreliable result after an unapproved change tomorrow. IT general controls address the access, changes and operating conditions behind the calculation. Understanding that dependency tells you which IT controls belong in the SOX program and why the auditor asks about them.

Two questions run through the whole program. The first is scope: which IT controls actually support the financial statements. The second gets less attention and takes more work: whether each of those controls operated across the period the assessment covers, and whether the records exist to show it. A control named in a policy and a control whose operation an auditor can trace across that period are two different claims, and most of a SOX ITGC program is the distance between them.

The four ITGC domains

ITGC is usually grouped into four domains, covering who can reach financial systems, how those systems change, how new ones are built, and how they run day to day.

The SEC's management guidance identifies these four areas as examples of IT general controls that may support financial reporting. They are a way to organize the assessment, not four boxes every company must check in exactly the same way. Scope each domain to the applications and risks that matter to your financial statements. A control that only improves operational efficiency does not enter SOX scope simply because it belongs to IT.

Access to programs and data

The risk here is unauthorized or excessive access: accounts that outlive the person who held them, privileges wider than the job, or a change made by someone who should not have been able to make it. These controls keep access to financial systems and their data matched to what each role needs. Typical controls:

• Access is granted, changed, and removed as people are hired, moved, and offboarded.
• User access rights are reviewed on a schedule, and the review is recorded.
• Privileged and administrative access is limited to named people and justified.
• Segregation of duties in financial systems is configured so that no one both requests and approves the same transaction.

For teams running recurring reviews across those systems, user access review software brings the access population and reviewer decisions into the same process. The control owner still decides which access is appropriate.

Program changes

Change management governs how changes to financial systems are requested, tested, approved, and moved into production, so a change cannot alter the numbers without anyone knowing. Typical controls:

• Each change is tested and approved before it reaches production.
• Development and production are separated, and the right to promote a change is restricted.
• Emergency changes are logged and approved after the fact, not left unrecorded.

Program development

Building or bringing in a new financial system runs from the development lifecycle to the go-live itself. The risk is a new system, or a data migration into it, that quietly carries errors into financial reporting. Typical controls:

• A new system goes live through a defined lifecycle, with go-live formally approved.
• Data migrated or converted into the new system is checked for completeness and accuracy before cutover.

Computer operations

Running the systems day to day is what keeps financial data complete and available. Typical controls:

• Scheduled jobs are monitored, and failures are investigated and resolved.
• Backups are taken, and restores are tested rather than assumed.
• Incidents and problems affecting financial systems are logged and closed.

ITGC vs ITAC vs SOX Section 404

ITGC, ITAC, and SOX Section 404 get used almost interchangeably, and they are three different things. ITGC are controls over the relevant IT environment. IT application controls (ITAC) operate within an application, such as an automated three-way match on a purchase order or an input-validation check. Section 404 establishes management's assessment responsibility and, where applicable, the auditor's attestation responsibility.

That distinction explains the dependency. A three-way match can work as designed while someone with excessive privileges changes the program or its underlying data. Effective access and change controls support reliance on the match; they do not replace testing whether the match itself does the right job.

Under PCAOB AS 2201, Appendix B, an auditor may use prior testing of an automated control when the relevant general controls remain effective and tested, and the auditor verifies that the application control has not changed. Related files, tables and parameters can matter too. This is a conditional testing approach, not an automatic exemption from testing. A failed ITGC requires evaluation of the controls and financial-reporting risks it affects; it does not by itself prove that every application control has failed.

Preparing ITGC before an IPO

Before an IPO, those system dependencies help determine which IT controls need attention. Growth can expose the limits of an informal approach: more systems, business units, and people create more access and change decisions to account for. Finance and IT need to agree which of those systems support financial reporting, who owns the relevant controls, and what records will demonstrate that they operated. Connect that work to the company's reporting obligations so the relevant controls and evidence are in place for the first required assessment.

The timing is what makes this hard. The first required assessment lands on a fixed date, but it judges controls that were meant to operate through the period leading up to it, and a company that spent that period as a private business rarely kept records to a public-company standard. You cannot reconstruct a control that was never recorded. So the practical move is to start the record now and let the evidence accumulate toward the first assessment, rather than treating readiness as a document to assemble in the final quarter.

Put the controls that need work into operation, retain evidence, and investigate exceptions. Allow time to remediate deficiencies and evaluate whether the revised controls work. The SEC's management guidance explains that the effort needed for an initial ICFR evaluation varies with the company and its existing risk assessment and monitoring. A growing team can use automation to collect and organize records, while control owners continue to make and document the decisions those records support.

From point-in-time collection to evidence over time

This is where the annual model strains. Management reaches its ICFR conclusion as of fiscal year-end, but a control that operates over the year can only support that conclusion with records that show it operating across the period it is relied on. So the evidence has to match how the control runs: a review performed each quarter, a change approval tied to each release, or monitoring that runs each day. Those controls leave different records, and a folder of current screenshots cannot stand in for any of them.

The failure mode is familiar. A team reconstructs evidence in Q4 and finds that a current access list says little about a role change in March. A July release may need its original test and approval records, not a picture of the application in December. The useful question is what the evidence actually covers. An export collected today may contain historical events; a snapshot of today's settings may not.

Coverage is not the only test the evidence has to pass. Under PCAOB AS 1105, an auditor relying on information the company produced has to be satisfied it is complete and accurate, and effective ITGC are part of what makes that information trustworthy. A system export that carries its query, its scope and its timestamp answers that on its face. A screenshot assembled by hand raises the next question: what did it leave out? A control can be strong on paper and weak in evidence, and how the record is produced decides which one it is.

Collect records as the work happens, preserve their dates and source, and keep the reviewer's decision with them. The amount and timing of testing still depend on the control and its risk. Collection supports the assessment; it does not make a control effective by itself. Our article on continuous compliance monitoring explains how ongoing monitoring changes the work between reviews.

Some of the systems behind the numbers are not yours to collect from. When a financial application runs at a service organization, the evidence for its controls comes from that provider's SOC 1 report, the service auditor's report on the controls relevant to your financial reporting. The complementary user entity controls the report leaves to you stay yours to operate and evidence. That report can also cover a period that does not line up with your fiscal year, which leaves a gap you bridge with your own records. Outsourcing the system does not outsource the responsibility for the controls that depend on it.

Anecdotes connects evidence collection to the systems a program already uses. Its compliance application gives control owners a place to work with evidence and requirements. Collection schedules and source coverage need to match the control being assessed, and a named owner remains responsible for reviewing the result. The reason IT auditing still matters as automation grows is that more data does not remove that judgment. For the wider evidence and review workflow, our SOX ITGC software page explains the platform's role.

SOX ITGC review: scope and dependencies

The domain examples above describe the controls. Use this review to connect them to your own financial systems. It is a scoping aid for the ITGC assessment; the SOX compliance checklist covers the wider control, evidence and reporting work.

1. Start with financial reporting. Identify the applications and data used for the financial statements and the risks those systems can introduce. Keep controls that address those risks in scope; document why unrelated operational controls sit outside it.
2. Identify the dependent control. Name the automated calculation, transaction check, report or manual review that relies on each system. A system name alone does not explain what could go wrong in the financial statements.
3. Connect the relevant ITGC. Use the four domains to identify which access, change, development and operations controls support that dependency. Preserve the link between the risk, the control and the responsible owner.
4. Match the evidence to the operation. An access review needs a review record; a release needs its testing and approval trail; a restore test needs a result. Record the systems, populations and dates covered by the evidence.
5. Follow exceptions to their consequences. If a general control fails, identify the dependent applications and financial-reporting risks, investigate the exception, and evaluate any compensating controls. Retain the decision and the remediation evidence.
6. Carry the result into the SOX assessment. Give the program owner the scope, evidence, findings and unresolved issues needed for the assessment and applicable disclosures. An IT control owner supplies evidence; management reaches the ICFR conclusion.

This is also why mapping a control to a requirement and proving that it operated are separate jobs. The mapping explains why the control belongs in the program. The evidence supports the conclusion about its operation. For the responsibilities around that IT work, see SOX compliance for IT: requirements and best practices.

Frequently asked questions

What is SOX ITGC?

SOX ITGC are the IT general controls relevant to reliable financial reporting under a company's SOX program. They cover the access, changes, development and operations of systems that financial controls depend on. Scope follows the company's financial-reporting risks, rather than every system or IT control it operates.

What are the four ITGC domains?

The four common domains are access to programs and data, program changes, program development, and computer operations. They cover who can reach financial systems, how existing systems change, how new systems go live, and how those systems run. The SEC guidance treats these as examples to evaluate in the company's circumstances, not a universal checklist prescribed in the statute.

What is the difference between ITGC and ITAC?

ITGC support the IT environment; ITAC perform a specific application-level control, such as matching an invoice or checking an input. Reliable application processing often depends on effective general controls. The auditor considers that dependency and the relevant testing evidence when deciding how much reliance to place on an application control.

Why does SOX require ITGC?

Section 404 addresses internal control over financial reporting. When financial reporting depends on IT, the general controls supporting that IT form part of the assessment of the relevant financial-reporting risks.

Who has to comply with SOX ITGC?

SOX reporting requirements apply to issuers reporting to the SEC, including foreign private issuers; they are not confined to US-incorporated businesses. Applicable reports and exemptions depend on the issuer's status. For domestic issuers, Item 308 provides a transition for newly public companies' first annual ICFR reports. Auditor attestation has separate applicability rules. Begin IPO preparation before the first assessment is due so there is time to evaluate the controls and address deficiencies.

Is SOX ITGC a certification a vendor can hold?

No. SOX ITGC is not a vendor certification scheme. A vendor can support an issuer's control work, and controls at a service organization may be relevant to the issuer's assessment. An issuer can meet its applicable SOX obligations, but buying a tool does not supply a SOX certificate or transfer management's responsibility to the vendor.

‍