Scope a disclosure policy by naming at least one internet facing production system, then widening it on a fixed schedule. CISA's BOD 20-01 requires one system at launch, more after 270 days, additions at least every 90 days after that, and every internet facing system within two years.
Why staged scope works
A policy that covers everything on day one can swamp a small team. A policy that covers nothing real is pointless. Staging lets you build capacity: you learn how reports look, fix issues, and then open more doors.
The federal schedule as a model
BOD 20-01 sets the timetable for agencies:
- At publication, at least one internet accessible production system or service is in scope. Broad categories are encouraged, such as every system within a given domain.
- Newly launched internet accessible systems must be added to scope.
- By 270 calendar days after issuance, scope must grow by at least one system or service, and at least every 90 days after that.
- By two years after issuance, all internet accessible systems and services must be in scope.
Private companies are not bound by this, but the pattern is sensible.
Writing your first scope
- List internet facing systems. Include marketing site, app, API, documentation, mobile apps and any subdomains.
- Pick the first one or two. Choose systems you understand well and can patch fast.
- Describe them exactly. Domain names, app names, versions. Avoid vague words like "our platform".
- List exclusions. Third party services you do not control, staging data of customers, physical locations.
- State testing rules. Which techniques are allowed, which are not. Prohibit actions such as denial of service and accessing other users' data beyond what is needed to prove the issue.
- Say what to do with out of scope reports. CISA's handling guidance asks agencies to define how out of scope reports are handled. You can accept them anyway or point researchers to the right owner.
Keep a growth calendar
Add a recurring task, every quarter, to review scope. Questions:
- Did we launch anything new?
- Did we retire anything?
- Which areas generated the most useful reports?
- Are we fixing reports fast enough to add more?
Update the policy date and keep a change history. BOD 20-01 asks for an issuance date and recommends a descriptive change history with links to prior versions.
Third party and supplier systems
Your scope should say what you do not control. If a report concerns a supplier's product, forward it or tell the reporter to contact the supplier, and tell them you will do the same. Your own dependency inventory helps here, because knowing which components you ship tells you which upstream maintainers to notify.
Quick check
Should internal systems be in scope?
Usually not at first. Start with internet facing production systems, which is also what the federal schedule does.
What if a researcher finds something out of scope?
Decide in advance. Many teams still read and thank them, then route the report. A rule of thumb is to treat the researcher well even when the target is not yours.
Safeguard's asset discovery can help build the list of internet facing systems to scope.
Sources
Last reviewed: 19 October 2026.
