This guide helps you decide what systems, processes, and boundaries should be included in a security test. It is intended to move scope definition away from asset lists and toward realistic exposure and impact.
How organizations typically get this wrong
Defining scope around system ownership rather than attacker movement. Excluding identity providers, third-party integrations, or shared services because they are “out of scope.” Treating scope as a contractual checkbox instead of a risk decision. Reusing last year’s scope with minimal review.
How penetration testing fits
Penetration testing evaluates specific systems or applications within a defined scope. It is best used when the goal is to validate technical controls or identify exploitable weaknesses.
How attack simulations and red teaming differ
These approaches test how the organization responds to realistic attack paths that span people, process, and technology. The emphasis is on exposure and response, not individual findings.
Choosing the right approach
The right choice depends on readiness, clarity of ownership, and how results will be used. In many cases, starting smaller produces more useful outcomes.