SOX ITGC audit: how the test works and what it costs

What a SOX ITGC audit tests and who pays for it

Management assesses IT general controls (ITGCs) as part of internal control over financial reporting (ICFR) at every fiscal year end under Section 404(a) of the Sarbanes-Oxley Act. The external auditor tests those ITGCs under PCAOB AS 2201 only where Section 404(b) applies, which covers accelerated and large accelerated filers that are not emerging growth companies. Every public company still owes management's annual assessment, so the cost of ITGC work is never optional, even when the auditor attestation is not required. The company owns its controls and its conclusion. An implementation partner such as DeployOpen can prepare systems, configuration records and evidence, but only the independent auditor issues the attestation report. No SEC rule or PCAOB standard publishes a catalog of IT general controls. SEC Release 33-8810 says the ITGC aspects relevant to an ICFR evaluation vary with each company's facts and circumstances, and it names program development, program changes, computer operations and access to programs and data as areas management might consider. Management only needs to evaluate the ITGCs that keep other financial reporting controls working consistently, not those that affect only operational efficiency. The practical question is therefore which financially significant systems, databases and infrastructure feed those controls, and that scoping decision should be documented before testing begins.

Filer status decides whether an auditor will test your ITGCs in addition to management's review. Under SEC Rule 12b-2, an accelerated filer has $75 million or more but less than $700 million of public float, and a large accelerated filer has $700 million or more, both measured at the end of the second fiscal quarter. Issuers eligible for the smaller reporting company revenue test are excluded. Confirm your float calculation with counsel and your auditor each year, because a change in status changes the testing you must prepare for. The SEC's 2020 estimate of about $210,000 per year in savings for newly exempt issuers (Release 34-88365) shows how much of the cost sits in the auditor attestation, but it does not cover management's own ITGC work, which continues either way.

How the ITGC audit runs from scoping to the attestation

The sequence starts with management choosing which systems and risks matter, then moves through documentation, testing and the auditor's own risk work, and ends with an ICFR conclusion that the auditor attests to where Section 404(b) applies. Each phase produces a specific output that feeds the next.

Scope systems and risks top-down
Management starts at the financial statements and works down. It identifies the material accounts, disclosures and locations, then the business processes that produce them, then the applications, databases, operating systems, networks and service providers those processes depend on. SEC Release 33-8810 asks management to evaluate only the IT general controls needed for the proper and consistent operation of controls that address financial reporting risks, so this step separates financially significant systems from those that affect only operational efficiency. The output is a scoping memo that lists in-scope systems, the risks each addresses and the rationale for exclusions, reviewed by the people who own the controls.
Document ITGCs that support automated controls
For each in-scope process, management identifies the automated controls, such as a three-way match or a system-enforced approval limit, and then the ITGCs those controls depend on. Because automated controls often rely on effective general controls over access, program changes and computer operations, the team records which ITGCs must work for each automated control to keep working. The output is a control matrix that links each automated control to the ITGCs it depends on, with the owner and the evidence expected for each.
Perform walkthroughs of each process
A walkthrough follows one real transaction from origination through the system to the financial record, while the tester observes the controls and asks the control owner how they operate. For ITGCs, the walkthrough confirms that the system configuration, the user access process and the change process work as the documentation says. The output is a walkthrough memo that confirms the controls were understood as designed, or records where the documentation and the actual process differ, which becomes a finding to evaluate.
Test design and operating effectiveness
Management tests whether each ITGC is designed to address its risk, then tests whether it operated effectively over the period. Design testing asks whether the control, if performed as described, would catch the risk. Operating effectiveness testing samples occurrences, such as access reviews, approved changes or backup restores, and checks the evidence for each sample. Management can use its own staff or internal audit, subject to their competence and objectivity. The output is a test workpaper for each control with the sample, the evidence examined, the exceptions found and a conclusion on effectiveness.
Assess auditor risk and IT understanding
The external auditor performs its own risk assessment under AS 2110. Under paragraph B1 of Appendix B, the auditor must understand how the company uses IT, the mix of manual and automated controls, and the ITGCs important to the operation of those automated controls. The auditor uses this understanding to decide which controls to test and how much reliance to place on management's work. The output is the auditor's documented risk assessment and the planned testing approach for the year, which includes which ITGCs the audit will rely on.
Run the auditor's varied control testing
The auditor tests selected controls under AS 2201 and may use the work of internal auditors and others working for management, scaled to their competence, objectivity and the risk of the control. Under paragraph 61, the auditor varies the nature, timing and extent of testing from year to year so the testing is not predictable. The auditor may test a baseline of an automated control only if general controls over program changes, access and computer operations are effective and continue to be tested, as paragraph B29 requires. The output is the auditor's own control test results, which either confirm or challenge management's conclusions.
Complete interim testing and roll-forward
Much of the testing happens before fiscal year end. Interim testing covers the period up to a date before year end, and roll-forward testing covers the remaining period through year end. Changes to systems, personnel or processes during the gap must be considered, because a control that worked at the interim date may not work at year end. The output is a documented roll-forward conclusion that states whether the ITGCs and dependent controls operated effectively through fiscal year end, or identifies changes that required additional testing.
Issue the ICFR conclusion and attestation
Management evaluates the results of its testing and any deficiencies, then concludes on the effectiveness of ICFR as of fiscal year end under Rule 13a-15(c) and the 404(a) report. Where Section 404(b) applies, the registered public accounting firm attests to management's assessment under AS 2201, integrated with the financial statement audit. The output is management's ICFR report in the annual filing and the auditor's attestation report. Only the independent auditor issues the attestation. Management and any outside consultant prepare the evidence the auditor reviews.

