Planning & RoE — Guided walkthrough

One scenario. A small business. A project lead who does not know the field. We are going to draft, line by line, a full Rules of Engagement, pointing out where the client would trap you without meaning to.

The scenario

The client: Boutique Éclair, a Quebec e-commerce SMB, 45 employees, online store + mobile app + internal backoffice.

The request: "We would like a pentest on our whole estate. A competitor of ours got hacked last year, and we want to check we are fine."

The budget: 15 person-days.

You: freelancer or provider, about to sign.

This is exactly the moment when 90% of beginners say yes and start scanning. We will do the opposite: ask questions before we draft.

---

Step 1 — The scoping questionnaire

Before any RoE, a scoping meeting. Twelve questions, minimum. Here are the exact questions to ask Boutique Éclair, with their likely answers, and what changes in the RoE.

Q1 — "Where do you host each component?"

Client answer: "Our website is on Shopify. The mobile app hits an API we host on AWS Montreal. The backoffice runs in our offices, on an old server."

What changes:

• Shopify: cannot be pentested in the classical sense. You can only test what the client has deployed (custom themes, private apps). The rest belongs to Shopify.
• AWS Montreal: testing is authorized without prior notification for most services, but check the current AWS Customer Support policy at the time of the engagement.
• On-premises server: testing allowed, with the client's agreement on the windows so as not to disrupt operations.

In the RoE, we will therefore have three distinct scopes, each with a different regime.

Q2 — "Who owns the domain boutique-eclair.ca?"

Answer: "It sits with our webmaster; he bought the name in his own name."

What changes: the webmaster must also sign an agreement. Otherwise your attack on boutique-eclair.ca is not covered by the domain owner's authorization.

In the RoE, add a warranty clause that the client holds the rights on every listed asset.

Q3 — "What sensitive data flows through these systems?"

Answer: "Credit cards on the site, customer emails and addresses in the backoffice, and some medical data on a few employees (group insurance)."

What changes:

• Credit cards: PCI-DSS environment. Heavy constraints.
• Customer email addresses: personal data. Law 25 (Quebec) + GDPR if you touch European customers.
• Medical data: RSS. You do not touch it.

In the RoE, a complete legal section, and an explicit exclusion of the systems that store medical data.

Definition — PCI-DSS, what changes when payment cards come into play

PCI-DSS — Payment Card Industry Data Security Standard — is the framework imposed by the major card networks (Visa, Mastercard, American Express, Discover, JCB) on any merchant that accepts their payments. The version current at the time these lines are written is 4.0, with tighter requirements on logging, authentication, and access management.

Two requirements matter directly to the pentester. First: an external and internal penetration test at least once a year, or after every significant change to the card perimeter. That gives you a recurring mandate, provided you are qualified to run it. Second: strict segmentation between the cardholder data environment (CDE) and the rest of the network. The pentester must verify that segmentation holds — a full-fledged test of its own, called segmentation testing.

Three precautions in the RoE. You never test in production on real card data: cards are tokenized, or the environment is cloned with test data. You state the applicable PCI-DSS version in the preamble — the requirements moved noticeably between 3.2 and 4.0. And you confirm that the provider — you — holds one of the recognized qualifications: ASV for external scans, PCI Professional for compliance review, a certified pentester (OSCP, CREST, CPTS) for the test itself. Without an adequate qualification, the report has no weight in the face of an audit.

Q4 — "Is the pentest grey-box, black-box, white-box?"

Client answer: "What is that?"

You explain:

Approach	What the pentester gets from the client
Black-box	Nothing. They start like an external attacker who knows nothing.
Grey-box	A regular user account. They simulate a rogue employee or a compromised customer.
White-box	Everything: source code, admin accounts, architecture docs. Most efficient, often most useful.

A sensible client picks grey-box or white-box for their money. Black-box is expensive in reconnaissance time without necessarily delivering more. For Boutique Éclair, propose grey-box on the site and the API, white-box on the backoffice.

Q5 — "Can I attempt phishing against your employees?"

Answer: "Yes, except the CEO, he hates it."

What changes: exclusive list in the RoE, and a post-phishing procedure — an employee who clicks: will they be trained, disciplined, ignored? We write it down in advance.

Q6 — "What is your tolerance window for an incident?"

Answer: "The site must not go down during business hours. We can shut the backoffice on the weekend."

What changes: aggressive scans and stress tests are forbidden during business hours, allowed during weekend evenings and nights.

