How do you scope SOX IT general controls with a top-down, risk-based approach?
If your company must support its ICFR assessment under Section 404, scope starts from significant accounts and relevant assertions, not from a list of IT systems. Management works down from the financial statement level and entity-level controls to the significant accounts, disclosures and assertions those controls cover, then identifies the automated and IT-dependent controls that address those risks. IT controls that only affect operational efficiency are left out. SEC Release 33-8810 says management needs to evaluate only the IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks. PCAOB AS 2201, paragraph 21, describes the same top-down sequence that auditors follow when they select controls to test.
The result differs from company to company. Neither the SEC nor the PCAOB publishes a catalog of IT general controls, and Release 33-8810 states that the aspects of ITGCs relevant to an ICFR evaluation vary with each company's facts and circumstances. Two companies with the same ERP may end up with different scope because one relies on a configured three-way match for payables and the other relies on a manual reconciliation. The practical work is to trace each significant account to the application that initiates or records it, the automated control that processes it and the access, change and operations controls that keep that control reliable. Document the reasoning for each exclusion so an auditor can follow it.
Management owns the scope decision. It must be documented, approved and supportable, and it must reflect the company's own risk assessment rather than a template from a consultant or prior year. An implementation partner or co-sourced internal audit team can help map systems to accounts and draft the documentation, but the company remains accountable for what is in scope. The external auditor then tests that scope independently under AS 2201, and it may challenge an omission it considers relevant to a significant account. Before finalizing the list, confirm with your auditor which applications, reports and layers they expect to see covered.
The scoping steps from financial statements down to in-scope systems
The sequence starts at the financial statements and entity-level controls, narrows to the accounts and assertions that matter, and ends with a register of the applications, reports and infrastructure that the relied-on controls depend on. Each step produces a written artifact that management and the external auditor can both trace.
Assess entity-level controls and financial statement risk
Management starts at the financial statement level by reviewing the control environment, risk assessment, monitoring and other entity-level controls, such as internal audit and the audit committee's oversight. The output is a list of material risks to reliable reporting and the entity-level controls that address them. Management can show that this work preceded any IT review, because PCAOB AS 2201 treats the top-down approach as the starting point for choosing what to test.
Identify significant accounts and disclosures
Using the same materiality considerations that apply to the annual financial statement audit, management identifies the significant accounts and disclosures, such as revenue, inventory, payroll and financial close. Quantitative thresholds are only part of the judgment, so qualitative factors such as fraud risk and complexity also count. The output is a scoping list of significant accounts and disclosures, with the rationale for each inclusion and exclusion.
Map relevant assertions to each account
For each significant account, management determines which financial statement assertions, such as existence, completeness, valuation or presentation, could be misstated and how. This turns a general account label into specific risks. The output is a risk-to-assertion matrix that later steps use to decide which processes and controls are needed to address each assertion.
Document processes and key control points
For each account, management walks through the business process from initiation to the general ledger, identifying where transactions are created, changed, approved, reconciled and reported. Walkthroughs confirm that the process works as described. The output is a process narrative and a set of key control points, each linked to the assertion it addresses, and each recorded so that the control owner and frequency are clear.
Flag automated and IT-dependent controls
Within the key control points, management separates manual controls from automated controls and from manual controls that depend on system-generated information. Automated controls and IPE-dependent controls are the ones that bring IT into scope, because SEC guidance says automated controls often depend on effective IT general controls. The output is a list of IT-dependent controls, along with a note on whether each control relies on a system function, a report or both.
Trace dependencies to applications, reports and infrastructure
For each IT-dependent control, management traces what the control needs to work, including the application, the database, the operating system, directories, interfaces, and any spreadsheet or query that produces a report the control uses. The output is a dependency map. Where a layer is needed for the control to operate as intended, it belongs in scope, and where a component only supports operational efficiency, it can stay out of scope.
Confirm the in-scope system register
Management consolidates the dependency work into an in-scope system register that lists each application, database, infrastructure component, report and location, the controls relying on it, and the ITGC areas that apply. Management and the external auditor should review this register together. The register is complete when every relied-on control maps to at least one in-scope system, and when each exclusion has a recorded reason tied to financial reporting risk.
Which IT controls can be left out of SOX scope
Management does not need to evaluate IT general controls that only affect operational efficiency. SEC Release 33-8810 limits the ITGC evaluation to the controls necessary for the proper and consistent operation of other controls that address financial reporting risks. An IT control that speeds up a help desk queue, improves reporting dashboards used only by operations, or tunes non-financial system performance can usually be left out. The guidance also says ITGCs alone ordinarily do not address financial reporting risks. The reason to keep a control in scope is therefore never that it is an IT control. It is that a financially significant control, automated control or report depends on it. Write down each excluded IT control, the financial reporting risk you checked against it, and the reason it does not support any in-scope control.
The practical test is dependency. If an automated application control, such as a three-way match, a calculated accrual or an interface reconciliation, is relied on in the top-down scope, the ITGCs that keep that logic stable become in scope: change management over the application and its configuration, access to the program and its data, and computer operations for the jobs and interfaces it depends on. The same applies to system-generated reports used in controls. The report's source data, query logic and report writer must stay reliable. Map each in-scope automated control and key report to the specific ITGCs it needs, and confirm the dependency with the control owner. A layer that no in-scope control depends on, such as an unrelated reporting database, is a candidate for exclusion.
Before you finalize exclusions, confirm the rationale with your external auditor. Under AS 2110, the auditor must understand the IT general controls important to automated controls, and that understanding determines which ITGCs they test and how much reliance they place on your system controls. An exclusion that the auditor sees as hiding a dependency can expand the audit or produce a deficiency finding late in the year. Share your dependency map and exclusion memo early, ask the auditor which automated controls they plan to rely on, and record their feedback. Revisit the scope when systems change, when a new automated control is added, or when a related control fails.
What makes SOX ITGC scope larger or smaller
Scope follows from the financial reporting risks, not from the size of the IT estate. The drivers below determine how many IT general controls management must evaluate and how many systems, locations and providers the evidence must cover, so each one is worth checking before the scope is locked.
Number of significant accounts
Each significant account and disclosure, traced through its relevant assertions, pulls in the applications, interfaces and data flows that produce it. Scope grows with every account that carries material risk. Keep it contained by mapping accounts to assertions in a single matrix, retiring accounts that no longer meet materiality, and reviewing the matrix whenever the chart of accounts or close process changes.
Automated controls that key controls rely on
A key control that depends on system logic, a report or a configurable rule brings the ITGCs over that system into scope. One reconciliation that relies on a system calculation can pull in access, change and operations controls for several layers. Ask for a list of every key control marked automated or IT-dependent, and confirm which ones the business could perform manually if the system failed.
Financially significant applications and hosting model
Each financially significant application needs its own ITGC coverage, including the database, operating system and infrastructure beneath it. On-premises, private cloud and SaaS hosting split responsibility differently, so the same application can produce different evidence work. Confirm which systems touch financial data, where each is hosted and which layers management controls directly.
Locations and shared service centers
Each entity, region or shared service center that processes financial transactions adds access, change and operations controls to test. Lower-risk units may be covered by entity-level controls instead of full ITGC testing. Document why each location is in or out, and align that choice with internal audit so the selection is defensible in the auditor's review.
Third-party and cloud providers
Outsourced hosting, managed services and SaaS providers can hold financially significant data and perform changes, backups or access reviews on your behalf. Management still owns the controls, so each provider that affects an in-scope system needs a documented reliance approach, such as obtaining the provider's service organization report and mapping its complementary user entity controls. Ask each provider which of its controls you must perform yourself.
Maturity of existing risk documentation
Scope is only as stable as the risk assessment that supports it. Undocumented assumptions about which systems matter, stale process narratives and spreadsheets maintained outside the control inventory tend to widen scope at audit time as gaps appear. Keep a current risk and control matrix tied to account, assertion and system, and record the rationale for each exclusion so that scope decisions can be reproduced by someone who did not make them.
How scope changes for on-premises, cloud and hybrid finance systems
When an ERP or general ledger runs in the company's own data center or private hosting, management usually owns every layer that carries a financially significant process. Auditors typically start with the application and then follow the stack down to the database, the operating system, the directory that authenticates users, and the network components that control reach into the environment. Each layer can carry its own access and change controls, so a gap at the operating system or database level can undermine an application control that looks sound on its own.
- Application: user access, role design, configuration changes and the vendor patch process for the ERP itself.
- Database: privileged access to the financial data store and direct changes that bypass the application.
- Operating system: administrator accounts, patching and changes to the host the application depends on.
- Directory: account provisioning, deprovisioning and password or authentication settings that feed the application.
- Network: firewall and remote access rules that determine who can reach the application and database.
The company still owns the controls, the evidence and the decision about which layers are in scope. Ask your auditor which layers they expect to see documented for your ERP and whether they will rely on any vendor-provided evidence.
When a finance application is delivered as SaaS, or runs on infrastructure rented from a public cloud provider, part of the stack moves to the provider. The company usually cannot see or change the physical hosts, the hypervisor or the provider's internal network, and it relies on the provider's controls for those layers. The company still owns how its own users, roles, configurations and integrations are managed, and auditors look for evidence on both sides of that line.
- Application: the company owns user roles, approval workflows, configuration settings and any custom logic it builds.
- Directory: the company's identity provider and single sign-on settings often sit in scope even when the application is hosted elsewhere.
- Database and infrastructure: often managed by the provider, so the company's evidence usually comes from provider reports rather than its own configuration.
- Integrations: APIs, data feeds and service accounts that move financial data in and out remain the company's responsibility.
- Provider evidence: the auditor will ask for independent assurance reports covering the provider's controls, such as a SOC 1 or SOC 2 report, and for proof that the company reviewed them and mapped any gaps.
To confirm the boundary, ask your auditor which provider reports they will accept, how recent they must be, and which user entity controls the company must operate.
Hybrid environments split a financial process across locations, for example an on-premises ledger that feeds a cloud reporting tool, or a SaaS procurement application that posts to an internal ERP. Scope has to cover each system that carries financially significant data and each handoff between them, because a control can pass on one side and fail at the interface. Identity is a common shared layer, and a single directory often governs access to systems in both environments.
- Interfaces: scheduled jobs, file transfers and APIs that move balances or transactions between environments need completeness and accuracy controls.
- Shared identity: one directory may provision accounts in both the internal and the hosted systems, so its controls affect both sides.
- Duplicate layers: the same role or permission may exist in two systems, and the company must keep them aligned.
- Split ownership: internal teams own some layers while providers own others, so responsibilities need a written matrix.
- Network connectivity: the links between sites and providers carry data and privileged access, so their rules belong in the review.
Ask your auditor to confirm how they want interfaces and shared identity documented and whether each environment needs its own walkthrough.
Scoping decisions buyers must make and who owns each
This table lists the five scoping decisions that shape a SOX ITGC program, the party that owns each one, and the record that should hold it. Read it as a split of responsibility: management makes and signs the scope decisions, the external auditor tests and challenges them, and an implementation partner prepares the inventory and evidence that support them.
| Decision | Owner | Record that holds it |
|---|---|---|
| Significant accounts and relevant assertions | Management decides, auditor challenges | Scoping memo mapping accounts, disclosures and assertions to risks |
| ITGC areas to include (access, program changes, program development, computer operations) | Management, based on facts and circumstances | ITGC scope matrix stating which areas apply and why |
| Applications, databases, operating systems and network layers in scope | Management decides, implementation partner prepares the inventory | System inventory linking each in-scope system to the reports and automated controls it supports |
| Reliance on automated controls and system-generated reports | Management decides which controls and reports it relies on, auditor tests reliance | Control narratives and IPE listing that name the ITGCs each reliance depends on |
| Treatment of IT that only affects operational efficiency | Management, with auditor review | Scoping memo entry documenting why the system or process is excluded |
| Entity-level controls that reduce IT risk | Management, including internal audit and the audit committee | Entity-level control inventory and self-assessment results |
Who owns the scope decision and who prepares the inputs
Management owns the scope decision and its rationale. Under Section 404, management evaluates internal control over financial reporting (ICFR) as of each fiscal year end, and the SEC's guidance in Release 33-8810 expects that evaluation to start from financial reporting risks, not from a list of systems. Management identifies significant accounts and assertions, determines which automated and IT-dependent controls address those risks, and then decides which IT general controls those controls rely on. The company keeps the written record explaining why each application, database, infrastructure layer and hosting location is in or out of scope.
- Scope rationale: a documented link from each in-scope system to a significant account, assertion or key control.
- Documented exclusions: written reasons for IT controls left out because they only affect operational efficiency.
- Entity-level input: consideration of the control environment, internal audit and audit committee oversight when identifying risks.
- Sign-off: management approves the scope and the ICFR conclusion, and this authority cannot be handed to a vendor.
Check that the scope memo was approved before testing started and that it is updated when systems, hosting arrangements or acquisitions change.
An implementation partner such as DeployOpen prepares the inputs that management uses to make the decision. Typical work includes building a system inventory for the financial reporting environment, drafting control-to-system maps that show which applications, databases, operating systems, directories and network components each key control touches, and assembling evidence packages for access, change and computer operations controls. The partner can also flag gaps in the evidence chain, such as an unmanaged report or a privileged account that no one reviews. The partner does not decide what is in scope, does not decide which risks are significant, and does not issue an ICFR report, attestation or opinion.
- System inventories: applications, databases, operating systems, directories, interfaces and hosting locations, with named owners and data flows.
- Control-to-system maps: which IT general controls support each automated or IT-dependent control, prepared for management's review.
- Evidence packages: organized samples and configuration exports prepared for walkthroughs and for the auditor's requests.
- Gap observations: documented findings on missing evidence or unclear ownership, delivered to management with a suggested owner.
- Fixed-scope agreement: inputs, deliverables and dates are agreed in writing before work begins, which makes the boundary of partner work explicit.
Confirm that every partner deliverable is labeled as an input to management's decision and that management, not the partner, approves the scope.
The external auditor tests the scope that management has set and forms its own view. Under PCAOB AS 2201, the auditor plans the ICFR audit with a top-down approach that starts at the financial statement and entity level, then works down to significant accounts and relevant assertions. The auditor uses the same materiality considerations that apply to the financial statement audit. Under AS 2110, the auditor assesses IT risks and must understand the IT general controls that matter to automated controls. Where Section 404(b) applies, the auditor issues the attestation on ICFR. Only the independent auditor issues that attestation.
- Independent scope testing: the auditor checks whether management's significant accounts and systems are complete and supported.
- Own risk assessment: the auditor's understanding of IT risks can lead to additional systems or controls being tested.
- Attestation: issued only by the independent auditor, and only where Section 404(b) applies to the company.
- Independence limits: auditor independence rules restrict what a firm can do for an audit client, so the scope of any partner work must fit those rules.
- Communication: scope disagreements and deficiencies are raised with management and the audit committee.
Agree the scope and the evidence format with the auditor before testing begins, and confirm in writing which party prepares and which party issues each document.
What to have ready before the scoping review
A scoping review works only when the inputs are current and consistent with each other. The six items below feed the top-down path from financial statement risk to significant accounts, then to the IT systems and controls that support them. Check each item against the others before the review starts, because gaps in one usually show up as wrong scope decisions in another.
Current significant account list
List every financial statement account and disclosure that management has judged significant, with the relevant assertions for each. This is the starting point for the top-down approach, since every IT system in scope must trace back to one of these accounts. To check completeness, compare the list against the latest financial statements and the materiality figures used in planning, and confirm that new revenue streams, acquired entities and new disclosures have been added.
Process narratives and risk-control matrix
Narratives describe how transactions move from initiation to the general ledger, and the risk-control matrix links each financial reporting risk to the control that addresses it. Together they show where automated controls and IT-dependent controls sit. To check them, walk a sample transaction through each narrative and confirm that every step has a matching control row, and that every control names its owner and frequency.
Application and infrastructure inventory
Record each application, database, operating system, directory and network component that supports a significant account, with its owner, hosting location and interfaces to other systems. The layers beneath an application matter because they can change its data or its automated logic. To check completeness, reconcile the inventory against the general ledger feeds, interface logs and the list of systems that appear in change and access records.
Reports and spreadsheets used in controls
Identify every system-generated report, query and spreadsheet that management relies on in a control, such as a reconciliation, review report or approval listing. Each one is information produced by the entity, so its source data and logic need their own assessment. To check completeness, ask control owners which reports they used last quarter and compare the answers with the reports the system team can list from the reporting environment.
Provider list with SOC reports
List every outsourced or cloud provider that hosts, runs or changes a financially significant system, with the service it delivers and the most recent SOC report on file. Providers can carry part of the ITGC evidence, but management still needs to know which complementary user entity controls it must operate. To check completeness, compare the list against vendor payments, hosting contracts and the subservice organizations named in each provider's report.
Prior-year scoping memos
Prior scoping memos record which applications, locations and controls were judged in scope and why, and they show what changed since the last assessment. Reviewing them shows whether last year's rationale still holds after mergers, system migrations or new processes. To check them, confirm that each memo has a date, an approver and a list of changes since the prior year, and that any system dropped from scope has a documented reason.
Common questions about SOX ITGC scoping
How long does SOX ITGC scoping take and what drives the time?
Scoping takes as long as it takes to map significant accounts to the systems that process them, and the duration depends mainly on how many applications, databases and locations are involved and how well current documentation matches reality. The main drivers are the number of significant accounts, the count of automated controls and system-generated reports management plans to rely on, whether an application inventory and data flow diagrams already exist, and how many people must confirm facts. Companies with a clean inventory and a recent risk assessment usually finish faster than those rebuilding both. Ask any partner for a written timeline tied to the agreed scope, the list of interviews and the review cycles included, rather than a generic duration.
Can our finance and IT teams scope SOX ITGCs without outside help?
Yes. Neither SEC guidance nor PCAOB standards require an outside firm to scope IT general controls, and management owns the decision. The work requires people who understand financial close processes, the applications that feed the general ledger, and how automated controls depend on access, change and operations controls. Teams new to the process often struggle with mapping IT risks to assertions and with documenting why an application is out of scope. External help is usually a question of capacity and experience, so decide based on whether your internal team can produce a defensible rationale the auditor can test.
What does the external auditor need to review in our ITGC scope?
The external auditor must understand management's scope and test whether the top-down, risk-based analysis supports it. Under PCAOB AS 2201, the auditor works from the financial statement level and entity-level controls down to significant accounts and relevant assertions, and under AS 2110 it must understand the IT general controls important to automated controls. Expect the auditor to review the list of significant accounts, the systems and reports mapped to them, the risk assessment, and the rationale for excluding applications or layers. Gaps in that trail are a common source of follow-up questions.
How often should we refresh the ITGC scope?
Refresh the scope every fiscal year, and sooner when the financial reporting environment changes. SEC guidance expects management to evaluate ICFR as of each fiscal year end, so the scope must reflect the systems in use at that date. Triggers for an earlier review include a new ERP module, a system migration, a new subsidiary, an acquisition, a change in a significant account, or a finding in a prior assessment. Many teams also review scope at the start of each year to confirm that the application inventory and risk assessment still match the close process.
Does moving a financial system to a cloud provider change our SOX ITGC scope?
Usually the system stays in scope, but responsibility for evidence changes. Moving an application to a public cloud, SaaS platform or managed provider does not remove it from SOX scope if it processes financially significant transactions. The company still owns its access, change and operations controls and must obtain evidence about the provider's controls, often through a SOC 1 report and the company's own complementary user entity controls. Scoping should identify which layers the provider operates, which the company manages, and where the company's own controls must still operate.
What should a SOX ITGC scoping memo contain?
A scoping memo should state the scope decision and the reasoning behind it so an auditor can follow the trail without interviewing the author. It should include the significant accounts and disclosures considered, the relevant assertions, the applications, databases, operating systems, directories and locations in scope, and the reports and automated controls relied on. It should also record the IT risks considered, the excluded items with the reason each one only affects operational efficiency or does not affect financial reporting, the approvers, the date, and the planned refresh. Ask any partner to show a sample memo structure before the engagement starts.
What do we need to provide to an implementation partner for scoping?
A partner needs the materials that show how financial reporting actually flows through your systems. Typical inputs include the list of significant accounts and the prior year's ICFR documentation, an application and infrastructure inventory, data flow or interface diagrams, the prior year's ITGC testing results and any open deficiencies, and access to the people who run the close and the systems. Access to read-only environments or configuration records helps confirm facts. The written scope should list these inputs, the interviews and the reviews, so both sides know what the engagement depends on.
Scoping mistakes that inflate cost or delay the audit
Most expensive SOX ITGC scoping errors share one root cause: the scope was built from an inventory of systems instead of from the financial reporting risks those systems support. The cards below cover the mistakes auditors most often see and the checks that catch them before fieldwork starts.
Scoping by system list
Teams often start with a list of applications and mark each one in or out by name, without tracing which significant accounts and assertions depend on it. The result is either an oversized scope that tests systems carrying no financial risk, or a gap where a feeder system was never listed. Start from the significant accounts and work down to the systems that process them, then document the path. Check that every in-scope system traces back to a named account and assertion.
Leaving out spreadsheets and report writers
End-user computing tools, report writers and custom queries often produce the numbers that management and auditors rely on, yet they are absent from the scope document. When a spreadsheet calculates a reserve or a query extracts a population for a control, its logic, inputs and access matter for the reliability of that output. Inventory these tools during scoping and decide which ones feed key reports. Confirm who can change their formulas and where the source data comes from.
Ignoring provider-managed layers
Hosting providers, SaaS vendors and managed service partners often run the databases, operating systems or network components under a financial application. Scoping that stops at the application layer leaves the owner of those layers unknown, so no one requests the provider's access or change evidence. Map each in-scope application to every layer beneath it, mark which layers the company manages and which the provider manages, and confirm what assurance the provider can supply.
Excluding IT controls without a rationale
Teams sometimes drop an IT control from scope because it seems operational, but the file contains no reasoning. Management need not evaluate IT general controls that only affect operational efficiency, yet that conclusion must rest on an analysis of how the control relates to financial reporting risk. Record for each exclusion the risk considered, why it does not support a relied-upon control, and who approved the decision. Auditors ask for this reasoning first when they challenge scope.
Scoping IT separately from the risk assessment
Some organizations run a standalone IT review that never connects to the financial risk assessment. The auditor then has to reconcile two inventories, and controls chosen in one may not match risks identified in the other. PCAOB standards treat IT risk identification as part of the top-down process, not a separate exercise. Use one risk assessment in which each IT risk points to the general controls that address it, so scope changes flow through a single document.
Freezing scope without an annual refresh
A scope set in one year can drift as systems are added, migrated to cloud platforms, or acquired. Old scope documents that no longer match the production environment cause late additions during fieldwork, which delay the audit and raise cost. Review the scope at each fiscal year end against the current system inventory, significant accounts and any changes in hosting. Confirm that the review is dated, signed and kept with the scope file.
How DeployOpen prepares SOX scoping inputs
DeployOpen helps finance, IT and internal audit teams prepare the system inventory, dependency maps and evidence that a top-down, risk-based ITGC scope depends on. Management and the external auditor make the scoping judgments, and DeployOpen works inside the client's own infrastructure to make those judgments easier to document and test.
How we scope
- Scope is agreed in writing before work starts, listing the applications, databases, infrastructure and reports covered.
- We map significant accounts and assertions to the systems that record, process and report them in your environment.
- We identify which automated controls and reports depend on ITGCs, and document why operational-only IT controls sit outside scope.
How we build
- We configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to match the agreed scope.
- We document access, change and operations settings so the in-scope systems can be walked through and tested by your team and auditors.
- We integrate logging and reporting so evidence for in-scope systems can be pulled consistently, without manual reconstruction.
How we hand over
- Deliverables include a scoping memo, system inventory, dependency diagram and control-to-system mapping in editable formats.
- We walk management and internal audit through each document so ownership of every scoping decision stays with your organization.
- Runbooks and evidence procedures are handed over so your team can refresh the scope at each fiscal year end.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- We can prepare updated inventories and dependency maps when systems change, are acquired or move to new hosting.
- Questions about your auditor's expectations should be confirmed with them directly, since DeployOpen does not issue audit reports or attestations.
