Treat the report on its merits, thank the researcher, and then decide whether to fix it and whether your scope is wrong. A serious flaw does not become safe because your policy did not list that system. Reply kindly and do not punish good faith reporting.
Why this happens
Scope lists age quickly. A company acquires a product, spins up a marketing site or leaves an old subdomain running, and nobody updates the policy. CISA's directive anticipates this: after a policy is published, newly launched internet-accessible systems must be added to scope, and the policy must be updated explicitly if its wording does not already include them. It also says the policy should ultimately cover all internet-accessible systems, including those that were not intentionally made internet-accessible.
The directive's FAQ also notes that a person could be acting in good faith when reporting on systems outside scope if discovery was accidental or incidental to authorized testing on in-scope systems.
Decision steps
- Check who owns the asset. Is it yours, a subsidiary's, or a vendor's?
- Check the effect. Does it expose customer data, credentials or a path into in-scope systems?
- Reproduce safely in an isolated copy where possible.
- Decide the fix. If you own it, fix it. If a vendor owns it, forward the report to them.
- Reply to the researcher with an honest message.
- Update the policy if the asset should have been covered.
Three common situations
| Situation | Suggested response |
|---|---|
| Your own forgotten asset | Fix it, thank the researcher, add the asset to scope |
| A third party's system | Tell the researcher you cannot fix it, offer to forward it, and warn them gently about testing others' systems |
| A system that is explicitly excluded for a reason | Explain the reason, still review the finding, and decline any reward |
What to say
Be specific and warm. Something like: "This system is not listed in our scope, but we looked at it and found a real problem. Thank you. We are fixing it and have added the system to our scope." Do not say that the researcher was wrong to report it unless they caused real harm.
Safe harbor questions
Whether to extend any protections to out-of-scope testing is a decision for your counsel, not this post. The directive's guidance on good faith can help you think about intent, but your policy wording and legal advice decide how you respond to testing outside the rules. See what safe harbor means in a disclosure policy.
Fix the gap
After the case closes, ask why the asset was missing. Maybe your asset inventory is incomplete. Safeguard's asset discovery can help find forgotten internet-facing assets, and scoping can then start from a real list. A free scan also checks your dependencies.
Starting small is fine. Our guide on starting small and expanding VDP scope explains how to grow it.
Quick check
Should I pay a bounty for an out-of-scope bug?
That is your call under your own rules. Many programs decline rewards for out-of-scope findings but still fix the issue and say thanks.
Should I tell the researcher not to report this kind of thing again?
Better to update the scope and invite them to keep testing in scope. Discouraging reports teaches people to stay quiet.
Sources
Last reviewed: 19 October 2026.