Q7 — Q12 (the rest)

7. "Who do you notify if we find an intrusion in progress?"
8. "How many hours do you have to answer a night call?"
9. "Can I create a persistent test account?"
10. "Can I exfiltrate demo data?"
11. "Where do we store the evidence during the engagement?"
12. "Does the report need to be delivered encrypted?"

Each answer spawns a line in the RoE.

---

Step 2 — The RoE drafted before your eyes

Here is the final RoE, section by section, with the notes an experienced pentester would slip in.

2.1. Header

Rules of Engagement — Boutique Éclair penetration test
Version 1.2 — Date: 2026-04-08
Provider: Cursor Security Inc., business number 1234567890
Client: Boutique Éclair Inc., business number 0987654321
Duration: 15 business days, between 2026-04-15 and 2026-05-06

A version number, a date. Every change bumps the number. The signed version is the only one that counts.

2.2. Technical scope

Scope — three distinct zones

Zone A — E-commerce site
  - Type: Shopify SaaS + custom theme + 2 private apps
  - Allowed techniques: test the private apps (grey-box, provided account),
    review the theme (white-box), test Shopify configuration (documentation).
  - Forbidden techniques: any active scan against Shopify IPs.
    Any exploitation outside the custom components.

Zone B — Mobile app API
  - Domain: api.boutique-eclair.ca
  - IPs: see Appendix A (5 AWS ca-central-1 elastic IPs)
  - Allowed techniques: active scan, exploitation, authentication testing.
  - Forbidden techniques: DoS, destructive injection into the database.
  - Regime: grey-box with 2 user accounts provided by the client.