The four ITGC areas auditors test and why

SEC Release 33-8810 names four IT general control areas management might consider, but it presents them as examples rather than a fixed catalog. Each area protects a different link between systems and the financial numbers, and only the ITGCs that support reliable operation of financial reporting controls fall inside scope.

Access to programs and data

This area limits who can change financially significant applications, databases and infrastructure to people whose duties justify that access. The risk is that an unauthorized user alters balances, postings or master data without leaving a trace. Auditors typically ask for a current user access listing, evidence of periodic access reviews with reviewer sign-off, and records showing that terminated and transferred employees lost access on time. Check privileged accounts and segregation of duties conflicts first, since those drive the most serious findings.

Program changes

This area confirms that changes to financially significant applications, configurations and infrastructure are requested, approved, tested and moved to production under control. The risk is that an unreviewed change alters how a calculation or report behaves while the automated control still appears to run. Auditors usually sample change tickets and look for approval before development, test evidence, and a separation between the person who builds a change and the person who promotes it. Emergency changes need their own documented path and after-the-fact review.

Program development

This area covers how new financially significant systems are acquired, built and implemented, including testing, data conversion and go-live approval. The risk is that a system goes live with logic errors or incomplete data migration, and the errors then flow into every period. Auditors commonly ask for project approvals, test plans and results, reconciliations that show converted balances match the legacy source, and a signed go-live decision. Ask whether the organization treats a major upgrade or a new reporting module as development work under the same discipline.

Computer operations

This area keeps financially significant processing running completely and accurately. It includes job scheduling, backup and recovery, incident handling and oversight of IT service providers. The risk is that a failed batch, lost data or an unmonitored outage produces incomplete or inaccurate financial records. Auditors typically look for job monitoring logs, failed job resolution records, backup completion and restoration test results, and incident tickets linked to their follow-up. When a third party hosts the system, the organization still needs evidence that the provider's operations were reviewed.

Scope limited to financial reporting

Management evaluates only the ITGCs needed for the proper and consistent operation of other controls that address financial reporting risks. An ITGC that affects only operational efficiency, such as a helpdesk service level, generally falls outside the ICFR evaluation. Before testing, confirm which applications, databases and infrastructure feed financially significant accounts, and document why each excluded system does not affect those accounts. Auditors will challenge a scope that leaves out a system their own risk assessment considers relevant.

Why ITGCs matter to automated controls and the auditor's reliance

IT general controls rarely prevent a misstatement on their own. The point of an ITGC is to keep the automated controls that do address financial reporting risk working as designed. SEC guidance in Release 33-8810 says ITGCs alone ordinarily do not address financial reporting risks, but automated controls often depend on them. An invoice match, a tolerance check or a system-calculated accrual is only as reliable as the program logic behind it, and that logic can change without anyone noticing if program change, access and computer operations controls fail. Management should map each automated key control to the specific ITGCs it depends on before testing begins, and record that link in the control documentation.

This dependency drives how the external auditor tests. Under paragraph B29 of PCAOB AS 2201, the auditor may rely on a baseline from prior years for an automated control that has not changed, but only if the general controls over program changes, access and computer operations are effective and the auditor keeps testing them. In practice, a clean prior-year result for a key report calculation does not carry forward when the program change process has gaps or privileged access is unreviewed. Finance and IT should confirm, for each automated key control, that the ITGCs supporting its baseline were tested in the current year, and plan for the baseline to be retested when they were not.

