Which applications and IT layers are in SOX scope

A system is in scope when it initiates, records, processes or reports transactions that flow into a financial statement account or disclosure that management has already judged significant. Start from the account list and the assertions for each account, then trace the transaction path back to the systems that touch it, including intermediate tools that hold or transform the data. Evidence to gather: the significant account inventory, a dated data flow diagram for each account, and walkthrough notes showing which system records each step. A system that only supports a non-financial process usually sits outside this boundary, but confirm that with the data flow rather than assuming it.

Yes. If a control depends on an automated calculation, a configured rule or a system-generated report, the application that performs or produces it is in scope, and so are the layers that supply its data and logic. Auditors ask for the report or query and the system that generated it, because a control over a report is only as reliable as the report. Evidence to gather: a list of every automated control and key report used in the financial close, the system and version that produces each one, and the report writer or query tool involved. Spreadsheets used to build a key report also need a clear owner and a documented source.

Write access to a database or directory lets someone change financial data or the users who can act on it without going through the application. If a user or service account can alter tables, master files or rate tables, that database and the directory that authenticates it become part of the ITGC boundary, even when the application itself looks well controlled. Evidence to gather: a list of accounts with write or schema privileges, the directory groups that map to them, and the procedure for approving direct data changes. Confirm this with your database and directory administrators, because service accounts and scheduled jobs often hold more rights than the people who manage them expect.

If administrators or developers can alter application code, configuration, or parameters without an approved change, the change control and access layers for that application are in scope, and the gap is an ITGC risk that auditors will test. Changes made directly in production, emergency fixes that skip review, and shared privileged accounts all fall in this category. Evidence to gather: the privileged account list for the application, the change tickets that match production change logs, and the procedure for emergency access with after-the-fact review. Where a path around the process exists, document it now, because the auditor will look for it whether or not your team considers it routine.

Yes, when an interface carries financial data into or out of a significant application, the integration middleware, file transfer jobs and the accounts that run them are relevant to the completeness and accuracy of that data. An interface that drops or duplicates records can misstate a balance even when both ends of the interface are well controlled. Evidence to gather: an interface inventory showing source, target, frequency, and transfer method, the reconciliation or control total that confirms completeness, and the logs or alerts for failed transfers. Ask who can change the interface mapping or schedule, since that person can alter what the financial system receives.

The hosting arrangement changes how you get evidence, not whether the layer is in scope. If a provider runs the database, operating system, hypervisor or network for a financial application, that layer is still in scope, and management remains responsible for the controls over it. Some controls are shared, and the division of responsibility should be written down. Evidence to gather: the provider contract and service description, the provider's independent assurance report if one exists, the list of customer-managed controls, and your own access and change records for the layer. Ask the provider what evidence they will supply and on what schedule, because that determines how the auditor can test the layer.

No. Scope follows financial reporting risk, not the number of systems that touch a ledger. A system is generally in scope when it initiates, records, processes or reports transactions for significant accounts, or when it holds data or configuration that an automated or IT-dependent control relies on. Feeder systems, reporting tools and interfaces are often in scope for that reason, while a system that only supports operational efficiency may be excluded. Management documents the reasoning for each inclusion and exclusion, and the external auditor decides whether that reasoning holds. Confirm the boundary with your auditor before fieldwork begins.

It depends on what the spreadsheet does in the control. A spreadsheet that performs calculations, holds a rate or threshold, or produces a report that management relies on as the basis for a control is generally treated as information produced by the entity, and its logic, inputs and access need to be reliable. Auditors commonly ask who can change the formulas, where the source data comes from, and whether the output is checked for completeness and accuracy. Spreadsheets that only store reference notes usually fall outside scope. Document each relied-on spreadsheet in your scope inventory and agree its treatment with the auditor.

Scope should be reviewed at least once each fiscal year, before the year's testing plan is set, and again when something changes. Common triggers include a new or upgraded financial application, a change in how a significant account is processed, a new interface or database, an acquisition, a move to a cloud or outsourced provider, and a change in the company's filer status or risk profile. A scope review that only repeats last year's list is a weak signal to an auditor, so record what was reconsidered, what changed and why. Ask your auditor which triggers they expect to see documented.

Yes, when it initiates, records, processes or reports financially significant transactions, or when it holds data or logic that controls rely on. Self-hosting does not change the scope logic. It does change ownership: the company operates the servers, databases, identity integration, change pipeline and backups, so those layers carry ITGC responsibility directly. Scope usually extends to the application, its database, the operating system, the directory it authenticates against and the administrative access paths. Its open-source origin does not make it out of scope, and a community license does not reduce what evidence the auditor expects.

An implementation partner can help map the systems in the financial chain, document their layers, configure access and change controls, prepare evidence and run walkthroughs with your team. The partner prepares systems and evidence. It does not decide final scope, and it does not issue audit reports or attestations. Final acceptance of scope rests with the external auditor, and the company's management remains responsible for its controls. Ask any partner to put the scope deliverables, the systems covered and the handover to your team in a written scope before work starts.

The company must keep ownership of the scope decision itself, the list of in-scope systems and the reasoning behind each inclusion and exclusion. Management must also own the risk assessment, the list of significant accounts and assertions, and the accountability for each control. Operating the controls, approving access and changes, and reviewing scope each year stay with internal staff, as does the relationship with the external auditor. Outside help can support any of this, but a reader should be able to explain the scope to an auditor without the partner in the room.