Scope should include every system that stores, processes or can reach sensitive data, plus the software components inside them and the tools that build and deploy them. Where scanners cannot reach something, list it and cover it another way, such as manual review. An unlisted system is an unmanaged one.
Why scope is where programs fail
Most programs fail on what they never looked at, not on what they looked at badly. A forgotten test server, a vendor-run portal, a build agent or an old container image can hold the flaw that matters.
New York's financial services rule is explicit on one point: automated scans plus a manual review of systems not covered by such scans. It also lists asset inventory, device management and end of life management among the areas the main cybersecurity policy must address. NIST's patch management guide says to maintain close-to-comprehensive software inventories using automation, and warns that monthly or quarterly scan-based inventories are no longer adequate.
Layers to consider
| Layer | Examples | Typical method |
|---|---|---|
| Source code | Repositories, infrastructure as code | Static analysis, review |
| Dependencies | Libraries, packages, transitive components | Composition scanning, SBOM |
| Build and release | CI runners, plugins, registries | Configuration review, access control |
| Containers | Images, base images, orchestrator config | Image scanning, config checks |
| Hosts | Servers, VMs, endpoints | Agent or authenticated scanning |
| Networks | Firewalls, gateways, remote access | Configuration and patch review |
| Exposed apps and APIs | Public sites and endpoints | Dynamic testing |
| Vendor-run services | SaaS platforms | Oversight, not scanning |
| Unscannable assets | Legacy and specialized devices | Manual review, isolation |
Build the scope list
- Start from the inventory. Include owner, environment, data sensitivity and exposure.
- Add discovery. Compare the inventory with what is actually running, using cloud APIs, network discovery and repository search. Anything found that is not listed is a gap to close.
- Tag each item with the method that covers it. If the method is manual, name the reviewer and frequency.
- Record exclusions with reasons, approver and review date.
- Review the list on a schedule and after material changes.
NIST also notes that vulnerability scans used for inventories need sufficient access, meaning authenticated scanning, to detect changes to software on the asset.
Developer-side scope people forget
- Developer laptops and the tools on them.
- Editor extensions and plugins.
- CI plugins and build scripts.
- Package registries and mirrors.
- Test and staging environments that hold copies of production data.
A compromise here reaches production through the pipeline, so include it.
Document exclusions honestly
Scope documents often say "all systems" while practice covers half. Write what is actually covered and what is not. It is easier to defend a stated gap with a plan than an overbroad claim that crumbles under sampling.
Where tooling helps
Safeguard offers asset discovery to find repositories, services and components you may not have listed, and SBOM and dependency scanning to cover the software inside them. Review the output against your own records, since no tool knows your whole business.
Quick check
Should test environments be in scope?
Yes, especially if they hold copies of real data or connect to production. At minimum, scan them at a lower cadence and keep them off the public internet.
How often should the scope list be reviewed?
Set a regular cadence, such as quarterly, plus a review after material changes like migrations, acquisitions or new vendors.
Sources
- 23 NYCRR 500.5, Vulnerability management
- 23 NYCRR 500.3, Cybersecurity policy
- NIST SP 800-40 Rev. 4, section 3.2
Last reviewed: 19 October 2026.
