Overview
Programs explicitly list exclusions — assets and activities that are forbidden even if otherwise reachable. Respecting exclusions is as important as respecting the in-scope list. This lesson covers exclusions.
Learning objectives
- Define exclusions in a program policy.
- Identify commonly excluded assets and issues.
- Respect exclusions strictly.
Core concept
Exclusions are the assets, systems, or issue types a program declares out of scope / forbidden, even within a broad in-scope wildcard. Common exclusions include: specific subdomains or systems (e.g. legacy.example.com), third-party services the organization cannot authorize, fragile/production systems, and certain vulnerability types or activities the program does not accept or forbids testing (e.g. DoS, social engineering, or issues they consider out-of-scope). Exclusions carve out forbidden areas from the authorized surface; testing them is unauthorized.
How it works
The researcher reads exclusions alongside the in-scope list and treats them as hard boundaries. Even if a broad wildcard would otherwise include an asset, an explicit exclusion removes it — so a discovered subdomain that is excluded must not be tested. Third-party services are commonly excluded because the organization has no authority to authorize testing them (testing them would be unauthorized against the third party). Some programs also exclude certain issue types as accepted risks or known issues. The researcher verifies each target/issue against the exclusions before proceeding, avoiding forbidden areas entirely.
Practical example
A program's scope is *.example.com but excludes legacy.example.com, all third-party services, and issues like clickjacking on non-sensitive pages. Enumerating subdomains, the researcher finds legacy.example.com and a third-party analytics service. They do not test either — both are explicitly excluded (and testing the third party would be unauthorized against it). They also don't report the excluded issue type. Respecting the exclusions kept testing within authorization despite the broad wildcard.
Cybersecurity relevance
Exclusions are critical to legal, safe participation: testing an excluded asset — especially a third-party service the organization cannot authorize — is unauthorized access and a serious violation, and testing fragile systems can cause harm. Exclusions also set expectations about which issue types are accepted. Ignoring exclusions is a common cause of program bans and legal trouble. Respecting them strictly — treating them as hard boundaries that override even broad in-scope wildcards — is essential discipline, mirroring the exclusions concept from the ethical-hacking rules-of-engagement module.
Common mistakes
- Testing an excluded asset because a broad wildcard seemed to include it.
- Testing third-party services the organization cannot authorize.
- Reporting excluded issue types the program does not accept.
Key takeaways
- Exclusions are assets, systems, or issue types a program forbids even within a broad in-scope wildcard — hard boundaries that override the in-scope list.
- Common exclusions: specific subdomains/systems, third-party services (unauthorizable), fragile systems, and certain issue types.
- Respecting exclusions strictly is essential to legal, safe participation; testing excluded/third-party assets is unauthorized and a common cause of bans/legal issues.
Check your understanding
- Why are third-party services commonly excluded, and what is the risk of testing them?
- How do exclusions interact with a broad in-scope wildcard?