Direct answer
A security testing scope states which targets, identities, methods, and conditions are authorized. Agree it with the responsible owner before active testing, including exclusions, data handling, availability limits, and a contact who can stop or clarify the assessment.
Define target and environment boundaries
List exact application origins, APIs, and environments rather than a broad brand name. Identify shared hosting, identity providers, payment services, and partner systems. A link or redirect from an approved page does not automatically bring its destination into scope.
- Record the owner and environment for each target.
- Mark production and staging separately.
- Keep explicit excluded origins and services in the test configuration.
Agree permitted techniques and limits
Rules of engagement connect assessment objectives with allowed methods, logistics, risk controls, and stop conditions. Choose request and concurrency limits, safe fixtures, and whether state changes are permitted. Use separate authorization for tests that could affect availability or external systems.
Reference: NIST SP 800-115: security assessment planning and rules of engagement.
Prepare roles and sensitive evidence handling
Supply the identities needed for the agreed boundaries: for example a viewer, administrator, and users in two test tenants. Decide how request tokens, screenshots, records, and reports will be protected and retained. Missing accounts should become a visible coverage limit rather than an assumed pass.
- Create dedicated test accounts and reversible fixture records.
- Define the secure report recipient and retention period.
- Record the escalation contact and pause procedure.
Keep scope current during discovery
Discovery may reveal an undocumented API or another service boundary. Record it and ask the owner to resolve scope before active checks. For a vulnerability disclosure or bounty program, use that program's written scope and reporting terms instead of treating general good intent as authorization.
Reference: OWASP Vulnerability Disclosure Cheat Sheet.
Assessment limits
This is an operational planning checklist, not a legal authorization template. The responsible parties must establish authority and applicable terms. Scope should be reviewed when the target, methods, provider constraints, or environment changes.
Frequently asked questions
Does owning a domain authorize testing every linked service?
No. Third-party destinations, shared infrastructure, and provider systems can have separate owners and terms. Identify and authorize each relevant boundary.
What should happen when a test needs a missing account?
Record the affected coverage as incomplete and obtain an appropriate fixture if possible. Do not count an unexercised role boundary as a passed check.
Can the scope change during an assessment?
Yes, when the responsible owner explicitly updates it. Record the change, permitted methods, and limits before performing the dependent active tests.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.