2.2
Rules of Engagement & Boundaries
The rules of engagement are your legal guardrails. The scope defines what you test. The RoE defines how you test it, and what happens if something goes wrong.
The RoE document is separate from the scope of work, and they cover different ground. The scope lists targets, timelines, and deliverables. The RoE covers authorization, prohibited actions, communication protocols, data handling, and incident response procedures. The two are not to be confused.
Key sections in every RoE document:
Authorization: Written confirmation that you are legally permitted to test. Without this, you’re committing a crime regardless of what the scope says.
Prohibited actions: What you are explicitly not allowed to do, even if you could. Denial of service testing, social engineering, physical access attempts. If it’s not in the RoE, assume it’s off limits. During testing, any irregularities should be discussed with the client so that you obtain written approval (email is enough).
Data handling: What do you do with sensitive data you encounter during testing? Client credentials, personal information, financial records. The RoE tells you how to handle it.
Communication protocols: How and when do you report issues. What constitutes an emergency versus a normal finding. Who you contact and through which channel.
You’re mid-engagement and hit a situation that’s not clearly covered by the documentation. The challenge on the right tests your judgment.
RoE Decision: Scope Ambiguity
multiple-choice
Scenario
During authorized exploitation of DC01, you exploit a Kerberos delegation misconfiguration and obtain a service account ticket. You discover that the same service account is also present on 10.1.1.50, a workstation you identified during host discovery. You could authenticate to 10.1.1.50 using this ticket. Per the RoE (TDSC-ROE-2026-001), all hosts other than DC01 are explicitly out of scope for exploitation and interaction. What do you do?
What is the most appropriate action?