Target Scoping & Rules of Engagement

Scoping LOW v1.0.0 updated 2026-06-17

Define the engagement scope, identify in-scope assets, review programme rules, and set up your testing environment before any active work begins.

Tools

Machine-readable JSON available at:

https://reconatlas.pages.dev/api/checklists/target-scoping

// checklist steps

scope-01

Read the programme policy

Thoroughly read the bug bounty or pentest programme policy, noting scope boundaries, exclusions, disclosure rules, and any testing restrictions.

curl -s https://target.com/.well-known/security.txt
curl -s https://target.com/security | grep -i 'scope\|bounty\|rules'

Screenshot or save the policy page with a timestamp. Programmes update rules without notice, and you need proof of what was in scope when you tested.

scope-02

Identify scope boundaries

List all in-scope domains, IP ranges, mobile applications, and API endpoints explicitly permitted by the programme.

echo 'target.com' > scope-domains.txt
echo '*.target.com' >> scope-domains.txt
echo '192.168.1.0/24' > scope-ips.txt

If the programme says "*.target.com", confirm whether third-party hosted subdomains (e.g. support.target.com on Zendesk) are included. When in doubt, ask the programme owner.

scope-03

Set up project structure and note-taking

Create a consistent directory structure and initialise your note-taking system so findings are organised from the start.

mkdir -p target-com/{recon,scans,vulns,screenshots,notes}
echo '# Target: target.com' > target-com/notes/engagement-log.md
echo 'Start date: $(date +%Y-%m-%d)' >> target-com/notes/engagement-log.md

Use a repeatable folder layout across engagements. Tools like Obsidian, Notion, or even plain Markdown files work well as long as you are consistent.

scope-04

Configure proxy and browser tooling

Set up Burp Suite or another intercepting proxy, install browser extensions, and verify traffic flows through your testing stack.

curl -x http://127.0.0.1:8080 -k https://target.com -o /dev/null -w '%{http_code}'

Ensure your proxy CA certificate is installed in the browser and system trust store. Test with a simple request before starting active work to avoid missing traffic.

scope-05

Verify safe harbour and legal protections

Confirm the programme offers safe harbour or authorisation language that protects you legally while testing within the defined scope.

curl -s https://target.com/.well-known/security.txt | grep -i 'policy\|contact\|hiring\|acknowledgment'

If the programme lacks explicit safe harbour language, consider requesting written authorisation before testing. Never test assets outside the stated scope regardless of what you discover.

Overview

Target scoping is the most overlooked phase in bug bounty and penetration testing. Skipping it leads to wasted effort on out-of-scope assets, duplicated reports, and — in the worst case — legal trouble from testing systems you were never authorised to touch.

Before you run a single scanner, invest time reading the programme rules, documenting exactly what is in scope, and setting up your environment so that every finding is captured cleanly.

What to look for

Pay close attention to:

Explicit exclusions (e.g. “do not test login brute-force”, “no DoS”)
Assets marked as out-of-scope even if they share the same root domain
Whether the programme accepts reports on third-party dependencies
Rate-limit or scan-frequency restrictions that could get you blocked

Setting up for success

A well-organised project directory and a configured proxy from day one will save you hours during reporting. Tag every finding with the date and the exact scope reference so triagers can verify your work quickly.

// references

← All checklists JSON ↗