The set of systems that must be covered by controls, evidence, and testing for Sarbanes-Oxley purposes. In identity governance, this list defines the real compliance boundary, which may be broader than the set of applications already onboarded into the IGA platform.
What the SOX-in-scope application list actually defines
The SOX-in-scope application list is the practical boundary for Sarbanes-Oxley testing, evidence, and control coverage. It is not just a register of what sits in the identity governance tool, it is the set of applications that matter to financial reporting control and audit readiness, including systems that may be connected indirectly to those processes.
That distinction matters because sox scope is driven by business impact and control reliance, not by platform onboarding status. A system can be relevant to SOX even if it is poorly documented, lightly integrated, or outside the normal application catalogue. In practice, the list becomes the source of truth for which systems need access reviews, change evidence, and other control proofs.
Why SOX scope and IGA scope are not always the same
Identity governance platforms often reflect operational onboarding, but SOX scope is an assurance construct. An application may fall inside SOX because it supports financial close, reporting, journal entry approval, segregation of duties, or another control dependency, even if it has not yet been fully rationalised in the IGA estate.
This is why the application list should be treated as a compliance boundary, not a tooling boundary. If teams equate “onboarded in IGA” with “in scope for SOX,” they can miss systems that still require review, attestation, or evidence collection. The result is usually a gap between control design and control execution.
How organisations use the list during controls and audit work
The list helps determine which applications need control ownership, which access paths require recertification, and where testing must be performed. It also supports audit planning, because evidence requests are easier to satisfy when the in-scope population is explicit and agreed with finance, IT, and control owners.
For that reason, scope maintenance is a governance activity as much as a documentation task. A useful list normally records why each system is in scope, what business process it supports, and what control dependencies make it relevant. That context helps separate core financial systems from adjacent platforms that are merely connected to them.
Where applications support sensitive workflows or privileged access, the list should also reflect control mechanisms such as segregation of duties and access governance. NHIMG’s Segregation of Duties (SoD) Guide is useful here because SoD conflicts often help determine whether a system belongs inside the SOX boundary.
What good SOX scoping practice looks like
Good scoping is iterative. Organisations usually refine the list as they discover new integrations, shared services, report dependencies, or manual workarounds that affect financial reporting controls. The list should therefore be reviewed whenever systems change, control ownership moves, or the business adopts new applications that touch reporting or approval flows.
Strong teams also maintain traceability between the SOX list, the control matrix, and the evidence plan. That lets auditors and control owners see not only which systems are in scope, but why they are in scope and what tests apply. NHIMG’s SOX IT General Controls (ITGC) Guide is a practical reference for how scoping, access control, change control, and evidence fit together.
For broader regulatory mapping, NHIMG’s Identity Security Regulatory Map helps situate SOX alongside other compliance regimes that also depend on sound access and governance controls.
Risk and Threat Considerations
When the SOX-in-scope list is incomplete, outdated, or too narrow, the organisation can test the wrong population and leave financial-reporting systems outside assurance. That creates both audit risk and operational exposure, because control failures may go unnoticed in systems that still affect reporting integrity.
Failure mechanism: Scope drift happens when application ownership, integrations, or business usage change faster than the SOX inventory and control matrix are updated, so evidence and testing no longer reflect the real boundary.
Impact: Missing in-scope systems can lead to incomplete access review coverage, untested change paths, weak segregation of duties enforcement, and audit findings that point to control design or control execution failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | SOX scoping depends on defining which systems must be assessed and tested for control coverage. |
| AU-6 — Audit Record Review, Analysis, and Reporting | SOX evidence relies on auditability and review of records from systems in scope. | |
| AC-6 — Least Privilege | SOX scope often includes systems where excessive access can affect financial control integrity. | |
| Recommendation — Define the in-scope application set before planning control assessments and evidence sampling. Review audit records from every in-scope application to support SOX testing and issue investigation. Limit privileged access in scoped applications to the minimum needed for financial reporting tasks. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | SOX scope depends on knowing which applications and related assets exist and matter to controls. |
| A.5.15 — Access control | SOX in-scope systems require governed access decisions because access can affect reporting controls. | |
| Recommendation — Maintain an asset inventory that distinguishes SOX-scoped applications from the wider application estate. Apply access control rules consistently across applications that fall inside SOX scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | SOX scope is operationally enforced through governed accounts and access reviews in covered systems. |
| Recommendation — Manage accounts in scoped applications with explicit ownership, review, and removal processes. | ||
| OWASP ASVS | V8 — Authorization | Applications in SOX scope often need strong authorization rules to protect reporting-relevant functions. |
| Recommendation — Verify authorization boundaries in in-scope applications that can affect financial reporting. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | APIs behind in-scope applications can bypass intended control boundaries if function-level access is weak. |
| Recommendation — Test function-level authorization on APIs used by SOX-scoped applications. | ||
Practitioner Guidance
Why practitioners should care: The SOX list is one of the few artefacts that directly connects technical inventory to audit defensibility. If it is wrong, every downstream control step, from access review to evidence sampling, can be mis-scoped.
Governance implication: Treat ownership of the list as a shared finance, IT, and control function, not as an IGA-only administrative task. The real question is whether the application influences financial reporting controls, not whether it has already been onboarded into a workflow tool.
Practitioner takeaway: Keep the list versioned, justified, and reviewed on a change-driven cadence so scope decisions stay aligned to the current control environment.
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 teams scope application penetration tests for modern cloud and AI-enabled systems?
- How should security teams scope web application testing to avoid blind spots without wasting effort?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org