Methodology, Authorisation & Rules of Engagement

Prerequisites

• FND-K001: CIA Triad & the Modern Threat Landscape
• FND-K002: Ethical & Legal Boundaries

Why This Lesson Matters

A penetration tester without a signed authorisation is a criminal. The skill set is identical — the only difference is a piece of paper. This lesson ensures you never work without that paper and that you know exactly what it must say. Every technique in this path is only legitimate inside the boundaries this lesson defines.

1. What a Penetration Test Is

A penetration test is an authorised, time-bound, objective-driven simulation of an attacker conducted to identify exploitable weaknesses before a real attacker does.

Three words matter: authorised (you have written permission), time-bound (there is a start and end date), and objective-driven (you are proving specific risks, not exploring indefinitely).

What a pentest is not: - A vulnerability scan (scanners find; testers prove) - An audit (audits measure compliance; pentests measure exploitability) - A red team operation (red teams simulate full APT campaigns; pentests are scoped and shorter)

2. The PTES Methodology

The Penetration Testing Execution Standard (PTES) defines seven phases:

Never skip phases. A tester who jumps straight to exploitation without recon misses the weaknesses that a real attacker would find in the gaps.

3. The Rules of Engagement Document

The Rules of Engagement (RoE) is the contract that defines exactly what you can and cannot do. Without it, every action you take is potentially criminal.

Mandatory RoE elements:

1. IN-SCOPE targets
   List every IP range, domain, application, and API endpoint
   you are permitted to test.
   Example: 10.0.0.0/24, app.corp.local, api.corp.local/v2/*

2. OUT-OF-SCOPE targets
   Anything NOT on the in-scope list that you must never touch.
   Example: prod-db.corp.local, 10.0.1.0/24 (HR network)

3. PERMITTED TECHNIQUES
   Which attack categories are allowed.
   Example: network scanning, web application testing, privilege escalation
   Prohibited: social engineering, DoS attacks, ransomware simulation

4. TESTING WINDOW
   Exact dates and hours when testing is permitted.
   Example: 2026-06-08 08:00 → 2026-06-22 17:00 (business hours only)

5. EMERGENCY CONTACT
   Who to call if something breaks or you discover a critical issue.
   Name, phone, email — available 24/7 during the engagement.

6. DATA HANDLING
   How to treat any sensitive data you encounter.
   Example: Do not exfiltrate; record only minimum necessary to prove the finding.

7. REPORT CLASSIFICATION
   How to handle the final report (confidential, attorney-client privilege, etc.)

The "verbal permission" trap: A manager saying "go ahead, test our app" is not authorisation. You need a signed document from someone with authority over the systems in question. If you cannot verify the authority, you cannot test.

4. Scoping Decisions

Scope is negotiated with the client, but the tester should understand the implications of each choice.

Most professional engagements use grey-box: enough context to test efficiently, limited enough to still simulate a realistic threat.

5. Sensitive Data Handling During Testing

During an engagement you will encounter sensitive data — credentials, PII, financial records, medical information. Your obligations:

• Minimum necessary principle: Capture only what proves the finding. Do not copy entire databases.
• No retention: Delete any sensitive data at engagement close per the agreed timeline.
• Secure transmission: All findings and evidence transmitted encrypted; never via personal email.
• Mandatory escalation: If you discover evidence of an ongoing crime (fraud, CSAM, active breach), stop and notify the emergency contact immediately. Do not continue testing.

6. Common Mistakes

Mistake 1: Starting without a signed RoE. Even if you trust the client. Even if you have done work for them before. Even if they are in a hurry. No signature = no test.

Mistake 2: Not verifying the client owns the target. A client can only authorise testing of systems they control. If the application runs on a third-party cloud platform, you may need that platform's permission too. AWS, Azure, and GCP all have their own penetration testing policies.

Mistake 3: Scope creep during testing. You find an interesting server that is not in scope. You "just look at it quickly." This is unauthorised access. Document what you found and notify the client — do not touch it.

7. Practice Exercises

1. A client hands you a URL and says "test it." What four questions do you ask before running a single tool?

2. During a web app test, you discover a SQL injection that gives you access to an out-of-scope database server containing HR records. Describe your next three actions.

3. Review this RoE excerpt and identify the two missing mandatory elements: "You may test app.corp.local between June 8–22. Do not attack any network infrastructure. Contact John if needed."

8. Lab

Assessment mode: quiz

8 scenario questions: identify missing RoE elements, classify actions as authorised/unauthorised, and select the correct response to scope violations.

9. Framework Alignment

10. Further Reading

• PTES Standard — http://www.pentest-standard.org — The full methodology reference
• AWS Penetration Testing Policy — https://aws.amazon.com/security/penetration-testing/
• HackerOne Disclosure Guidelines — Model for responsible disclosure after finding issues

["State the seven PTES phases in order and describe the output of each", "List the seven mandatory elements of a Rules of Engagement document and identify which element is missing from a provided RoE excerpt", "Apply the minimum necessary principle and the scope boundary rules to three described test scenarios and determine the correct action in each"]

Prerequisites → Why this matters → What a pentest is (vs scan, audit, red team) → PTES methodology (7 phases table) → Rules of Engagement (7 mandatory elements with examples) → Scoping decisions (black/grey/white box) → Sensitive data handling → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading