ITGC Scoping for SOX in SaaS Environments: 2026 Practitioner Walkthrough

If your financial reporting runs on Workday, NetSuite, Salesforce, Coupa, or any other vendor-managed platform, your ITGC scoping problem is fundamentally different from the textbook version. The systems you depend on most are ones you don't own, can't directly inspect, and can't patch. Yet PCAOB AS 2201 still requires your auditor to obtain an understanding of the IT general controls relevant to financial reporting, full stop.

This guide walks through the scoping decision end-to-end, with the SaaS dimension front and centre. It covers the regulatory basis, the four-question in-scope test, how SOC 1 Type II reports factor in (and where they stop), what complementary user entity controls (CUECs) are and why they remain your responsibility, and how to document a scoping rationale that survives PCAOB inspection scrutiny.

Key takeaway: SaaS doesn't shrink your ITGC obligations. It redistributes them. The vendor owns the infrastructure controls; you own the CUECs, configuration management, and access governance. Scoping that ignores this split is the single most common source of ITGC audit findings in cloud-heavy environments.

What Is ITGC Scoping and Why Does It Matter Under SOX?

ITGC scoping is the decision about which IT systems are subject to general controls testing under your SOX Section 404 programme. Get it right and your controls work covers what matters with manageable effort. Get it wrong in either direction and the programme suffers: too narrow and you miss material risks; too broad and you exhaust the team on systems that don't affect the financial statements.

The regulatory basis is not optional. PCAOB AS 2201 paragraph .16 mandates a top-down, risk-based approach: start with entity-level controls, identify significant accounts and disclosures, then trace back to the processes and IT systems that produce them. SEC Release No. 33-8810 makes clear that management's ICFR assessment must cover IT controls at service organisations, not just on-premise systems. And COSO 2013 Principle 11 requires the organisation to select and develop general control activities over technology to support the achievement of objectives, regardless of whether that technology is on-premise or SaaS-hosted.

The scale of the challenge is real. A KPMG 2026 survey of over 2,900 audit and risk leaders found that 65% of organisations had seen an increase in the number of systems coming into SOX scope, and 87% reported that cloud adoption had increased the complexity and effort of ICFR. According to EY's 2024 SOX survey, 67% of companies cited cloud and SaaS migration as the top driver of ITGC scope changes, and 43% had experienced at least one ITGC finding related to a SaaS application in the prior audit cycle.

For context on how ITGC testing fits into the broader SOX 404 evidence cycle, see our design vs. operating effectiveness testing walkthrough.

Step 1: Scope from the Financial Statements Backwards

The correct direction is financial statement line items to IT systems, never the reverse. Starting from the IT estate and asking "which of these is in scope?" produces over-scoping every time.

Here's the sequence:

1. List significant accounts and disclosures. Work from the auditor's materiality threshold. Revenue, cost of goods sold, deferred revenue, payroll, accounts payable, and financial close are almost always significant. Your auditor sets the threshold; your job is to map from there.
2. Identify the business processes that produce each account. Revenue traces to order-to-cash; payroll traces to its own process; close and consolidation are typically scoped together. Map each significant account to its upstream process.
3. Identify every IT system that touches each process. Include the obvious systems (ERP, payroll, consolidation tool) and the less obvious ones: CPQ tools, revenue recognition engines, expense management platforms, billing systems, and any integration or middleware that moves data between them. Deloitte's SOX/ICFR practice guidance specifically flags that companies frequently miss ancillary systems like CPQ and revenue recognition engines when focusing only on the primary ERP.
4. Apply the in-scope test to each system (see Step 2 below).
5. Document the rationale for every inclusion and exclusion (see Step 5 below).

This backward-from-the-financials approach is also the regulatory approach. AS 2201 paragraph .16 is explicit: the auditor identifies significant accounts and disclosures and the relevant assertions, then traces to the processes and controls, including IT controls, that support them.

Step 2: Apply the Four-Question In-Scope Test to Every System

A system is in scope for ITGC testing if it answers "yes" to any one of these four questions, per Big-4 consensus guidance anchored to AS 2201:

