The set of applications, users, entitlements, and evidence that must be included to satisfy Sarbanes-Oxley control testing. In identity governance, scope is not just a system inventory. It is the boundary that determines whether access controls can be proven for financially relevant risk.
What SOX Scope Includes
SOX scope is the boundary that determines which applications, users, entitlements, and evidence are in play for Sarbanes-Oxley control testing. For identity governance, it is the line between what is merely operational and what must be provably controlled for financially relevant reporting.
That boundary is usually broader than a simple system list. It should reflect where access can affect financial data, approvals, journal entries, reporting workflows, supporting platforms, and the evidence needed to show those controls are actually working.
Why Scope Matters for SOX Testing
Scope drives what auditors and control owners can reasonably test, what must be reviewed, and where evidence has to be retained. If the boundary is too narrow, important access paths can fall outside testing even though they can influence financial reporting.
Scope decisions also shape how identity teams think about inherited access, indirect access, and supporting systems. A payroll engine, an ERP module, or a workflow tool may be operationally ordinary, but still be in scope if it can change a financially relevant process or data set.
Identity, Entitlements, and Evidence Boundaries
In identity governance, SOX scope is not just about the application owner naming a system. It also covers who has access, what entitlements exist, how those entitlements are approved, and what evidence proves the access is appropriate and monitored.
This is why scope often extends into role design, segregation of duties, privileged access, and recertification evidence. The question is not only whether a system stores financial data, but whether its access model can introduce unauthorized change, concealment, or override of controls.
For a useful control map, the Identity Security Regulatory Map shows how identity controls connect to SOX and related compliance regimes.
How Teams Define a Practical SOX Boundary
A practical SOX boundary starts with processes and data that can affect financial reporting, then works outward to supporting systems, identities, and control evidence. That usually means including not only the primary finance application, but also adjacent administration tools, integrated services, and the access reviewers who approve or attest to control operation.
Scope should be specific enough that control owners know what to test and what evidence to produce, but not so narrow that it ignores dependencies that can change the financial outcome. A good boundary makes audit testing repeatable, supports timely access review, and keeps control coverage aligned to actual reporting risk.
For teams building the access side of that boundary, the Authorisation Models Guide is useful when access decisions need to be tied to roles, attributes, or policies rather than informal exceptions. The Segregation of Duties (SoD) Guide is equally relevant where SOX scope must include toxic combinations and compensating controls. For broader access governance, the Privileged Access Management Guide helps when privileged accounts are part of the control perimeter.
Risk and Threat Considerations
SOX scope creates risk when the boundary is incomplete, inconsistent, or outdated. If a system, entitlement set, or support workflow is missed, the organisation may believe a control is operating over the full financial process when it only covers part of it.
Failure mechanism: scope drift, hidden integrations, overbroad privileged access, or incomplete evidence chains can leave financially relevant change paths outside testing while still affecting reporting integrity.
Impact: That can produce control gaps, failed testing, remedial audit findings, delayed sign-off, or a false sense of assurance over access controls that are not actually complete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | SOX scope depends on governing identities, entitlements, and access evidence for financial systems. |
| Recommendation — Define the identity boundary for in-scope financial systems and verify access review evidence end to end. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | SOX scope must include which accounts and entitlements can affect financially relevant processes. |
| AC-6 — Least Privilege | SOX scope is materially shaped by privileged access that can alter financial controls or reporting data. | |
| Recommendation — Inventory and review in-scope accounts, then remove unused or unauthorized access promptly. Limit in-scope privileges to the minimum needed and review exceptions for compensating controls. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SOX scope defines which access paths and approvals are part of the control boundary. |
| A.8.3 — Information access restriction | SOX testing depends on restricting access to the systems and data that affect financial reporting. | |
| Recommendation — Apply access control rules consistently to all in-scope finance applications and supporting systems. Restrict access to in-scope information and evidence the restriction through review and approval. | ||
Practitioner Guidance
Governance implication: Treat SOX scope as a maintained control boundary, not a one-time inventory. Ownership should sit with both the business control owner and the identity or GRC function so changes to applications, entitlements, or integrations are evaluated for financial relevance as they occur.
What to watch for: New interfaces, emergency access, indirect admin rights, and access paths added after the last review often expand the real scope faster than documentation changes do. If the evidence trail cannot show who approved access, who reviewed it, and which process it supports, the scope definition is probably too weak.
Related resources from NHI Mgmt Group
- How should security teams run SOX access reviews across multiple in-scope systems?
- How do security teams know whether SOX scope is complete?
- How should security and compliance teams determine which Salesforce changes are in scope for SOX review?
- How should organisations scope IT systems for SOX compliance when financial reporting depends on shared infrastructure?