Overview
Just as important as what is in scope is what is excluded — systems and actions explicitly forbidden. Exclusions protect fragile or off-limits assets from testing. This lesson covers exclusions in the ROE.
Learning objectives
- Explain the purpose of exclusions.
- Identify commonly excluded systems and actions.
- Connect exclusions to safety and trust.
Core concept
Exclusions are systems, assets, or techniques explicitly declared off-limits, even if otherwise reachable. Common exclusions include: fragile production systems that could be disrupted, third-party services the owner cannot authorize, systems with sensitive/regulated data, and certain techniques (e.g. destructive tests, denial-of-service, social engineering) that the owner does not permit. Exclusions ensure that testing avoids areas where the impact or authority is unacceptable.
How it works
Exclusions are agreed in writing and honored absolutely. If an excluded system is reachable during testing, the tester does not touch it. Exclusions frequently protect third-party assets (which the owner has no authority to let you test), critical production systems (where disruption is unacceptable), and out-of-bounds techniques (like DoS, which risks outages, or social engineering, which involves people and legal sensitivities). Respecting exclusions is as binding as respecting scope — crossing an exclusion is a serious breach even within an authorized engagement.
Practical example
An ROE excludes the production payment system, any third-party APIs the application integrates with, and denial-of-service techniques. During testing, the tester discovers the app calls a third-party service — which is excluded — so they do not test it. They also avoid any action that could disrupt the production payment system and never attempt DoS. The exclusions kept high-risk and unauthorized areas untouched, protecting the owner and third parties.
Cybersecurity relevance
Exclusions are critical for safety and legality: testing a third-party system the owner cannot authorize is unauthorized access against that third party; disrupting fragile production systems causes real harm; prohibited techniques (DoS, social engineering) carry outsized risk and legal sensitivity. Honoring exclusions protects the owner, third parties, and the tester, and preserves trust. Together with targets, exclusions precisely bound the engagement — a core professional discipline in offensive security.
Common mistakes
- Testing an excluded system because it is reachable or connected to an in-scope target.
- Using prohibited techniques (DoS, social engineering, destructive tests) despite exclusions.
- Touching third-party assets the owner has no authority to authorize.
Key takeaways
- Exclusions are systems, assets, or techniques explicitly forbidden, even if reachable — often fragile production systems, third-party services, and high-risk techniques (DoS, social engineering).
- They protect against unacceptable impact and unauthorized action (e.g. against third parties the owner cannot authorize).
- Honoring exclusions is as binding as respecting scope; crossing one is a serious breach even within an authorized engagement.
Check your understanding
- Why are third-party services commonly excluded, and what is the risk of testing them anyway?
- Name two techniques that are often excluded and why.