Planning & RoE — Concepts

You know how to attack a machine in your lab. Now we step into the real world: the one where the client pays you to attack theirs. Between the two, there is a piece of paper. Without that paper, your career ends after the first scan.

The rule that overrides all the others

A pentest without written authorization is a computer intrusion. It is a criminal offense in every developed jurisdiction. Not "it depends." Not "if I am careful." An offense. The paper exists for that one reason: it turns your attack into a service that was ordered.

What you will be able to do after this lesson

• Name the five contractual pieces of a pentest engagement.
• Tell scope, RoE, SOW, and master service agreement apart — four documents 90% of beginners confuse.
• Draft a scope that stands up before a lawyer and before your technical team.
• Anticipate the cases where the client itself has no right to authorize the attack (SaaS, shared hosting, monitored employees).
• Know what to do when, mid-engagement, you find evidence of a preexisting intrusion (it happens more often than people think).

---

1. The real boss of a pentest: the lawyers

On paper, the client is your boss. In reality, whoever decides where you are allowed to press is the legal counsel. A junior pentester who does not grasp this ends up in one of two situations:

• They sign something vague, do what they think is useful, step outside the scope, the client complains, the contract was not precise enough, nobody is protected.
• They refuse anything that is not in the RoE — even an obvious test — because the RoE is the law. That second posture is the one you adopt. Always.

Remember the single rule: what is not written down does not exist. An oral agreement does not survive an incident. An unsigned email does not either.

---

2. The five contractual pieces

A complete engagement carries five documents. They do not serve the same purpose, and you must not mix them up.

Document	Role	Who drafts it
NDA (Non-Disclosure Agreement)	Binds you to secrecy. Signed before even discussing scope.	Client (usually), signed by both sides.
SOW (Statement of Work)	What we do, for how much, over how many days. The contracted quote.	You (the service provider).
RoE (Rules of Engagement)	How we do it: technical scope, windows, escalation paths.	You, validated by the client.
Letter of authorization	The proof to show if a third party challenges you (cloud provider, MSSP).	Client, printed, signed.
Master service agreement	Liability, insurance, applicable law.	Legal counsel on both sides.

The RoE is your day-to-day working document. The others run in the background, but they all must exist before you launch nmap.

Definition — the color of the box, or three ways to start an engagement

The RoE fixes how much information the client gives you before you begin. Three postures have settled in, and each one completely changes how the engagement runs.

In black-box, the client hands you only a scope — an IP, a domain name, a URL — and nothing else. This most closely mirrors a real attacker who has picked a target but knows nothing of the inside. It demands more time on reconnaissance and costs the client more per person-day.

In grey-box, the client provides one or more legitimate user accounts, possibly a rough description of the architecture. This is the best value-for-money for most application engagements: you skip the external reconnaissance box to go straight to where the real flaws hide, inside the authenticated portions of the application.

In white-box or crystal-box, the client hands over source code, architecture diagrams, operating procedures, sometimes even an administrative account. The test becomes a design review assisted by attack. This is what you pick for a piece of software before it ships, or to validate a new production architecture.

An experienced pentester knows how to recommend the right color: black-box to reassure a regulator, grey-box to cover the broadest surface, white-box for a critical component where the smallest flaw would carry heavy consequences.

---

3. RoE: what absolutely has to be in it

A minimal RoE, the one nobody argues with, has eight sections. If one is missing, refuse to start.

3.1. Scope — the map of the battlefield

The scope is never "the client's infrastructure." It is:

• A list of IP addresses or CIDR ranges. For example: 203.0.113.0/28, 198.51.100.42.
• A list of domain names and subdomains. For example: www.client.com, api.client.com. Anything not listed is out of bounds, even if you find it.
• A list of applications. Web, mobile, API, SCADA systems. Each with its version.
• Test accounts provided by the client (username/password for a grey-box or white-box pentest).
• Explicit exclusions. The CEO's printer, the payroll server, the aging AS/400 that has been running since 1998 and nobody dares turn off.

The classic trap

A client hands you "their domain client.com." You scan mail.client.com — but that subdomain actually points to Google Workspace. Google never authorized you. You just scanned a third party's infrastructure. That is illegal. Filter the subdomains and verify DNS ownership before any scan.

Definition — CIDR notation, that slash after the IP

An IPv4 address like 203.0.113.42 designates a single machine. A range — a set of contiguous addresses — is written with CIDR notation, from the Classless Inter-Domain Routing specification published in 1993. The form is network/prefix: 203.0.113.0/28.

The number after the slash tells you how many bits, on the left, belong to the common network part; the remaining bits form the host part that varies. With /28, twenty-eight bits are fixed and four bits vary — that gives sixteen addresses in total, two of which cannot be used as hosts (the network address and the broadcast address). With /24, twenty-four bits are fixed and eight vary — two hundred fifty-six addresses, often called "a class C" by old-school admins. With /16, sixteen bits vary — sixty-five thousand five hundred thirty-six addresses, the classic size of a medium enterprise network.

