A scope review is the process of re-checking which systems, people, and services belong inside PCI DSS coverage after a change occurs. For identity teams, it should be tied to access recertification and offboarding so that the compliance boundary and actual access paths stay aligned.
Expanded Definition
Scope review is the disciplined re-validation of which systems, accounts, APIs, and third-party services remain inside PCI DSS coverage after an operational change. In NHI governance, that means checking whether machine identities, service accounts, and secret-bearing integrations still map to the compliance boundary, not just whether the diagram says they do. Definitions vary across vendors on whether scope review is a compliance activity, an identity control, or both, but the practical expectation is consistent: the control boundary must match real access paths. That alignment is especially important when service accounts are reused across environments, when secrets are embedded in automation, or when offboarding changes remove one dependency but leave another live. Guidance from the OWASP Non-Human Identity Top 10 reinforces that machine identities expand risk when they are not continuously inventoried and governed. The most common misapplication is treating scope review as an annual documentation exercise, which occurs when teams update policy diagrams without re-checking actual authentication and API access paths.
Examples and Use Cases
Implementing scope review rigorously often introduces coordination overhead, requiring organisations to weigh compliance certainty against the cost of reconciling access across infrastructure, IAM, and application owners.
- A payment application is moved to a new cloud account, and the team re-checks whether legacy service accounts, CI/CD tokens, and webhook secrets still touch cardholder data systems.
- An acquisition adds a new support platform, so identity teams verify whether federated access, API keys, and integration users now fall inside PCI DSS coverage.
- A privileged developer leaves the company, and offboarding triggers a scope review to confirm that related machine identities and automation credentials are no longer connected to in-scope assets.
- A secrets rotation program reveals shared credentials across environments, prompting a review of whether test, staging, or logging systems unexpectedly inherit production scope.
- NHIMG research on NHI risk highlights how weak visibility and poor offboarding make scope drift hard to detect; see Ultimate Guide to NHIs — Key Challenges and Risks alongside the OWASP Non-Human Identity Top 10 for the control implications.
Why It Matters in NHI Security
Scope review matters because NHI exposure often grows quietly after a change, not during the original implementation. A system can remain “out of scope” on paper while its service account still authenticates to production data, or while an automation token continues to reach a regulated workload. That disconnect weakens offboarding, access recertification, and incident containment at the same time. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes scope drift a persistent governance gap. The same research also shows 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which increases the chance that a boundary change leaves hidden access paths behind. In practice, scope review should be paired with entitlement review, secret inventory, and asset ownership so that changes in architecture do not silently create audit failures. Organisations typically encounter scope review as a critical control only after an audit exception, incident, or failed decommission reveals that access outlived the system it was meant to protect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Scope drift often starts with unmanaged service accounts and secrets. |
| NIST CSF 2.0 | PR.AA-01 | Identity inventory and access oversight support boundary validation. |
| PCI DSS v4.0 | PCI DSS requires organisations to keep the assessed cardholder-data scope accurate. |
Tie scope review to access recertification so active identities match in-scope assets.