Auditors may also use work done by internal audit and others working for management or the audit committee, under paragraphs 16 to 19 of AS 2201. The reliance is scaled to the competence and objectivity of those testers and to the risk of the control, so a well-documented internal audit test of user access reviews is more likely to be used than an informal check by a process owner. Companies that want the external auditor to accept this work should keep test scripts, sample selections, exceptions and reviewer sign-offs, and should confirm early in the year which testing the auditor plans to rely on.

Who owns controls, who prepares evidence and who attests

Management owns internal control over financial reporting. Section 404(a) requires management to assess, as of fiscal year end, whether ICFR is effective, and Rule 13a-15(c) requires that assessment to rest on a suitable, recognized framework. That duty is personal to management and cannot be handed to a vendor. The audit committee oversees the process and the external auditor's work on behalf of the board.

Assessment ownership: Management designs the IT general controls, decides their scope, evaluates deficiencies and concludes on effectiveness.
Control operation: Named control owners perform access reviews, approve changes and monitor job runs, and they keep the records that show it.
Evidence retention: Management keeps the evidence that supports its assessment, including tickets, approvals, logs and review sign-offs.
Commonly outsourced: Sourcing of configuration work, testing support and documentation drafting, with management still reviewing and accepting the output.
Audit committee role: Oversight of the assessment, of significant deficiencies and of the auditor's communications.

Confirm with your auditor which IT general controls they expect management to evaluate and which evidence they will sample, before any outside party starts work.

What makes ITGC testing larger or longer

Most of the effort in a SOX ITGC audit comes from how many systems, locations, providers and changes sit inside scope, and how well evidence is produced as a routine byproduct. The cards below cover the drivers that expand testing and the scoping and evidence choices that keep it contained.

Financially significant system count

Every application, database and infrastructure component that feeds a financial report or an automated control must be assessed for access, change and operations controls. Each added system multiplies walkthroughs, samples and evidence requests. Start from the financial statement line items and work down to the systems that process them, then confirm each system's role in writing. Remove systems that only support operational efficiency, since management need not evaluate ITGCs that affect only efficiency.

Locations and third parties

Each data center, business unit, shared service center and outsourced provider adds its own access reviews, change records and operations evidence. Where a provider runs a system, you need to know what it controls and what you still have to test yourself. Ask each provider early for its independent assurance report and map which controls it covers. Locations that touch no in-scope system should be documented as out of scope with a reason.

Manual and automated control mix

Automated controls, such as a system enforcing a three-way match or a calculated reserve, depend on ITGCs that keep their logic and configuration stable. A higher share of automated controls means more ITGC testing, because the auditor must rely on those general controls. Manual controls, such as a reviewer signing a reconciliation, rely on different evidence. Map each key control to its type early so the ITGC work follows the automated controls it protects.

Change volume and emergency fixes

The number of production changes in the year sets how many items auditors sample from program change controls. Frequent releases, direct database updates and emergency fixes that skip normal approval add the most work, because each one needs a documented authorization, testing and approval trail. Reduce effort by standardizing change categories, using a single ticketing workflow linked to deployment records, and requiring retrospective review of emergency changes within a defined window set by your own policy.

Identity sprawl and privileged access

Shared accounts, stale users, service accounts with broad rights and privileged roles spread across applications and infrastructure all widen the population that access reviews must cover. Auditors test whether provisioning, periodic recertification and removal of terminated users work as designed, and whether privileged activity is monitored. Consolidate identity into a central directory where feasible, document who owns each role, and generate the user listing directly from the source system so the population is complete.

Evidence maturity

When evidence is produced by the system and retained in a consistent place, testing moves quickly. When it has to be assembled from screenshots, email threads and spreadsheets months after the fact, the same control takes far longer and invites exceptions. Define a standard evidence set for each control, name the owner and the system report that generates it, and set a retention rule. Confirm with your auditor which populations and report formats they will accept before the year starts.

What a SOX ITGC audit costs by component

This table lists the cost components of SOX ITGC work, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for scoping a quote, since no supplied source gives a total price for ITGC work. The main takeaway is that internal labor is usually the largest share, so the fastest way to control cost is to reduce evidence gathering effort.

