How should organisations scope IT systems for SOX compliance when financial reporting depends on shared infrastructure?

Start by mapping the systems that can affect financial reporting, not just the report output itself. That includes servers, workstations, databases, and supporting platforms that store, process, or transmit sensitive financial data. The control objective is to reduce unauthorized access and preserve report integrity across the full information flow. A practical scope keeps attention on the systems most likely to influence accuracy, availability, and evidence of control.

Scope the control environment, not just the final report

SOX scoping should follow the path of the financial statement assertions, so the question is which systems can change, block, or distort the data that feeds those assertions. That means shared infrastructure matters when it stores, processes, transmits, or administers financial data, even if it does not produce the report itself. The practical boundary is the set of systems where a control failure could alter accuracy, completeness, availability, or audit evidence.

Shared platforms are especially important when one environment supports many applications or business units, because a weakness in the common layer can affect multiple reporting processes at once. In practice, organisations should treat the shared service as in scope when its configuration, access model, or failure mode can influence the integrity of a covered process. That is why scoping often includes servers, databases, identity and access layers, middleware, batch jobs, and supporting admin workstations.

For shared infrastructure, scoping should also reflect how controls are actually operated. If a control is inherited from a central platform team, then the platform itself may be the control point that must be tested, not only the downstream application. When evidence of review, logging, backup, job scheduling, or privileged access comes from the shared layer, the layer becomes part of the audit trail the organisation must trust.

How to decide whether a shared platform is in or out of scope

The cleanest test is whether removing that system would reduce the organisation’s ability to prevent, detect, or evidence misstatement in financial reporting. If the answer is yes, the system is likely in scope even when it is not a finance application. Shared infrastructure that holds master data, runs interfaces, feeds reports, or provides privileged administration usually meets that test because it can affect multiple downstream controls at once.

A useful second test is dependency. If a system is technically generic but is used by several in-scope applications, it often becomes part of the control boundary because its outage or misconfiguration can break a reporting control across the estate. Organisations commonly underestimate identity and access control mapping and end up scoping only the application while missing the shared admin and access layers that actually enforce segregation. Likewise, scoping should consider whether access decisions are centralised enough that the shared platform carries the real control burden.

When scoping is unclear, look at the evidence the auditor will need. If the organisation cannot show who had access, who changed the system, when jobs ran, or how exceptions were approved, the shared component is probably part of the control story. That is especially true where segregation of duties is enforced through shared infrastructure, because the control exists in the environment that grants, monitors, or restricts the activity.

Shared infrastructure changes the audit focus on access, monitoring, and evidence

In SOX programs, shared infrastructure is rarely excluded just because it is common or enterprise-wide. Instead, it is usually scoped by function: does it support financial reporting, security administration, interface processing, logging, job scheduling, or storage of controlled data? If it does, the audit focus shifts from “is this a finance server?” to “does this system participate in a key control or create a path to misstatement?” That is why a shared database, virtual host, file transfer service, or jump host may all be in scope.

Access management is usually the most important practical issue. If shared infrastructure allows privileged users to reach multiple in-scope systems, the organisation must be able to prove that access is restricted and reviewed. Controls for privileged access management and just-in-time access often determine whether the shared layer is a limited support service or a material control dependency. If standing privileged access can reach multiple financial systems, the scope should expand to the control points that grant and record that access.

Shared infrastructure also affects how evidence is collected. When logs, configuration baselines, and change records sit on a common platform, the organisation should scope that platform if auditors will rely on it to validate control operation. A system that stores evidence for many in-scope controls is not merely supporting infrastructure; it is part of the integrity chain for the reporting environment. In those cases, cloud entitlement and privilege management or other centralised governance controls may be necessary to keep the shared layer from becoming a hidden control gap.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
SOC 2 (AICPA)	CC6.1 — Logical and Physical Access Controls	Shared infrastructure scope depends on restricting access to systems supporting reporting.
Recommendation — Define access boundaries for shared systems that support financial reporting and review them regularly.
ISO/IEC 27001:2022	A.5.15 — Access control	SOX scoping for shared infrastructure hinges on limiting who can reach reporting-relevant systems.
Recommendation — Apply access control to shared infrastructure that can influence financial reporting or its evidence.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Privileged shared platforms should be scoped where excessive access could alter reporting data or controls.
	AU-2 — Audit Events	Shared infrastructure often becomes in scope because audit logs and evidence are needed for SOX controls.
Recommendation — Restrict shared-platform privileges to the minimum needed for reporting-related operations. Log reporting-relevant activity on shared systems and retain the records needed for control testing.
NIST CSF 2.0	PR.AA-05 — Identity and Access Management	Shared infrastructure is in scope when identity and access controls govern financial-reporting dependencies.
Recommendation — Map shared services that enforce access to reporting assets and verify those access paths are controlled.

Practitioner Guidance

What to prioritise: Start with the systems that can change financial data, control access to it, or provide evidence that the control operated. Shared infrastructure should be tested when it is part of that chain, not only when finance owns it.

What to verify: Confirm whether the shared platform hosts privileged accounts, interfaces, batch jobs, logs, or configuration that downstream reporting relies on. If auditors would need that platform’s records to trust a control, it belongs in the scope discussion.

Common mistake: Treating scope as an application inventory exercise. That approach misses central services, admin tooling, and platform controls that can have broader impact than the report-producing application itself.

Decision rule: If a shared system can affect data integrity, access control, or control evidence for any in-scope process, include it in SOX scoping and define the exact control dependency rather than excluding it by ownership or technology label.

Practitioner takeaway: For SOX, the right question is not “Who owns the infrastructure?” but “Could this infrastructure affect the reliability of financial reporting or the evidence used to prove it?”