For a pentester, CIDR notation is indispensable in the RoE, to avoid two mistakes: listing twenty addresses by hand when /28 states the whole range, and confusing /24 with /32. A /32 range designates a single address — the CIDR equivalent of an isolated IP. Always check the prefix before launching a scan: nmap -sS 203.0.113.0/24 scans two hundred fifty-six hosts, nmap -sS 203.0.113.0/16 scans sixty-five thousand, and if your RoE covered only the first /24 you just overstepped the scope.

3.2. Permitted and prohibited techniques

You list what you may do, and what you may not. Examples of typical sections:

Technique	Allowed?	Detail
Active port scanning	Yes	Outside business hours.
Exploitation of vulnerabilities found	Yes	Without writing to production databases.
Privilege escalation	Yes	No persistent account creation.
Email social engineering (phishing)	Yes	On a provided employee list, no more than 3 waves.
Voice social engineering (vishing)	No	—
Denial of service	No	Never in production.
Physical test (office penetration)	No	Planned for a phase 2.
Authentication attacks	Yes	Max 3 attempts per account to avoid lockouts.

Every No can spare your client an incident. Every poorly framed Yes can create one.

3.3. Intervention windows

Never "during the day." Always precise timestamps, with time zone:

- Noisy scan:    Sat. March 15, 10:00 PM → Sun. March 16, 6:00 AM (UTC-05:00)
- Exploitation:  Week of March 17, 9:00 AM → 6:00 PM (UTC-05:00)
- Phishing:      Wed. March 19, send between 9:00 AM and 11:00 AM (UTC-05:00)

A scan that overruns by an hour into business hours and takes down a server can be argued in court. A scan that overruns and was not in the authorized window has to be paid for.

3.4. Escalation contacts

Three people, minimum, in the RoE:

• The operational point of contact on the client side. Answers technical questions, reachable 9-to-5.
• The emergency escalation point. Reachable 24/7 during the test window. Personal mobile, not a switchboard.
• Your engagement lead on the provider side.

Numbers. Emails. The RoE says exactly who to call when something goes wrong.

3.5. Handling critical findings

"If you find a critical flaw mid-test, what do you do?"

Typical answer:

• Exploitable critical vulnerability in production: stop exploitation immediately, notify the escalation contact within 2 hours, continue the test on other axes.
• Evidence of a preexisting intrusion (the client has already been hacked): full stop, notification within 1 hour, preserve indicators. This is a response case, not a pentest.
• Personal data leak identified: immediate notification, GDPR / Law 25 provisions on reporting to the authority.

These cases are written down in advance. On the day they happen, you are not in the mood to negotiate.

Definition — incident response, what a pentester must not improvise

Incident response, or DFIR for Digital Forensics and Incident Response, is a different profession from pentesting, with opposite rules. The pentester tries to leave no trace, the incident responder tries to preserve every trace. The pentester can rerun an exploit two or three times to verify, the incident responder must freeze the system's state at first access, because every command they run overwrites RAM and modifies disk timestamps.

If during your pentest you discover signs of a prior compromise — a svchost.exe file in a user folder, a scheduled task that pings a .onion domain every hour, a process listening on an undeclared port — the rule is simple. You stop everything. You touch nothing: not the file, not the process, not the logs. You call your escalation contact within the hour. You document what you saw, with the exact time, without having altered its metadata.

The client will then trigger a DFIR team — their own, or an external one. That team will pick up the case with its own tools: disk imaging, memory capture, artifact preservation. Your role stops at the notification. Any further exploration on your part destroys evidence that would have helped identify the attacker, measure the real impact, and possibly bring legal action.

3.6. Evidence handling

Where do you store screenshots, logs, retrieved hashes?

• Evidence encryption: LUKS, VeraCrypt, separate disk.
• Naming: YYYY-MM-DD_client_<target>_<action>.ext.
• Retention period: 30, 60, or 90 days after delivering the report, then certified destruction.
• Return to the client on request, over an encrypted channel (Signal, Wire, or physical delivery of an encrypted USB key).

A pentester who leaves a hashdump on their unencrypted desktop is a pentester nobody calls back.

3.7. Legal and regulatory aspects

Depending on the jurisdiction:

• Canada / Quebec — Law 25. Any personal data touched during the pentest must be documented. The client must have anticipated a data processing agreement that covers the pentest provider.
• European Union — GDPR. Same, article 28. The provider is a processor, with a DPA (Data Processing Agreement).
• United States — CFAA. Computer Fraud and Abuse Act. Extremely broad. The RoE must state "authorized access" explicitly.
• PCI-DSS environments. Require an annual pentest. Strong constraints on who can lead it (ASV, PA-QSA qualifications).
• Healthcare environments — HIPAA (US), RSS (Canada). Additional logging constraints.