Zone C — Internal backoffice
  - Domain: intranet.boutique-eclair.local (reachable via provided VPN)
  - IPs: 10.20.30.0/24
  - Allowed techniques: active scan, exploitation, privilege escalation,
    access to demo files.
  - Forbidden techniques: access to folders RH_medical/*, access to
    salary files.
  - Regime: white-box, source code available on the client's GitLab.

Cross-cutting exclusions
  - AS/400 server (10.20.30.99) — legacy critical machine, not tested.
  - Employee workstations — no client-side compromise.
  - Any infrastructure belonging to Shopify.

The scope fits on one page. Every line can stand up in front of a judge.

2.3. Allowed and forbidden techniques (Zone B summary, as an example)

Technique	Allowed?	Notes
Active port scan	Yes	Outside business hours, --max-rate 500 maximum.
Exploitation	Yes	No destructive writes.
SQL injection	Yes	On demo data only.
Privilege escalation	Yes	No persistent account after remediation.
Data extraction	Yes	Maximum 100 rows per table, redacted after extraction.
Brute force attack	Yes	Max 5 attempts per account.
Denial of service	No	—
Social engineering	See Zone D	—

Zone D is handled separately because phishing has its own rules.

2.4. Zone D — Social engineering

- Vector: email phishing only.
- Targets: 30 employees listed in Appendix B. CEO excluded.
- Volume: at most 2 waves of emails, 5 days apart.
- Send window: Wednesday 09:00 → 11:00 (Montreal time).
- Sender domain: boutique-eclair-support.com (acquired for the exercise).
- Post-click: redirection to an internal awareness page
  (provided by the client), no theft of real credentials.
- Reporting: anonymized list of clicks; names delivered only to HR.

Each of these constraints is coverage. The line "awareness page, no credential theft" prevents an internal scandal.

Definition — ethical phishing, and why we never actually steal the credentials

Authorized phishing in a pentest is not aiming to get usable passwords. It aims to measure a click-through rate and a submission rate on a booby-trapped page. That distinction changes everything, technically and legally.

On the landing page you present a fake authentication prompt — client logo, realistic form, credible URL on the domain acquired for the exercise. When the employee enters their email and password, the form does not transmit the data to a server that would store it. It discards the input immediately and switches to an awareness page: "You just fell for a simulated phishing message; here is how to spot it next time." The pentester never sees the password in clear text; the report contains only a counter, possibly pseudonymized.

This framing has three virtues. It makes the exercise compliant with personal data regulations — no authentication secret is collected. It makes the exercise defensible for HR, who can promise employees that no test will trap them for real. And it maximizes the learning value: the employee faces the awareness page in the second following their click, the moment where learning is most effective. A phishing exercise that actually stole credentials would produce the same metric without the three virtues.

2.5. Intervention windows

Week 1 (April 15-19)
  Zone A — documentation review, during business hours
  Zone C — initial scan, Wednesday 22:00 → Thursday 06:00

Week 2 (April 22-26)
  Zone B — exploitation, Tuesday and Thursday, 09:00 → 18:00
  Zone D — phishing wave #1, Wednesday 09:00 → 11:00

Week 3 (April 29 - May 3)
  Zone C — deep exploitation, Saturday 20:00 → Sunday 08:00
  Zone D — phishing wave #2, Wednesday 09:00 → 11:00

Buffer window: May 6-8, report writing.

Each slot in the calendar has an intent. The client knows what to expect. You know what you are not allowed to do on Tuesday at 2 PM.

2.6. Escalation contacts

Operational contact — Ms. Sophie Tremblay, CISO
  Phone: (514) 555-0142 (mobile, reachable 9-5 ET)
  Email: sophie.tremblay@boutique-eclair.ca

Emergency escalation (24/7) — Mr. Karim Bélanger, CIO
  Phone: (514) 555-0177 (personal mobile)
  Email: karim@boutique-eclair.ca
  Signal: +1 514 555 0177

Engagement lead (provider) — You
  Phone: (514) 555-0100
  PGP: see Appendix C

Three people. Three mobile numbers. No switchboard. No email with auto-reply.

2.7. Handling critical situations

Discovery of an exploitable critical vulnerability in production
  1. Immediate halt of exploitation.
  2. Notify Sophie Tremblay within 2 hours.
  3. Draft a short memo (1 page) within 24 hours.
  4. Continue the pentest on other axes.

Discovery of a preexisting intrusion
  1. Complete stop of tests on the affected zone.
  2. Call Karim Bélanger within 1 hour, on his personal number.
  3. Preserve indicators of compromise (IoCs).
  4. Switch to an incident response mandate, as an amendment to this contract.

Discovery of a personal data leak
  1. Notify Sophie Tremblay within 1 hour.
  2. Apply Law 25 obligations: notify the Commission d'accès à l'information
     if the leak is confirmed and presents a serious risk.

These procedures are not poetry. They are decision trees. We rehearse them in the kick-off meeting so everyone knows them by heart.

2.8. Evidence handling

Storage
  - Dedicated mission machine, LUKS-encrypted (aes-xts-plain64, 256 bits).
  - No cloud storage during the engagement.

Naming
  - YYYY-MM-DD_boutique-eclair_<zone>_<target>_<action>.<ext>
  - Ex.: 2026-04-23_boutique-eclair_zoneB_api_login_bruteforce.pcap

Retention
  - 90 days after delivery of the final report.
  - Certified destruction by DBAN overwrite + signed attestation.

Delivery
  - Report encrypted with PGP, client key fingerprint verified over the phone
    with Sophie Tremblay before delivery.

One day, someone will ask you "what did you do with our stolen passwords?". The answer is written right there.

2.9. Deliverables

1. Executive report (2-3 pages), delivered to Karim Bélanger.
   Date: 2026-05-13.

2. Full technical report, delivered to Sophie Tremblay.
   Date: 2026-05-13.
   Format: encrypted PDF + appendices (evidence files, scripts, screenshots).

3. Oral read-out session: 2026-05-16, 90 minutes, in person.

4. Retest session after remediation: to be scoped via amendment, within
   6 months of the report, capped at 3 person-days.

---

Step 3 — Get it reviewed

An unreviewed RoE is an incomplete RoE. Have it reviewed by two pairs of eyes before signing:

1. A lawyer — liability clauses, legal framework, data ownership.
2. A pentester peer — technical consistency, realism of the windows, completeness of the scope.

Each review yields 5 to 10 corrections. That is normal. A first-draft-perfect RoE is an unreviewed RoE.

---

Step 4 — Signature

Qualified electronic signature if possible (DocuSign, Notarius). Failing that, handwritten signature plus scan. Never a plain "yes, we agree" in an email.

Once signed, the RoE becomes the technical appendix to your contract. Any change goes through a written and signed amendment. An adjustment agreed in a meeting, captured in minutes, holds — but we always back it up with an amendment.

---

What just happened

• You met a client who, left alone, would have produced a half-page RoE that was dangerous.
• You asked twelve questions, several of them uncomfortable.
• You produced a three-page RoE that stands.
• You still have not run a single command. That is normal. A pentest starts on paper.

Next lesson: your turn. You draft a full RoE for a different, imposed scenario, with traps to spot.