Cost component	Who is paid or bears the cost	One-time or recurring, and main driver
External auditor fees for the 404(b) attestation	Registered public accounting firm	Recurring each fiscal year. Driven by the number of ITGC-dependent controls, systems in scope and testing samples.
Management internal labor	Company staff in IT, finance and compliance (not a payment to a vendor)	Recurring. Usually the largest share. Driven by manual evidence collection, number of control owners and ticket quality.
Co-sourced internal audit or outside advisers	Consultants or co-source providers	Recurring for testing support, one-time for initial design. Driven by gaps found in prior years and the depth of independent testing.
Implementation partner work on systems and evidence	Partner engaged under a written, fixed-scope agreement	Mostly one-time for configuration and evidence design, with optional recurring support. Driven by number of systems, legacy platforms and automation.
Tooling and log or ticket retention	Software vendors or infrastructure providers, including self-hosted platforms	Recurring licenses or hosting, plus storage. Driven by log volume, retention period and number of integrated systems.
Remediation of ITGC failures	Internal teams and any external support used	One-time per failure, then recurring testing. Driven by severity, whether compensating controls exist and timing before year end.

What must be in place before the auditor arrives

Auditors test IT general controls by sampling evidence across a full period, so the gaps they find are usually gaps in preparation rather than in intent. The six items below form one chain: scope defines what is tested, design documents how it works, owners answer for it, and evidence proves it operated. Check each one before fieldwork starts, not during it.

Current scope and risk assessment

Confirm that the list of financially significant applications, databases, operating systems, network components and reports reflects this year's systems, not last year's. Each in-scope system should trace to a financial reporting risk, such as a ledger, subledger or reconciliation tool that feeds the financial statements. Ask who approved the scope and when, and whether any system added, retired or migrated during the year is reflected. Management owns this decision; the auditor will test whether it is complete.

Documented ITGC design

Each in-scope control area should have a written description of the control, the system it covers, the frequency, and the precise step where a person or tool performs the check. Walk one control from the policy statement to the system setting to confirm the document matches what the system does. Gaps often appear where a procedure exists only in an administrator's head or in a ticket comment. Written design is what lets an auditor test operating effectiveness consistently.

Named control owners

Every ITGC needs a named person accountable for performing it and a backup for when that person is absent. Confirm that owners have the authority and access to perform the control and that they understand what evidence they must produce. An access review signed by someone who cannot see the underlying permissions does not hold up. Record owner names in the control matrix so the auditor can direct questions to the right person.

Access review evidence

Check that periodic reviews of user access to financial applications, databases and infrastructure were completed for each period in the year. Each review should show the population reviewed, the reviewer, the date, the exceptions found and how they were resolved. Confirm that privileged and administrative accounts are reviewed separately and that terminated or transferred users were removed on time. Ask the system to export the user list as of the review date so the reviewer's sign-off matches the data.

Change tickets with approvals

Sample a set of production changes to financially significant systems and confirm each has a ticket showing the request, the business or technical approval, evidence of testing, and the date the change reached production. Compare ticket dates with deployment logs to catch changes deployed before approval. Check that emergency changes were approved after the fact and reviewed. Gaps here commonly come from changes made directly on infrastructure that bypassed the ticketing workflow.

Job monitoring, backup and retained evidence

Confirm that scheduled batch jobs and financial interfaces are monitored, that failures generate alerts with documented follow-up, and that backups run and restores are tested on a schedule. Keep the job logs, backup reports and restore test records together in one retained location with a defined retention period set with counsel. Verify that the evidence can be retrieved for the full audit period, not only the most recent months. An auditor who cannot retrieve a log from the period under test will treat the control as not evidenced.

Common questions about the SOX ITGC audit

Does a public company need an outside partner for SOX IT general controls?

No rule requires an outside partner. Under Section 404(a), management owns its assessment of internal control over financial reporting, and the company decides whether to use internal staff, consultants or both. An outside partner typically helps when internal teams lack capacity or experience with ITGC testing, or when the company is preparing for its first assessment. The external auditor's role is different: under PCAOB AS 2201, the auditor performs its own testing and issues the attestation for accelerated and large accelerated filers that are not emerging growth companies. An implementation partner can prepare systems, configurations and evidence, but only the independent auditor issues the attestation. Ask any partner to put its role in writing so that management, not the partner, remains accountable for the conclusions.

Can our own IT and finance teams run SOX ITGC testing without help?