KPMG's SOX IT scoping guidance adds a fifth practical test: does the system produce information used as an input to a key control (sometimes called "IPE" or information produced by the entity)? If a report from Salesforce feeds a manual revenue reconciliation, Salesforce is in scope even if it doesn't directly post to the general ledger.

For SaaS applications specifically, the test applies identically. Stripe processing revenue transactions is in scope. Rippling processing payroll is in scope. Workiva producing the financial statements is in scope. The fact that you don't own the infrastructure doesn't change the answer to the four questions.

Step 3: Understand What SOC 1 Type II Reports Cover (and What They Don't)

A SOC 1 Type II report from your SaaS vendor is not a substitute for ITGC testing. It is a partial input to it.

Here's what a SOC 1 Type II actually provides, under AICPA SSAE 18: an independent service auditor's opinion on the design and operating effectiveness of the vendor's controls over a defined period, for the control objectives stated in the report. That's genuinely useful. But it has four hard limits:

• It covers the vendor's controls, not yours. The controls the vendor operates on the shared infrastructure are tested. The controls your organisation must operate on top of that infrastructure are not.
• CUECs are explicitly carved out. Every SOC 1 report identifies complementary user entity controls: controls that the service organisation's system assumes the user entity has in place. These are your ITGC responsibility, not the vendor's.
• The period must match your audit period. A SOC 1 report covering January through September doesn't cover your December year-end. You need a report that spans your full audit period, or you need to bridge the gap with additional procedures.
• Exceptions in the report matter. A qualified service auditor's opinion, or a report with noted exceptions, requires additional evaluation. You can't simply file the report and move on.

PwC's ICFR technical guidance is direct on this point: relying on a SOC 1 report without identifying and testing CUECs is a common audit finding. The PCAOB's 2024 inspection cycle confirmed the same, citing cases where auditors relied on SOC 1 reports without adequately evaluating the relevance of the control objectives or testing CUECs at the user entity.

What to do with the SOC 1 report in practice

1. Obtain the report and confirm it covers the relevant audit period.
2. Confirm the control objectives in the report are relevant to your financial reporting risks.
3. Read the service auditor's opinion and review any exceptions or deviations noted.
4. Extract the CUEC list from the report.
5. Map each CUEC to a company-side control, test it, and document the evidence.

Step 4: Identify and Test Your CUECs

Complementary user entity controls (CUECs) are the ITGCs that remain your responsibility even when your SaaS vendor has a clean SOC 1 Type II. They are not optional and they are not the vendor's problem.

Common CUECs across SaaS financial applications include:

• User access provisioning and deprovisioning. The vendor controls who can be a user in principle; you control who at your organisation gets access, what role they receive, and whether terminated employees are removed promptly. Grant Thornton's 2024 SOX/ICFR guidance identifies inadequate user access reviews for SaaS applications, particularly around terminated employees and role changes, as one of the three most common ITGC deficiencies in SaaS environments.
• Periodic access reviews. Quarterly or semi-annual reviews of who has access to in-scope SaaS applications, and at what privilege level, are a standard CUEC. These reviews are your control to design, operate, and evidence.
• Data input controls. If your organisation sends data into the SaaS system (via integration, file upload, or manual entry), controls over the completeness and accuracy of that input are your responsibility.
• Configuration change controls. This is the emerging ITGC domain that most scoping guides miss entirely.

Configuration management: the SaaS-specific ITGC domain

In an on-premise environment, change management covers code and infrastructure changes. In a SaaS environment, the vendor manages the code. But your organisation controls the configuration: approval workflow thresholds, business rules, integration mappings, role definitions, and automated calculation parameters.

A change to an approval threshold in Coupa, a modification to a revenue recognition rule in Salesforce Revenue Cloud, or a change to a payroll calculation in Workday can materially affect financial reporting without triggering a traditional IT change management process. BDO's SOX advisory practice specifically flags configuration management as an emerging ITGC domain that requires its own controls: a change request process, approval requirements, testing before deployment, and evidence of the change for audit purposes.

If your current ITGC programme has access controls and change management for on-premise systems but no configuration change controls for SaaS applications, you have a gap that will surface in the audit.

Step 5: Handle the Subservice Organisation Problem

Most SaaS vendors run on AWS, Azure, or GCP. That creates a fourth-party risk that your scoping must address.

Under SSAE 18, a SaaS vendor's SOC 1 report will handle its cloud infrastructure provider using one of two methods:

The carve-out method is more common. When you see it, your scoping memo needs to document that you obtained and reviewed the subservice organisation's SOC 1 report (AWS SOC 1, Azure SOC 1, or GCP SOC 1 are all publicly available) and confirmed that the relevant control objectives are covered.

This is not a theoretical risk. The PCAOB's 2023 inspection reports identified ITGC deficiencies in cloud environments as a recurring finding, including cases where auditors failed to obtain sufficient evidence about IT controls at service organisations and their subservice providers.

Step 6: Handle SaaS Vendors Without a SOC 1 Report

Newer or smaller SaaS vendors, particularly in fintech, HR tech, and revenue operations, often don't have a SOC 1 Type II report. This is a common situation and it has a defined answer.

Per AICPA/PCAOB guidance, you have two options:

1. Direct testing. Your auditor (or you, with auditor agreement) tests the vendor's controls directly. This requires vendor cooperation, is often impractical, and is rarely the path taken.
2. Compensating controls. You implement and test company-side controls that mitigate the risk that would otherwise be addressed by the vendor's ITGCs. This is the practical path for most companies.

Compensating controls in this context typically include:

• Enhanced reconciliations between the SaaS system's outputs and your general ledger
• Manual review of all transactions processed by the system above a defined threshold
• Periodic data integrity checks comparing source data to system outputs
• Restricted access controls with enhanced monitoring

The critical requirement: document the risk the missing SOC 1 would have addressed, the compensating control you implemented, and the evidence that the compensating control operated effectively. Without that documentation, the compensating control doesn't exist from an audit perspective.

Also note: PCAOB Staff Audit Practice Alert No. 11 warns against excessive reliance on prior-year testing without considering changes in the IT environment. SaaS vendors push updates continuously, outside your direct control. Your testing must cover the full audit period, not just a point in time.

Step 7: Document the Scoping Rationale

The scoping memo is the document auditors ask for first and find missing most often. It needs to exist, be current, and answer the question "why is X in scope and Y out of scope?" for every material system.

A defensible scoping rationale document includes:

• The methodology statement. Confirm you used the top-down, risk-based approach per AS 2201 paragraph .16, starting from significant financial statement accounts.
• The significant accounts list. With the materiality basis and the auditor's concurrence.
• The process-to-system mapping. For each significant process, the systems identified and the basis for inclusion or exclusion.
• The in-scope system inventory. Each system, its owner, the financial reporting risk it addresses, and the ITGC domains applicable to it.
• SOC 1 reliance documentation. For each in-scope SaaS system: the SOC 1 report obtained, the period covered, the control objectives assessed as relevant, the exceptions noted, and the CUECs identified and tested.
• Subservice organisation assessment. For each SaaS vendor using the carve-out method, the subservice organisation's SOC 1 report obtained and the relevant control objectives confirmed.
• Exclusion rationale. For every system considered and excluded, a written explanation of why it failed the in-scope test. Auditors ask "why is X out of scope?" and the answer needs to be in writing.
• Change log. The date the scope was last reviewed and any systems added or removed, with the basis for the change.

The SEC's guidance in Release 33-8810 is clear that management cannot simply defer to the service organisation's SOC 1 report. Management must evaluate whether the controls at the service organisation are effective and whether CUECs are in place. The scoping memo is how you demonstrate that evaluation happened.

ITGC Scoping for IPO-Stage Companies

Companies preparing for a US listing with a SaaS-heavy environment face a compressed version of this problem. Many have never formally scoped or tested ITGCs, and the remediation timeline is not forgiving.

Deloitte's IPO readiness guidance puts the typical timeline at 12 to 18 months to achieve audit-ready ITGC maturity from a standing start in a SaaS-heavy environment. The first audited financial statements filed with the SEC need to be supported by a defensible ICFR programme, which means the scoping work, CUEC identification, and control design need to be done before the audit, not during it.

For IPO-stage companies, the practical sequence is:

1. Engage a Big-4 or specialist firm for an ITGC readiness assessment 18 months before the expected listing date.
2. Run the scoping exercise using the steps above, with the prospective auditor's input on significant accounts and materiality.
3. Identify all in-scope SaaS applications and obtain SOC 1 reports for each.
4. Build and document CUECs for every in-scope SaaS system.
5. Implement configuration change controls for SaaS applications.
6. Run a dry-run testing cycle at least one full period before the first audited year-end.

For the broader IPO financial reporting preparation context, see our IPO underwriter selection walkthrough.

The Four Most Common ITGC Scoping Mistakes in SaaS Environments

1. Assuming the SOC 1 report covers everything. It covers the vendor's controls. Your CUECs are still your problem. This is the most common source of ITGC findings in SaaS environments, per Grant Thornton's 2024 guidance.

2. Missing ancillary systems. The ERP is always in scope. The CPQ tool feeding the revenue recognition engine, the expense management platform, the billing system, the payroll integration, the close management tool: these are frequently missed. Deloitte's 2024 guidance specifically flags this pattern.

3. No configuration change controls. Traditional change management covers code. SaaS configuration changes (approval thresholds, workflow rules, calculation parameters) require their own control framework. Most programmes don't have one.

4. No written exclusion rationale. Auditors ask why systems are out of scope. If the answer isn't in writing, the exclusion isn't defensible. Document every exclusion with the specific in-scope test question it failed and the basis for that conclusion.

FAQ

What is the difference between ITGC and SOX controls? ITGC (IT general controls) are the foundational controls applied across IT systems to ensure their security, availability, and integrity. SOX controls are the broader set of entity-level, process-level, and IT-dependent controls that together support reliable financial reporting under Section 404. Every SOX-relevant automated or IT-dependent control rests on ITGC: if the ITGC foundation is weak, the auditor can't rely on the controls built on top of it.

What are the four domains of ITGC? PCAOB AS 2201 and standard Big-4 practice identify four core ITGC domains: (1) access to programs and data (user provisioning, access reviews, authentication); (2) change management (how changes to systems are designed, tested, approved, and deployed); (3) computer operations (batch jobs, backups, incident management, interface monitoring); and (4) program development (how new systems or significant changes are acquired, configured, and moved into production). In SaaS environments, configuration management is increasingly treated as a fifth domain.

What is SOX compliance for SaaS companies? For a company using SaaS applications in its financial reporting process, SOX compliance requires: scoping in-scope SaaS systems using the four-question in-scope test; obtaining and evaluating SOC 1 Type II reports from each vendor; identifying and testing all CUECs; implementing configuration change controls; and documenting the scoping rationale. The company retains full ICFR responsibility even when the underlying infrastructure is vendor-managed.

Does a SOC 1 Type II report replace ITGC testing? No. A SOC 1 Type II report covers the vendor's controls over the defined period and control objectives in the report. It does not cover the company's CUECs, configuration change controls, or access governance. Relying on a SOC 1 report without testing CUECs is one of the most common ITGC audit findings, per PwC's ICFR guidance and PCAOB 2024 inspection findings.

What if our SaaS vendor doesn't have a SOC 1 report? You have two options: direct testing of the vendor's controls (which requires vendor cooperation and is often impractical) or compensating controls at the company level. The compensating controls path is more common. It requires documenting the risk the missing SOC 1 would have addressed, the compensating control implemented, and evidence that the control operated effectively during the audit period.

How does filer category affect ITGC scoping? Large accelerated filers and accelerated filers are subject to both management's assessment under SOX 404(a) and the external auditor's attestation under 404(b) and PCAOB AS 2201. Non-accelerated filers and emerging growth companies (EGCs) are subject to management's assessment only, with no auditor attestation requirement. The scoping methodology is the same in both cases, but the evidence standard and auditor scrutiny are higher for 404(b) filers. See our SOX 302 vs 404 comparison guide for the full filer category breakdown.