If your client is on SaaS (AWS, Azure, GCP), check the provider's policy. AWS no longer requires prior notification for most tests since 2019; Azure still requires a declaration; GCP asks for an agreement. Look at the current documentation at the time of the engagement, not this course.

Definition — the DPA, the contract that follows every set of personal data

A DPA — Data Processing Agreement — is the contract that governs relations between a controller (the client, who decides why and how personal data is processed) and a processor (you, the pentester, processing that data on behalf of the controller). The European GDPR mandates it under article 28; Quebec's Law 25 has required it since 2023; other jurisdictions have equivalents.

The DPA states minimum obligations, three of which concern you directly. It sets the purpose — a pentest, not resale of data or training of a model. It sets the duration — the time of the engagement plus the retention period for evidence. And it sets the security measures you must apply to the data: encryption of captures, certified destruction after the report is delivered, transfer only over encrypted channels.

Two practical points. You do not sign a new DPA per engagement: serious providers have a template DPA that the client accepts as is, or with a few amendments. And if you delegate all or part of the work to a subcontractor on your side — a freelancer helping for a week, a cloud service to store your evidence — you in turn must sign a DPA with them. The contract passes down the chain, from the client to the last link that will touch the data.

3.8. Deliverables and deadlines

What you turn in, and when:

• Executive report (2-3 pages).
• Full technical report (30-80 pages).
• Evidence files.
• Oral read-out session.

Each deliverable has a date, a format, a recipient.

---

4. The edge case that leaves the client exposed: subcontracting

The client hires you to pentest their ERP. The ERP runs on a VPS hosted at OVH. Do you have the right to attack the VPS?

It depends on the contract between the client and OVH. Some providers forbid penetration tests without prior notification. Others allow them without asking. It is up to the client to check — but it is you whose connection gets cut and who receives an abuse email if nobody has done the work.

Add a standard clause to your RoE:

"The client warrants that it holds the necessary rights to authorize the tests described, including from its hosting providers and managed service providers. Any complaint or blocking action by a third party falls under the client's responsibility."

That sentence is coverage. It will not be enough if the client knowingly lies to you, but it puts you on the right side of the story.

---

5. Red flags to spot before signing

Refuse the engagement, or renegotiate, if you see:

• A client who will not provide a 24/7 escalation contact. They are not taking the engagement seriously.
• An RoE from the client shorter than one page. They think an RoE is a formality. You will pay the price.
• An explicit request to test systems that belong to a third party. That is the client's problem to sort out, not yours.
• A client who insists that you "try to break in by surprise, without warning anyone." That is red team territory — it has its own heavier framing, not a pentest's.
• A very short engagement (2 days) on a very large target (an entire domain). You will not have time to do useful work; the client will complain about the report; nobody wins.

Definition — scope creep, the sneaky enemy of a well-framed pentest

Scope creep refers to the gradual expansion of the engagement beyond what was signed. It rarely takes the form of an explicit decision; it advances through small requests that each seem harmless.

The typical scenario unfolds in four steps. The client asks, on day two, whether "while you are at it" you could take a look at server X, which is not in the RoE. You agree out of goodwill. On day three, another server is added. By day five, you have been out of scope for a long time, your schedule has blown up, your evidence gets muddled, and if an incident hits one of these added servers, nobody can prove it was authorized. You pay on three fronts: time, quality, legal exposure.

The counter is procedural. Every out-of-RoE request receives the same written answer: "Thank you for the request. I can cover this target through a written RoE extension countersigned by [contract contact]. Estimate: X additional days." The client officially adds the target, or backs off. No oral extension, no extension over an unsigned email, no "we will see later." This rigor shocks people at first, but it protects you every time in the end.

---

6. Common mistakes that cost

• Scope described orally, never written down. On the day of the dispute, you have nothing.
• No procedure for a preexisting intrusion. You walk into an already compromised infrastructure, you do not know what to do, you accidentally destroy evidence that would have served an investigation.
• No slack in the windows. An nmap -p- can take 4 hours over a 256-IP range. Plan 1.5× your estimate.
• Test accounts created inside the client's admin account, without a strong password. At the end of the engagement, they forget to delete them.
• Use of tools that phone home. Some commercial tools ship results to their cloud. The RoE may not have anticipated that exfiltration. Configure everything locally.

---

7. What to remember

• An RoE is not just another piece of paper. It is the only document that makes your work legal.
• NDA, SOW, RoE, letter of authorization, master service agreement: five documents, five roles. Do not confuse them.
• The scope is a list, not a sentence.
• Windows and contacts are written down to the minute and to the phone number.
• The "preexisting intrusion" case and the "critical finding" case are anticipated.
• The client can authorize you to attack only what belongs to them.

Next lesson: we take a real scenario (an e-commerce SMB), we draft a full RoE, and we have it reviewed.