Yes, many companies do this with internal staff. SEC Release 33-8810 lets management evaluate the IT general controls needed for the proper and consistent operation of controls that address financial reporting risks, and the guidance does not prescribe who performs the work. The practical question is whether your team can document the scope, perform walkthroughs, test design and operating effectiveness, and keep evidence that holds up to review. Under AS 2201, the auditor may use the work of internal auditors and others working for management, scaled to their competence and objectivity and to the risk of the control. Independence matters: testers who also operate the systems they test create weaker evidence. Confirm your internal approach with your external auditor before the year begins.

How long does SOX ITGC testing take for a company?

The duration depends on the drivers below, so no general timeline applies. The number of in-scope applications, databases and infrastructure components sets the volume of testing. The maturity of change management, access reviews and job monitoring affects how many samples are needed and how many exceptions need investigation. Whether financial systems run in-house, in cloud or with service providers adds documentation steps for each party. Timing also matters: testing performed before year end and rolled forward to the fiscal year end takes less last-minute effort than a compressed cycle. Ask any partner for a written scope that lists systems, control areas, testing periods and deliverables before agreeing to a schedule.

Does a SOC 1 report from a service provider replace our own ITGC testing?

No. A SOC 1 report from a service organization describes that provider's controls, but it does not replace the company's own SOX IT general controls. Management still has to evaluate the controls over the company's own access, program changes and computer operations, including how it uses the provider's services. Management and auditors can rely on the report only after reading its scope, testing period, exceptions and complementary user entity controls, and confirming that the services relevant to financial reporting are covered. Gaps in those user entity controls are the company's responsibility. Review the report with your auditor early, because a report that does not cover the right period or system can leave a testing gap.

What happens when an IT general control fails during a SOX audit?

A failed ITGC is evaluated as a control deficiency, and the severity depends on its effect on financial reporting. Under AS 2201, the auditor considers whether the failure affects automated controls that depend on it. An ITGC failure can therefore undermine reliance on automated controls, even when the automated control itself worked in the sample tested. Management should identify the affected automated controls, test whether compensating controls exist, and remediate before the fiscal year end where possible. Under AS 2201, a baseline for an unchanged automated control can be relied on in later years only if general controls over program changes, access and computer operations are effective and continue to be tested. Severity classification and disclosure decisions belong to management and the audit committee, with the auditor's communication as an input.

What evidence must a company provide to the external auditor for ITGCs?

The company must provide evidence that its controls operated throughout the period, not only a description of them. Typical items include the system scope list, process documentation and walkthrough results, access listings with approval records and periodic review sign-offs, change tickets showing authorization, testing and approval before production, job monitoring logs, backup and recovery test results, and incident and service provider oversight records. Management also needs to keep evidence that supports its ICFR assessment. Ask the auditor early to confirm the population definitions, sample expectations and format it prefers, because incomplete or system-generated lists without a completeness check are a common source of rework.

Do we have to show the auditor the same ITGC controls every year?

The auditor's approach changes from year to year. Under AS 2201, the auditor must vary the nature, timing and extent of control testing from year to year to introduce unpredictability. Management should not expect an identical sample or test procedure each cycle. Companies that keep stable, well-documented controls and retain consistent evidence usually make the yearly cycle easier, because changes in testing approach do not require rebuilding evidence from scratch. Confirm with your auditor which items change in the coming year, including new systems, reorganized teams and changed providers, since each change can expand scope.

How DeployOpen prepares systems and evidence for the ITGC audit

DeployOpen works on SOX ITGC audit preparation as an implementation partner. We scope the systems and controls in writing, build and configure the self-hosted open-source platforms inside your own infrastructure, and document the evidence management needs for its assessment and the external auditor's testing. Management owns the controls, and only the independent auditor issues the opinion.

How we scope

Agree in writing which financially significant applications, databases and infrastructure fall inside the ITGC scope
Map each in-scope system to the four ITGC areas: access, program changes, program development and computer operations
Confirm with your auditor and finance leads which reports and automated controls depend on each system

How we build

Configure role-based access, approval workflows and logging on self-hosted platforms in your own cloud or data center
Set up change management records, test and approval gates, and separation of duties in the delivery pipeline
Document backup, recovery and job scheduling configurations so operating effectiveness can be tested across the year

How we hand over

Deliver control narratives, walkthrough documentation and a control-to-evidence matrix for management's ICFR file
Provide access review extracts, change tickets, job logs and restore test records in formats your team retains
Train control owners on evidence collection so they can answer auditor requests without rebuilding records

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement
Revisit scope and evidence when systems change, new reports go live or the auditor requests additional samples
Coordinate with your internal audit and external auditor on evidence requests, while leaving assessment conclusions to them