Pentest Authorization Scoping And Methodology

---
name: pentest-authorization-scoping-and-methodology
description: "Use when planning or scoping an authorized penetration test or red-team engagement, or reasoning about what makes offensive security work lawful and professional. Covers the authorization and legal foundation (CFAA as criminal and civil statute, the UK Computer Misuse Act, the DOJ good-faith-research policy and why not to rely on it, DMCA §1201), the authorization package and get-out-of-jail letter, the third-party trap, bug bounty and VDP scope, professional obligations; the engagement types and the scoping questions that determine whether a test is useful (including regulated testing); and the standard methodologies (PTES, OWASP WSTG, NIST SP 800-115, MITRE ATT&CK, OSSTMM) and the engagement lifecycle. Includes the router for the whole penetration-testing reference. Authorized, defensive-context work only."
---

# Penetration Testing: Authorization and Law, Engagement Types and Scoping, and Methodology

> **Part 1 of 4** of the *Penetration Testing and Offensive Security* reference (plugin `penetration-testing`), covering §0–§3. Sibling skills: `pentest-technical-domains` (§4–§9), `pentest-red-team-ai-and-reporting` (§10–§13), `pentest-disclosure-career-and-reference` (§14–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill.
>
> **Currency:** Verified August 2026. See §17 → `pentest-disclosure-career-and-reference` for the currency snapshot and what goes stale first.

> **⚠️ THE PREREQUISITE FOR EVERYTHING BELOW.** The entire difference between this
> profession and a felony is **documented, informed authorization from someone with the
> authority to grant it, for a defined scope, in a defined window.** Not implied consent.
> Not a verbal go-ahead. Not "the client seemed fine with it." Not a bug bounty scope you
> read quickly. **§1 is the section that matters most, and it is first for that reason.**
>
> This document is written for people doing authorized work — in-house security teams,
> consultancies, bug bounty participants operating inside a published scope, and the
> people who hire and manage them. **It is a methodology, process, and professional
> practice reference.** It deliberately does not contain exploitation recipes, working
> exploit code, or techniques for evading specific defensive products; those live in
> engagement-specific research, and the value of a reference like this is in the parts
> practitioners actually get wrong — scoping, method, evidence, and communication.
>
> **This is not legal advice.** §1 tells you what to ask your counsel, not what your
> obligations are in your jurisdiction.

> **How to read this.** Three markers:
> - **[DURABLE]** — professional practice, methodology, or a lesson the field has settled.
> - **[VERSIONED]** — regulation, tooling, market state. Verify.
> - **[CONTESTED]** — practitioners genuinely disagree.
>
> **The three framings that organize everything below:**
> 1. **The report is the product.** The client is not buying access to their systems —
>    they already have that. **They are buying a prioritized, reproducible, actionable
>    understanding of their risk.** A brilliant compromise written up badly is a failed
>    engagement (§13 → `pentest-red-team-ai-and-reporting`).
> 2. **Your job is to model a threat, not to win.** "I got domain admin" is not the goal;
>    **"here is how an attacker with these capabilities would reach these assets, here is
>    what detected them and what didn't, and here is what to fix first"** is.
> 3. **You are operating in someone's production environment and you can break it.**
>    Professional restraint — knowing what *not* to run — is a larger part of competence
>    than the ability to run anything.

---

## §0. Routing

| Asked about... | Go to |
|---|---|
| **Authorization, legality, rules of engagement** | **§1 — start here** |
| Engagement types and scoping | §2 |
| Methodology and standards | §3 |
| Recon and attack surface | §4 → `pentest-technical-domains` |
| Web application testing | §5 → `pentest-technical-domains` |
| Network and infrastructure | §6 → `pentest-technical-domains` |
| Active Directory and identity | §7 → `pentest-technical-domains` |
| Cloud | §8 → `pentest-technical-domains` |
| API, mobile, wireless, OT, hardware | §9 → `pentest-technical-domains` |
| Social engineering and physical | §10 → `pentest-red-team-ai-and-reporting` |
| Red teaming, purple teaming, post-exploitation | §11 → `pentest-red-team-ai-and-reporting` |
| AI systems (testing them, and using them) | §12 → `pentest-red-team-ai-and-reporting` |
| **Reporting and remediation** | **§13 → `pentest-red-team-ai-and-reporting`** |
| Disclosure, bug bounty, career, certifications | §14 → `pentest-disclosure-career-and-reference` |
| "Don't do this" | §15 → `pentest-disclosure-career-and-reference` |
| "Which approach is better?" | §16 → `pentest-disclosure-career-and-reference` |
| "Is this still current?" | §17 → `pentest-disclosure-career-and-reference` |
| Books, labs, people | §18 → `pentest-disclosure-career-and-reference` |

---

## §1. Authorization and Law

### 1.1 What makes this legal

**[DURABLE] Unauthorized access to a computer system is a crime in essentially every
jurisdiction**, and the technical activity is identical whether or not you have
permission. **The permission is the entire legal distinction.** In the US the relevant
statute is the **Computer Fraud and Abuse Act (CFAA)** — note that it is **both a criminal
and a civil statute**, so you can be prosecuted *and* privately sued. The UK has the
Computer Misuse Act; the EU has national implementations of the Directive on attacks
against information systems; most other jurisdictions have equivalents.

**⚠️ The threat to researchers is more often civil than criminal.** Rapid7's assessment is
that the threat of private lawsuits against legitimate researchers for "loss" is **much
more common than federal criminal prosecution** — which matters, because a civil suit
doesn't require a prosecutor to think you did something wrong.

**[VERSIONED] The US DOJ's CFAA charging policy directs federal prosecutors to decline
prosecution where the evidence shows good-faith security research** — but the policy
itself states that it is **internal guidance and creates no enforceable legal right or
benefit.** It is not a defence you can raise; it is a prosecutorial preference that can
change. **Do not build your risk model on it.**

Also live: **DMCA §1201** (circumventing technical protection measures — the reason
researchers sought and won a specific exemption), **US state computer-crime laws** (which
have their own scope and have been used against researchers), export controls, and
sector-specific rules. **[VERSIONED]** Academic work in 2026 continues to argue that
European protection for security researchers is fragmented, citing high-profile cases in
the Netherlands, Malta, and Germany, and noting jurisdictions such as Italy where
researchers risk falling within criminal provisions without an available exemption.

### 1.2 The authorization package

**[DURABLE] Never begin technical work without all of these, in writing, signed.**

| Document | What it establishes |
|---|---|
| **Master Services Agreement / contract** | Commercial terms, liability, insurance |
| **Statement of Work** | What you are testing and what you will deliver |
| **Rules of Engagement (RoE)** | The operational boundaries — the most important document |
| **Authorization letter ("get out of jail letter")** | Signed by someone with actual authority; **carry it during the engagement**, especially for physical work |
| **NDA** | Both directions |
| **Third-party authorization** | ⚠️ §1.3 |

**The Rules of Engagement must state**: exact in-scope targets (IPs, domains, apps,
accounts — **enumerated, not described**), **explicit out-of-scope items**, the testing
window (dates *and* hours), permitted techniques and **prohibited ones** (DoS? social
engineering? physical? password spraying against production accounts? data exfiltration,
and if so, of what?), **the stop condition and who can invoke it**, emergency contacts on
both sides available during the window, evidence handling and data-retention rules,
how findings of unrelated criminal activity are handled, and **whether the blue team
knows** (§11.2 → `pentest-red-team-ai-and-reporting`).

**[DURABLE] Get the authorizer's authority verified, not assumed.** A CTO can usually
authorize testing of systems the company owns. **They usually cannot authorize testing of
their cloud provider's infrastructure, their SaaS vendors, or a shared-hosting neighbour.**

### 1.3 The third-party trap

> **⚠️ GOTCHA — scope creep into systems your client doesn't own is the most common way
> good engagements become legal problems.** Watch for:
> - **Cloud provider infrastructure.** Major providers publish penetration testing
>   policies; most permit customer testing of your own resources without prior approval
>   but **prohibit testing of provider infrastructure and certain service types**, and
>   **require separate approval for simulated DoS/DDoS.** Read the current policy for the
>   specific provider — they change.
> - **SaaS and third-party APIs** your client integrates. Their systems, their permission.
> - **Shared hosting** where other tenants sit on the same host.
> - **CDN, WAF, and DNS providers** in front of the target.
> - **Supply chain** — testing a vendor because your client uses them is not authorized by
>   your client.
> - **Employees' personal devices and accounts**, and anything touching their personal data.
> - **Wireless** — RF doesn't respect property lines, and neighbouring networks are not
>   yours.

### 1.4 Bug bounty and VDP

**[DURABLE] A published scope is your authorization, and its edges are hard.** Read the
policy in full before touching anything: in-scope assets, out-of-scope assets, prohibited
techniques (usually automated scanning at volume, DoS, social engineering of staff, and
anything touching real user data), and disclosure terms.

**Safe harbour language is the load-bearing element.** As one platform puts it, existing
anti-hacking laws are broad enough that even good-faith researchers doing ethical
disclosure could face liability, which makes an **unambiguous statement that the
organization considers good-faith security research to be authorized activity** essential.
**⚠️ A program without safe harbour language is a program that has not authorized you** —
weigh that accordingly. **[VERSIONED]** HackerOne's Gold Standard Safe Harbor was aligned
as of **1 January 2026** with recent legal and regulatory developments, including the
Netherlands NCSC's vulnerability disclosure policy.

**A VDP requires four things**: clear scope, safe harbour, a submission channel, and a
response SLA. A bug bounty adds rewards and a platform. **[VERSIONED] CISA BOD 20-01
required all US federal civilian agencies to publish a VDP**, which is why nearly every
`.gov` has one.

**⚠️ Going out of scope voids your protection entirely**, and no amount of good intent
recovers it. If you find something interesting just outside the boundary: **stop, document
that you stopped, and ask.**

### 1.5 Professional obligations

**[DURABLE] Minimize impact.** You are in production. Prefer read over write, proof over
exploitation, and the least invasive demonstration that establishes the finding. **You do
not need to exfiltrate the customer database to prove you could** — a row count and a
redacted sample field is proof; the full dump is a liability you now hold.

**Handle data as if it were the client's most sensitive asset, because it is.** Encrypted
storage, minimal retention, documented destruction, and **never on a personal device**.

**Report immediately, outside the normal cycle**: evidence of a **prior or ongoing
compromise** (this is the one that stops the engagement and starts an incident response),
anything that endangers safety, and critical findings on production systems that can't
wait for the report.

**⚠️ If you break something, say so immediately.** Concealment turns a recoverable
operational incident into a career-ending professional failure, and clients forgive the
first far more readily than the second.

---

## §2. Engagement Types and Scoping

### 2.1 The types

| Type | Question it answers |
|---|---|
| **Vulnerability assessment** | "What known weaknesses exist?" — breadth, largely automated. **Not a pentest**, and mislabelling is endemic |
| **Penetration test** | "What can an attacker actually do with these weaknesses?" — depth, verified exploitation |
| **Red team** | "Would we detect and respond to a real adversary pursuing a specific objective?" — tests **people and process**, not just technology |
| **Purple team** | Collaborative — testers and defenders working together to build and validate detections. **Often the highest value per dollar** (§11.2 → `pentest-red-team-ai-and-reporting`) |
| **Threat-Led Penetration Testing (TLPT)** | Regulated, intelligence-driven red teaming against production (§2.3) |
| **Assumed breach** | "Given a foothold, what happens next?" — skips the perimeter, spends the budget on what matters |
| **Config / architecture review** | Whitebox, often finds more per hour than testing does |

**Knowledge levels**: **black box** (no information — realistic, and you spend the client's
money rediscovering their network diagram), **grey box** (some access/credentials — **the
usual and usually correct choice**), **white box** (full access and source — **the highest
findings-per-hour, and the least realistic**).

**[CONTESTED] Black box realism vs. white box coverage.** *For black box*: it tests what an
external attacker faces, including your detection. *Against*: a real attacker has unlimited
time and you have two weeks, so you are testing your recon speed rather than their
security. **The strong practitioner position is that grey/white box finds more real risk
per dollar, and black box should be reserved for when you're specifically testing
detection** — which is a red team objective (§11 → `pentest-red-team-ai-and-reporting`).

### 2.2 Scoping questions that determine whether the test is useful

**[DURABLE] Bad scoping produces a technically competent test that answers the wrong
question**, and it's the most common failure in commissioning one.

- **What are you actually worried about?** ("Compliance" is a valid answer; it just leads
  to a different test than "we hold customer PII and want to know if it's reachable.")
- **What are the crown jewels?** Test toward them.
- **What is the threat model?** Opportunistic external attacker, targeted adversary,
  malicious insider, compromised third party — these need different tests.
- **Production or staging?** ⚠️ **A staging environment that differs from production tests
  a system that doesn't exist**, but production carries real risk. Name the trade-off
  explicitly rather than defaulting.
- **How much time?** Findings scale with time; a five-day test on a large estate is a
  sample, and the report should say so.
- **What happens to the findings?** A test whose output nobody has budget to remediate is
  an expensive document.
- **Retest included?** It should be.

### 2.3 Regulated testing

**[VERSIONED] DORA's Threat-Led Penetration Testing is the most consequential regulatory
development in this space**, and it has real supply-side consequences.

- **DORA Article 26** requires designated EU financial entities to undergo TLPT **at least
  every three years**, on **production** systems, following intelligence-driven scenarios.
  **Article 27** sets a demanding bar for testers.
- **⚠️ You do not self-select.** Your national TLPT authority notifies you when you are in
  scope, based on impact and ICT-risk criteria.
- **The methodology is TIBER-EU**, with a five-phase structure and a defined cast:
  a **Control Team** inside the entity, a regulator-side **TLPT Cyber Team**, an
  independent **Threat Intelligence provider**, and a **Red Team** — with the **Blue Team
  deliberately unaware until the active phase ends**.
- **⚠️ Capacity is genuinely tight.** A full cycle is reported at **9–14 months from
  provider selection to attestation**, against a small pool of qualified providers; one
  2026 analysis cites 200+ designated entities competing for **fewer than 40 qualified red
  team providers**, and warns that **a competent authority may reject a TLPT conducted by
  an unqualified provider, forcing a restart.**
- **UK equivalents**: **CBEST** (Bank of England) and **STAR-FS** (CREST) — CBEST-certified
  exercises are recognized under DORA given the TIBER-EU alignment.
- **Note the divergence**: DORA permits internal testers under strict conditions and
  mandates outsourcing every third test; **TIBER-EU currently prohibits internal testers.**

**Other regimes**: **PCI DSS** requires annual penetration testing and after significant
change, with segmentation testing; **HIPAA**, **SOC 2**, **ISO 27001**, **FedRAMP**, and
**NIS2** all drive testing demand with differing specificity.

---

## §3. Methodology

### 3.1 The standards

**[DURABLE] Use a published methodology. It is what makes your work defensible, repeatable,
and comparable** — and "we poked at it until we found something" is not a methodology.

| Standard | Use |
|---|---|
| **PTES** (Penetration Testing Execution Standard) | The seven-phase engagement structure |
| **OWASP Web Security Testing Guide (WSTG)** | **The reference for web app testing.** Exhaustive, free |
| **OWASP MASTG / MASVS** | Mobile |
| **OWASP API Security Top 10** | APIs (§9.1 → `pentest-technical-domains`) |
| **NIST SP 800-115** | The US government technical testing guide |
| **OSSTMM** | Older, rigorous, metrics-oriented |
| **MITRE ATT&CK** | **The shared vocabulary for adversary behaviour** — map findings to it so defenders can act |
| **TIBER-EU / CBEST / STAR-FS** | Regulated red teaming (§2.3) |
| **CWE / CVSS / EPSS** | Classification and severity (§13.2 → `pentest-red-team-ai-and-reporting`) |

### 3.2 The engagement lifecycle

```
1. PRE-ENGAGEMENT      scope, RoE, authorization, contacts, logistics   ← §1, §2
2. INTELLIGENCE        passive then active recon, attack surface        ← §4
3. THREAT MODELLING    what would an adversary want, and how
4. VULNERABILITY ANALYSIS   identify and verify candidate weaknesses
5. EXPLOITATION        verify impact, with restraint                    ← §1.5
6. POST-EXPLOITATION   pivot, escalate, demonstrate business impact     ← §11
7. REPORTING           the actual product                              ← §13
   → remediation support → RETEST
```

**[DURABLE] Two disciplines that separate professionals from enthusiasts:**
- **Contemporaneous notes.** Every command, timestamp, target, and result — because you
  will be asked "was that you?" months later, and because your report's reproduction steps
  come from here. Timestamps in **UTC**, and record your source IPs so the client can
  correlate their logs.
- **Deconfliction.** The client must be able to distinguish your traffic from a real
  attacker's. Provide source IPs in advance, use identifiable user-agents where
  appropriate, and be reachable.