Engagement Management, Scoping and Rules of Engagement
Engagement Management
The contract stack
Every engagement rests on three documents: the NDA (confidentiality both ways), the master services agreement (liability, insurance, indemnity), and the statement of work (the actual task, deliverables, timeline, and fee). The SOW is what defines your authority. Separately, the authorization to test letter names the client signatory, the in-scope assets, and the test window - it is the document you produce if law enforcement or a network defender challenges you mid-test.
Running the engagement
Competence in this domain is really about operational discipline: named points of contact on both sides, an escalation path for critical findings (who do you call at 02:00 when you find ransomware?), an agreed emergency stop procedure, a communication cadence, and deconfliction so the client's blue team knows your traffic is sanctioned. Track time and scope consumption; a scope creep discovered midway requires a written amendment, not a phone call.
Traps in exam questions
- Confusing the MSA (commercial terms) with the SOW (technical scope) - questions often ask which document authorizes a specific action.
- Assuming verbal approval is authorization. It is not.
- Assuming a signature dated today covers testing that started yesterday.
- Forgetting that third-party hosted assets (SaaS, shared hosting, cloud) need their own permission.
Rule of thumb
If an action is not written into the SOW or the rules of engagement, treat it as out of scope until you have written approval.
Worked example: mid-test you discover an undocumented /24 adjacent to the client's subnet. You do not scan it. You document the discovery, notify the client contact, and request a written scope amendment; only after the ROE is re-issued do you touch it.
Scoping and Rules of Engagement
Scope is an inventory, not an idea
A defensible scope lists assets precisely: CIDR ranges, exact FQDNs or explicitly bounded wildcards, application URLs, credentials, and source IPs to be allowlisted. Equally important is the exclusion list: third-party hosted services, production databases, partner networks, and anything the client cannot legally authorize you to test. Record whether the engagement is black box, grey box, or white box - this drives effort estimates and what a "finding" even means.
Rules of engagement content
The ROE converts scope into permitted behaviour: testing windows and time zones, allowed and forbidden techniques (denial of service, social engineering, physical access, data exfiltration), rate limits, whether destructive exploitation is permitted, how credentials may be used, how evidence is stored, and notification thresholds for critical findings.
Traps in exam questions
- Wildcard scope (
*.example.com) where some subdomains are hosted by a third party with no authorization. - Production vs staging confusion - the client says "test the app" and the candidate picks the production cluster.
- Source IP not allowlisted, so your scan trips a WAF and gets the engagement suspended.
- Time zone drift - a 22:00–06:00 window in the client's local time, not yours.
- Cloud provider policy: most CSPs permit testing of your own instances but prohibit attacking the provider's infrastructure, and some services require prior notification.
Rule of thumb
Explicit inclusion beats reasonable assumption. When scope is ambiguous, pause and confirm in writing; the cost of a delay is trivial compared with an out-of-scope incident.
Worked example: an acquired legacy domain resolves to a marketing vendor's CDN. The client owns the brand, not the infrastructure. Testing it is out of scope even though the name is on the target list.