Skip to content

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

[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.

Plugin: penetration-testing · View SKILL.md on GitHub