Safeguard
Compliance•

VDP Scope and Out-of-Scope Lists: A Table a Small Team Can Maintain

A scope section that is too vague floods your inbox. One that is too narrow hides real bugs. Here is a practical in-scope and out-of-scope table, and how to keep it current.

Safeguard Security Team
3 min read

Article 14 of the EU Cyber Resilience Act has applied since 11 September 2026, and Article 13(6) already tells manufacturers what to do when they find a flaw in a component they ship: report it to whoever makes or maintains that component. The same logic applies to your inbox. Reports will arrive about your code, your dependencies and your vendors, and the scope section of your VDP decides which ones you own.

CISA's BOD 20-01 sets a useful rule for agencies: at least one internet-accessible production system must be in scope when the policy is published, and every newly launched system must be added. Private companies can borrow it.

What's affected

Any team writing or editing a VDP. A workable scope has three parts: what is in, what is out, and what you want to hear about anyway.

AssetTypical decisionReason
Production web app and APIIn scopeThe reason the policy exists
Mobile apps you publishIn scopeSame data, different client
Staging and test hostsIn scope only if internet facing and realOften forgotten and exposed
Open source libraries you maintainIn scope, via repository policyLink to its SECURITY.md
Third-party SaaS you useOut of scope, forward if askedYou cannot authorize testing
Your cloud providerOut of scopeFollow its own policy
Social engineering, phishing, physical accessOut of scopeTargets people
Denial of service and load testingOut of scopeHarms customers
Automated scanner output with no proofOut of scopeTriage cost, no signal

Say plainly that a report about out-of-scope assets is welcome. BOD 20-01 requires handling procedures for reports on out-of-scope systems, and the same discipline helps a small team: decide in advance who forwards them.

What to do now

  1. List every hostname you operate from DNS, not from memory. Compare it with the in-scope list.
  2. Write scope as exact names or a wildcard such as *.example.com, with explicit exceptions.
  3. Add a "known issues and non-issues" list: missing security headers on marketing pages, clickjacking on pages with no sensitive action, and version banners. Naming them cuts duplicates.
  4. Add a line telling reporters what to do on an out-of-scope find: report it anyway, and you will pass it to the vendor where you can.
  5. Review scope on every launch. Put it in the release checklist.

Quick check

Your VDP says "all our systems." Why is that a problem?

It authorizes testing of hosts you may not own, such as vendor-run subdomains, and it gives you no way to say no. Name the assets and list the exceptions.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.