Penetration Testing Methodology: Lifecycle, Frameworks, and Reporting

The full authorized penetration-testing lifecycle - legal prerequisites, methodology frameworks (PTES, OWASP WSTG, NIST SP 800-115, OSSTMM, MITRE ATT&CK), engagement phases, exploitation frameworks, and coordinated disclosure - tying together OSINT reconnaissance and vulnerability scanning.

Introduction / Overview

Legal and Ethical Prerequisites. Everything described in this document is illegal in essentially every jurisdiction unless performed under explicit, written, signed authorization from a party with the legal authority to grant it. In the United States, the Computer Fraud and Abuse Act (CFAA, 18 U.S.C. § 1030) criminalizes accessing a "protected computer" without authorization or in excess of authorization; in the United Kingdom, the Computer Misuse Act 1990 creates equivalent offenses for unauthorized access and unauthorized modification. Most other jurisdictions have directly analogous statutes. A signed scope document and rules of engagement (ROE) - sometimes informally called a "get-out-of-jail-free letter" - is not paperwork overhead; it is the sole line between a lawful security assessment and a computer crime, and it must be in hand, signed by someone with actual authority over the target systems, before a single packet of reconnaissance or scanning traffic is sent. This document assumes, throughout, a properly authorized, properly scoped engagement. It does not, and cannot, authorize testing anything without that signed agreement in place.

Penetration testing is the goal-oriented, exploitation-focused discipline that sits at the far end of a spectrum of authorized security assessment activity, downstream of the reconnaissance techniques covered in OSINT Reconnaissance and the automated discovery techniques covered in Vulnerability Scanning. Where a vulnerability scan answers "what weaknesses exist," a penetration test answers "can a skilled human actually exploit them, chain them together, and reach a defined objective, and what happens if they do." In 2026, penetration testing remains a required or de facto mandatory control under PCI DSS 4.0, most cyber-insurance underwriting questionnaires, and SOC 2 / ISO 27001 audit cycles, alongside its role as the primary tool for validating that automated scanning and code-level controls actually hold up against a determined, creative adversary.

Before any technical activity begins, confirm each of the following is true:

• A written, signed ROE exists, signed by someone with actual legal authority over every in-scope system.
• The signatory's authority has been verified - not merely asserted - particularly for engagements arranged through a procurement or sales channel rather than directly with the system owner.
• Third-party infrastructure (cloud providers, SaaS vendors, CDNs, managed hosting) that the target relies on has its own authorization satisfied where the provider requires separate pre-notification or approval.
• Emergency contacts, escalation procedures, and a defined "stop testing" trigger are documented and known to every tester before the testing window opens.
• Professional indemnity insurance and any required certifications (e.g., OSCP, CREST, GPEN - or organizationally, an authorization such as CREST-accredited status) are current, where required by the client or regulatory context.

Authorization requirements are not limited to the CFAA and Computer Misuse Act. Most jurisdictions with a developed cybercrime statute - Germany's StGB §202a-c, Australia's Cybercrime Act 2001, Canada's Criminal Code s.342.1, and equivalents across the EU under the Directive on Attacks Against Information Systems - impose similar unauthorized-access liability, and cross-border engagements (a common reality for cloud-hosted targets) can trigger multiple jurisdictions' statutes simultaneously. Where a target's infrastructure spans clouds, countries, or third-party providers, the ROE must identify which specific entity has authority to authorize testing of each component, and testers should confirm cloud-provider-specific penetration testing policies (most major cloud providers publish pre-authorization rules for testing workloads hosted on their platforms) are separately satisfied.

This document covers the full lifecycle: how penetration testing differs from adjacent disciplines, the standard methodology frameworks that structure an engagement, the phase-by-phase structure of a test from scoping through reporting, the classes of frameworks used during exploitation and post-exploitation, and the coordinated disclosure process for anything discovered along the way.

When to use this guidance: Planning, scoping, executing, or reporting on an authorized penetration test or red team engagement; selecting a methodology framework for an internal testing program; or writing a rules-of-engagement document for an external assessor.

Core Concepts

• Authorization is binary, not contextual: A tester either holds signed, current, in-scope authorization for a specific system at a specific time, or they do not. Good intent, a "responsible disclosure" motive, or having found a vulnerability by accident does not retroactively create authorization.
• Scope defines the boundary of legality, not just the boundary of usefulness: Every IP range, domain, application, and physical location must be enumerated as explicitly in-scope; anything not listed is out-of-scope by default, including third-party infrastructure the target merely uses (cloud provider control planes, SaaS vendors, ISPs) unless that third party has separately authorized it.
• Goal orientation: Unlike a vulnerability assessment, which aims for breadth (find as many weaknesses as possible), a penetration test is typically organized around one or more defined objectives (e.g., "achieve domain administrator," "exfiltrate a sample of the customer PII table," "compromise the payment processing path") that mirror what a realistic attacker would pursue.
• Time-boxing: Engagements run for a fixed, agreed window (commonly one to four weeks of active testing), which shapes methodology - testers prioritize high-value paths over exhaustive coverage, in contrast to continuous programs like bug bounties.
• Blue-team awareness varies by engagement type: A standard penetration test is typically announced to the defending team in advance; a red team engagement is often unannounced, specifically to measure detection and response, not just the presence of exploitable flaws.
• The kill chain / attack lifecycle: Most methodologies model an intrusion as a sequence - initial access, execution, persistence, privilege escalation, lateral movement, and objective completion (often mapped to the MITRE ATT&CK tactic categories) - and a mature test report narrates findings along this chain rather than as an unordered list of bugs.

Scoping & ROE  ->  Reconnaissance  ->  Scanning & Enumeration  ->  Exploitation  ->  Post-Exploitation  ->  Reporting  ->  Retest
   (legal)         (OSINT, passive)     (active, automated)      (manual, human)   (priv-esc, lateral,      (findings,     (verify
                                                                                     persistence)             CVSS, PoC)     fixes)

• Assessor independence and conflict of interest: The party conducting the test should not be the same party solely responsible for having built or operated the system under test without disclosure of that relationship, since it creates an incentive to underreport findings that reflect on the assessor's own prior work.
• Proportionality: The intensity and techniques of a test should be proportional to the sensitivity of what is being protected and the maturity of the target organization - an early-stage internal tool and a payment-processing platform do not warrant the same depth of manual exploitation effort.

Best Practices

1. Obtain and Verify Signed Authorization Before Any Technical Activity

Rationale: This is the non-negotiable legal prerequisite described above. Verbal approval, a Slack message from an engineering manager, or an assumption of implied consent ("they must know we test things") does not constitute authorization and does not protect the tester under the CFAA, the Computer Misuse Act, or their local equivalent.

# Rules of Engagement - required elements before testing begins
- Legal entity and named signatory with authority over the in-scope systems
- Explicit in-scope assets (IP ranges, domains, application names, cloud account IDs)
- Explicit out-of-scope exclusions (e.g., third-party payment processor, physical safety systems)
- Testing window (start/end date-time, time zone, blackout periods)
- Emergency contact list (target-side and tester-side, with escalation path)
- Data handling rules for anything discovered (PII, credentials, source code)
- Authorized testing techniques (e.g., is denial-of-service testing permitted? social engineering?)

Why this works well in production:

• A written, signed ROE is the evidentiary record that authorization existed, scoped exactly as tested, if the engagement is later questioned by legal, a regulator, or a third party whose system was inadvertently touched.
• Explicit emergency contacts prevent a discovered critical vulnerability (e.g., one already being actively exploited by a real attacker) from sitting undisclosed until a scheduled report date.

2. Select the Methodology Framework That Matches the Engagement's Purpose

Rationale: PTES, OWASP WSTG, NIST SP 800-115, and OSSTMM structure testing differently; using the wrong one as a rigid checklist produces a report that does not answer the question the engagement was commissioned to answer.

Important distinction: MITRE ATT&CK is a taxonomy of adversary behavior, not a step-by-step testing process. A mature penetration test or red team report commonly uses PTES or NIST 800-115 (or an internal methodology derived from them) to structure the engagement process, and separately maps individual findings and actions to ATT&CK technique IDs (e.g., T1078 Valid Accounts, T1021 Remote Services) to communicate adversary realism to a technical, detection-focused audience.

3. Distinguish Penetration Testing From Adjacent Disciplines Before Scoping

Rationale: Choosing the wrong discipline for the actual business question wastes budget and produces a report that answers the wrong question - e.g., commissioning a two-week penetration test to validate SOC detection capability, when only a red team engagement is designed to measure that.

Why this matters in practice: A low-risk internal tool with no sensitive data may only warrant recurring automated vulnerability scanning; a public-facing product benefits from continuous bug bounty coverage between periodic penetration tests; a red team engagement is commissioned specifically when the organization already has a mature detection program and wants to know whether it actually works against a realistic, evasive adversary - not to find more vulnerabilities.

4. Structure the Engagement Through Defined, Sequential Phases

Rationale: Every mainstream methodology framework converges on a similar phase structure; skipping or compressing a phase (most commonly scoping or reporting) is the most common source of engagement failure, scope disputes, and unusable deliverables.

Phase 1 - Scoping and Rules of Engagement: Define in-scope and out-of-scope systems precisely (by IP, domain, application, or account boundary), the testing window and any blackout periods, emergency contacts and escalation procedures for critical findings or unexpected impact, and data handling rules for anything sensitive discovered (how PII, credentials, or proprietary source code encountered during testing must be stored, transmitted, and destroyed after the engagement).

Phase 2 - Reconnaissance: Passive and semi-passive information gathering about the target organization, its infrastructure, personnel, and technology stack, performed without directly interacting with in-scope systems in an intrusive way. See OSINT Reconnaissance for the full technique set (domain/DNS enumeration, employee and technology footprinting, public code and document leakage, search-engine and certificate-transparency-based discovery).

Phase 3 - Scanning and Enumeration: Active, automated identification of live hosts, open services, software versions, and known vulnerabilities across the in-scope estate, forming the candidate target list that manual exploitation will attempt against. See Vulnerability Scanning for scanner selection, authenticated vs. unauthenticated scanning, and false-positive triage.

Phase 4 - Exploitation and Post-Exploitation: Manual, human-driven attempts to exploit identified weaknesses to gain an initial foothold, followed - at a methodology level, not as attack instruction - by:

• Privilege escalation: Moving from an initial low-privilege foothold to higher-privilege access on the same host or within the same trust boundary.
• Lateral movement: Using credentials, trust relationships, or exposed services to move from the initially compromised system toward the engagement's defined objective.
• Persistence: Establishing a durable foothold that survives reboots or credential rotation, used during longer engagements (particularly red team) to demonstrate sustained access risk, always removed and documented before engagement close-out.

Data-exfiltration objectives (e.g., "demonstrate access to the customer PII table") should be demonstrated with sample extraction sufficient to prove impact - a handful of representative, appropriately handled records - never a full-volume extraction of real sensitive data, which would itself constitute an unnecessary and unauthorized data-handling event beyond what the ROE's proof-of-impact requirement calls for.

Phase 5 - Reporting: The deliverable that converts technical findings into organizational action, detailed further below.

5. Report Findings in Layers That Serve Different Audiences

Rationale: An executive sponsor, a security engineering team, and a compliance auditor each need a different slice of the same underlying findings; a single undifferentiated technical dump serves none of them well.

# Penetration Test Report - structure
1. Executive Summary
   - Business-risk narrative in plain language, no CVE IDs or payloads
   - Overall risk posture and trend versus prior engagements
2. Scope and Methodology
   - ROE reference, dates, testers, framework used (e.g., PTES-aligned)
3. Findings (one per vulnerability/chain)
   - Title, CVSS v4 score and vector, affected asset(s)
   - Technical description and root cause
   - Proof-of-concept evidence (screenshots, request/response pairs, redacted data samples)
   - Business impact
   - Remediation guidance, prioritized
   - MITRE ATT&CK technique mapping where a chain was executed
4. Retest Results (on subsequent engagement or dedicated retest window)

Why this works well in production:

• CVSS scoring (Common Vulnerability Scoring System) gives findings a comparable, defensible severity ranking that feeds directly into the same vulnerability management prioritization process used for scanner output (see Vulnerability Scanning), rather than creating a parallel, incompatible severity scale.
• Proof-of-concept evidence must be handled under the same data classification as the sensitive data it demonstrates access to - screenshots of real customer PII in a report are themselves a data-handling liability and should be redacted or replaced with synthetic equivalents wherever the finding can still be understood.
• A defined retest process (commonly 30-90 days after report delivery) closes the loop - an unverified "fixed" status in a ticketing system is not evidence that a finding is actually resolved.

6. Map Findings and Actions to a Common Adversary Vocabulary

Rationale: Reporting a raw technique ("used a leaked service-account token to authenticate to the internal API gateway, then queried an over-permissioned role to enumerate other accounts") is accurate but does not let a blue-team reader quickly cross-reference the finding against their own detection rule coverage or threat-intelligence feeds.

Finding: Excessive IAM role permissions permitted lateral movement to the billing service.
ATT&CK mapping: T1078.004 (Valid Accounts: Cloud Accounts) -> T1021 (Remote Services)
Detection gap: No alert fired on cross-service authentication using this role outside its
normal calling service, despite the activity occurring outside business hours.

Why this works well in production:

• Mapping findings to MITRE ATT&CK technique IDs lets a security operations team directly check whether their SIEM/EDR has a corresponding detection rule, converting a penetration test report into an input for detection-engineering backlogs, not just a remediation backlog.
• Because ATT&CK is a continuously maintained, widely adopted taxonomy, this mapping remains legible across different assessors and different engagements over time, even as the underlying tools and specific exploitation techniques change.

Common Pitfalls & Anti-Patterns

Pitfall: Testing Without Written Authorization, or With Authorization That Does Not Match What Is Actually Tested

Problem: Verbal sign-off, outdated scope documents from a prior engagement, or "implied" authorization because the tester works for the same company are common shortcuts that leave both the tester and the organization legally exposed under the CFAA, Computer Misuse Act, or local equivalent the moment scope drifts even slightly (e.g., a discovered pivot path leads into a system, subsidiary, or cloud account not listed in the signed ROE).

Recommended approach: Treat the signed ROE as a hard technical boundary enforced by the tester, not just a legal formality - if a discovered path leads outside the documented scope, stop, document the finding at a high level, and escalate to request a scope amendment before proceeding.

Pitfall: Treating a Methodology Framework as a Rigid Checklist Instead of a Structural Guide

Problem: Mechanically working through every OWASP WSTG test case regardless of the application's actual architecture, or every PTES phase regardless of engagement objective, produces a report padded with irrelevant "not applicable" entries and can crowd out time for the deep, creative exploitation that finds the highest-impact findings.

Recommended approach: Use the framework to ensure coverage and consistency, but allocate the majority of engagement time to the attack paths most likely to matter for the specific target's architecture and business risk, adjusting checklist depth accordingly.

Pitfall: Confusing MITRE ATT&CK With a Testing Methodology

Problem: Teams sometimes attempt to run an engagement "using ATT&CK" as if it were a phase-by-phase process like PTES or NIST 800-115 - but ATT&CK is a taxonomy of adversary behavior, not a sequence of engagement activities, and has no scoping, ROE, or reporting guidance of its own.

Recommended approach: Pair a process framework (PTES, NIST 800-115, or an internal methodology) for how the engagement is run with ATT&CK as the vocabulary for describing what techniques were used once the engagement is underway or complete.

Pitfall: Skipping or Rushing the Reporting Phase

Problem: Under engagement time pressure, reporting is frequently compressed into a raw scanner export or an unstructured list of findings without business-impact narrative, CVSS scoring, or prioritized remediation guidance - producing a deliverable the client cannot act on.

Recommended approach: Budget explicit, protected time for report writing and internal quality review as a first-class phase of the engagement, not a residual activity performed after all testing time is exhausted.

Pitfall: Leaving Persistence Mechanisms or Test Artifacts in Place After Engagement Close-Out

Problem: Backdoors, scheduled tasks, added user accounts, or uploaded web shells created to demonstrate persistence during exploitation, if not fully removed and verified, become a genuine security liability indistinguishable from a real compromise - and a plausible source of confusion or panic for the client's incident response team later.

Recommended approach: Maintain a running log of every artifact created or account modified during the engagement, and perform an explicit clean-up and verification pass before delivering the final report, with the client confirming remediation of anything the tester cannot remove directly (e.g., requiring an administrator to reset a password the tester was given).

Pitfall: Applying a Bug-Bounty Safe-Harbor Mindset to a Non-Bounty Engagement

Problem: Testers sometimes assume that because a similar-looking activity is legal and welcomed under a bug bounty program's safe-harbor language, the same activity is implicitly acceptable against a different target that has no such published policy - it is not; safe harbor applies only within the specific program's stated scope and terms.

Recommended approach: Always verify the specific written authorization governing the exact target being tested; do not generalize permission from one program or engagement to another.

Pitfall: Conflating a Clean Scan Result With "Nothing Found" in the Report

Problem: When automated scanning (Phase 3) returns few or no findings, some engagements are compressed or the report understates residual risk, implying the target is broadly secure - but scanners systematically miss business-logic flaws, authorization bypasses, and multi-step chains, which is precisely why the manual exploitation phase exists.

Recommended approach: Report scanning and manual-testing coverage separately, and explicitly state what classes of vulnerability (e.g., logic flaws, IDOR, privilege escalation chains) the manual phase specifically targeted, so an absence of scanner findings is never mistaken for an absence of risk.

Testing Strategies

• Methodology fidelity check: Before the engagement begins, agree explicitly with the client which framework (PTES, WSTG, NIST 800-115, or a blended internal standard) will structure the test, and reference it in the ROE so both sides have a shared expectation of coverage.
• Objective-based test design: For goal-oriented engagements, define the target objective(s) (e.g., "demonstrate access to the production database containing customer PII") up front, and structure exploitation attempts around realistic paths to that objective rather than exhaustively testing every discovered vulnerability in isolation.
• Chained-finding validation: Individually low-severity findings (an information disclosure, a weak default credential, an overly permissive CORS policy) frequently combine into a critical chain; test and report chains explicitly, with CVSS scoring reflecting the chain's actual impact, not just the sum of individual component severities.
• Segregated evidence handling: Store proof-of-concept evidence (screenshots, extracted data samples, credentials obtained) in an access-controlled, encrypted repository separate from general engagement notes, and define its destruction timeline in the ROE.
• Retest as a distinct test cycle: Treat retesting fixed findings as its own scoped activity with its own pass/fail criteria per finding, rather than folding it informally into the next full engagement.
• Detection-validation testing (red team specifically): Where the objective includes validating detection and response, instrument the engagement to record exactly when and how each action was (or was not) detected by the blue team, independent of whether the technical exploitation itself succeeded.
• Assumption verification for scoping accuracy: Before relying on a client-provided asset inventory as the scope boundary, cross-check it against independent reconnaissance (see OSINT Reconnaissance) to catch forgotten or shadow-IT assets that the client's own inventory omits - while still respecting that anything not in the signed ROE remains out of scope regardless of what reconnaissance surfaces.
• Coverage-to-objective traceability: For objective-based engagements, maintain a matrix mapping each defined objective to the specific attack paths attempted and their outcome (succeeded, blocked, inconclusive), so the final report can state plainly whether each objective was or was not achieved, rather than leaving the reader to infer engagement success from a loosely related findings list.

Recommended assessment stack for this discipline:

• Reconnaissance and asset discovery: passive OSINT tooling paired with authoritative asset inventories (see OSINT Reconnaissance)
• Scanning and enumeration: authenticated and unauthenticated vulnerability scanners (see Vulnerability Scanning)
• Exploitation and post-exploitation: a general-purpose exploitation framework (e.g., Metasploit) plus a C2 framework appropriate to engagement type (commercial for red team realism, open-source for standard penetration tests)
• Attack-path analysis: directory/identity graph tooling (e.g., BloodHound) for environments with a significant Active Directory or cloud-IAM footprint
• Reporting: a structured report template enforcing CVSS scoring, ATT&CK mapping, and a consistent executive-summary format across engagements

Performance, Security & Scalability Considerations

• Engagement duration versus coverage trade-off: A fixed time-box means testers must triage which paths receive deep manual attention; a broader but shallower automated pass (see Vulnerability Scanning) should precede the engagement so manual effort is not spent re-discovering what a scanner would have found in minutes.
• Production impact management: Exploitation and post-exploitation activity, particularly denial-of-service-adjacent techniques or aggressive password-guessing, carries real availability risk against production systems; the ROE must explicitly state whether such techniques are authorized, and testers should throttle activity and maintain the emergency contact channel for immediate rollback coordination.
• Data exposure during testing itself: Any real sensitive data accessed during exploitation (to prove access, not to exfiltrate at volume) must be handled under the client's own data classification rules for the remainder of the engagement and reporting process - the test itself must not become a secondary data-exposure incident.
• C2 (command-and-control) infrastructure hygiene: In longer engagements using command-and-control frameworks for post-exploitation, tester-controlled infrastructure (redirectors, listening posts) must itself be secured against the client's real adversaries potentially discovering and hijacking it, and decommissioned promptly at engagement close.
• Credential and access cleanup at scale: In larger environments, track every credential harvested and every system accessed in a structured log so post-engagement cleanup (password resets, session invalidation, account removal) can be executed completely rather than from memory.

Edge Cases & Advanced Usage

• Assumed-breach engagements: Rather than starting from an external, unauthenticated perspective, the client provides the tester an initial low-privilege foothold (e.g., a standard employee laptop image or VPN credential) to compress the engagement directly into privilege escalation, lateral movement, and objective-completion phases - useful when external perimeter testing has already been validated separately and internal resilience is the actual question.
• Physical and social engineering scope: Some engagements (particularly PTES- and OSSTMM-aligned ones) explicitly include physical access attempts (badge cloning, tailgating) and social engineering (phishing, vishing) as in-scope vectors; these require unusually explicit ROE language covering employee consent, law-enforcement notification (to avoid a false alarm response to a physical intrusion attempt), and psychological/HR considerations for targeted staff.
• Cloud-native and API-heavy targets: Modern engagements increasingly focus on cloud IAM misconfiguration, container escape paths, and API authorization flaws rather than classical network-perimeter exploitation; testers should scope cloud provider account boundaries and API rate limits explicitly, since cloud infrastructure often spans shared control planes that require provider-level authorization in addition to the client's own.
• Purple team formats: A hybrid model where the red team (offense) and blue team (defense) collaborate in real time rather than the red team operating covertly, trading some detection-validation realism for faster knowledge transfer and remediation - appropriate when the primary goal is team capability-building rather than an unbiased measurement of current detection posture.
• Continuous/automated penetration testing platforms: Emerging tooling automates parts of the exploitation and lateral-movement chain (sometimes marketed as "automated red teaming" or "breach and attack simulation"); these complement but do not replace human-driven testing for novel logic flaws and creative chaining that automation does not anticipate.
• AI-assisted vulnerability discovery and exploitation tooling: Large-language-model-assisted code review, exploit generation, and target triage tools have materially accelerated both attacker and defender workflows; treat AI-suggested exploitation paths with the same verification rigor as any other unvetted tool output before including them in a report, since hallucinated or non-functional proof-of-concept code undermines report credibility.
• Cross-border and multi-cloud scope boundaries: When in-scope infrastructure spans multiple cloud providers, countries, or corporate subsidiaries, obtain and cross-reference authorization at every boundary crossed - a signed ROE with the primary client does not automatically extend to a third-party subprocessor's infrastructure or a subsidiary in a different legal jurisdiction, even if traffic flows through it as part of the same logical application.
• Engagements against systems with physical safety implications: Operational technology (OT), industrial control systems (ICS), and medical devices require substantially more conservative testing techniques (favoring passive analysis and read-only interaction over active exploitation) given that a crashed or misbehaving controller can have physical-world safety consequences; the ROE for such engagements should explicitly restrict or prohibit techniques with a plausible availability-impact risk.

Exploitation and Post-Exploitation Frameworks (Reference Level)

The following are referenced at the level of "what this class of tool does and why a team chooses it" - this is methodology and reporting context, not operational attack instruction.

These tools are referenced in penetration test and red team reports as the mechanism by which a described technique (e.g., an ATT&CK-mapped lateral movement step) was carried out, giving the reader (often a technical blue-team audience) enough context to understand detection and defensive implications, without the report itself constituting a how-to guide.

Coordinated Vulnerability Disclosure

Anything discovered during an authorized engagement that constitutes a novel, previously unknown vulnerability (as opposed to a known, already-tracked misconfiguration) should follow a coordinated (or "responsible") disclosure process if it affects third-party software, a shared dependency, or anything outside the direct client relationship where a simple internal ticket is not the appropriate mechanism.

• CVE assignment: Novel vulnerabilities in named products are typically reported to the vendor or a CVE Numbering Authority (CNA) to receive a CVE identifier, which anchors the finding in the same identifier space used by the vulnerability management lifecycle described in Vulnerability Scanning, enabling downstream scanners and asset inventories to track remediation.
• Standard disclosure timelines: A 90-day window from initial vendor notification to public disclosure remains the most commonly cited industry baseline (popularized by Google Project Zero and reflected in many vendor and government disclosure policies), with disclosure typically occurring earlier if a fix ships first. This baseline is under active pressure in 2026: the EU Cyber Resilience Act introduces a much shorter 72-hour initial notification requirement for actively exploited vulnerabilities in in-scope products, and some practitioners argue AI-accelerated vulnerability research is compressing realistic timelines further. A defensible current approach is a tiered timeline - an expedited window (days, not months) for actively exploited critical vulnerabilities, with 90 days retained as a ceiling for lower-severity findings absent regulatory requirements to the contrary.
• Safe harbor language: Formal disclosure and bug bounty program policies increasingly include explicit "safe harbor" clauses committing the vendor not to pursue legal action (including under the CFAA or Computer Misuse Act) against a researcher who discovers and reports a vulnerability in good faith within the program's stated scope and process - this protection applies only within that specific program's terms, not generally.
• Connection to vulnerability management: Once assigned a CVE and disclosed, a finding re-enters the standard vulnerability management lifecycle - scored, tracked, and remediated using the same processes and tooling used for scanner-discovered vulnerabilities (see Vulnerability Scanning), closing the loop between manual, human-driven discovery and the organization's ongoing automated posture management.
• Vulnerability Disclosure Policy (VDP) vs. CVD vs. bug bounty: A VDP is the published policy statement (scope, safe harbor, reporting channel) that makes CVD possible for external researchers; a bug bounty program is a VDP with an added financial incentive structure. A penetration test engagement typically has its findings disclosed directly and privately to the client under the ROE's existing confidentiality terms - CVD process specifically applies when the finding affects a third-party vendor, an open-source dependency, or shared infrastructure the client does not exclusively control, and therefore requires notifying a party outside the direct engagement relationship.
• Findings affecting third-party or shared components: When exploitation reveals a vulnerability in a third-party product or library rather than client-specific configuration or code, the tester should recommend (and, where the ROE and client relationship permit, assist with) routing that specific finding through the vendor's own CVD channel in parallel with the client-facing report, since the client alone cannot remediate a defect in code it does not own.

Reporting and Retesting Detail

Beyond the layered structure in Best Practice #5, two operational details determine whether a report is actually actionable:

• Proof-of-concept evidence handling: Store PoC evidence (request/response captures, screenshots, extracted sample records) in an access-controlled repository separate from the narrative report, redact or synthesize any real sensitive data values before inclusion, and define a destruction date for this evidence in the ROE - typically aligned with contractual record-retention requirements, not indefinite retention "just in case."
• Remediation guidance specificity: Generic guidance ("implement input validation") is less actionable than guidance tied to the specific finding's root cause and the client's actual stack (e.g., "add server-side authorization check scoped to current_user.id on the /invoices/{id} handler, mirroring the pattern already used on /orders/{id}") - where the codebase already demonstrates a correct pattern elsewhere, cite it directly as the fix template.

When Not to Use / Alternatives

A full penetration test is not always the correct tool for the underlying business question.

A red team engagement is the wrong choice when the goal is simply "find as many vulnerabilities as possible" - its unannounced, objective-based, detection-focused design intentionally sacrifices coverage breadth for depth and realism, which is the opposite trade-off a comprehensive-coverage goal requires.

Related Documentation

• OSINT Reconnaissance - the passive information-gathering phase preceding scanning and exploitation
• Vulnerability Scanning - the automated discovery phase and the vulnerability management lifecycle that disclosed findings feed back into
• OWASP Top 10:2025 - the risk categories most commonly targeted during web-application-focused exploitation
• Secure Coding Practices - the code-level controls that determine what a penetration test will and will not find exploitable

Glossary

• PTES (Penetration Testing Execution Standard): A community-maintained methodology defining the standard seven-phase structure of a penetration test - pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting.
• ROE (Rules of Engagement): The signed document defining scope, testing window, authorized techniques, emergency contacts, and data handling rules for an engagement; the legal and operational boundary of authorized activity.
• OSSTMM (Open Source Security Testing Methodology Manual): A quantified, metrics-driven testing methodology maintained by ISECOM, scoring an attack surface across human, physical, wireless, telecommunications, and data-network channels.
• WSTG (Web Security Testing Guide): OWASP's web-application-focused testing methodology and technique catalog, organized by vulnerability category.
• CVD (Coordinated Vulnerability Disclosure): The process of privately notifying an affected vendor of a discovered vulnerability and agreeing a timeline for remediation before public disclosure.
• Red team: An adversary-emulation engagement, often unannounced to the defending team, designed to test detection and response capability against a realistic, objective-driven attacker, not merely to enumerate vulnerabilities.
• C2 (command and control): Infrastructure and tooling used by an attacker (or, in an authorized engagement, a tester) to maintain remote control over a compromised system after initial access.
• Lateral movement: The technique of using access gained on one system to reach additional systems within the same environment, typically via harvested credentials or trust relationships.
• Privilege escalation: Increasing one's level of access on a compromised system or environment beyond the level initially obtained.
• CVSS (Common Vulnerability Scoring System): A standardized scoring framework used to rank the severity of a vulnerability, used consistently across both scanner findings and penetration test findings.
• Safe harbor: Contractual or policy language committing an organization not to pursue legal action against a researcher who discovers and reports vulnerabilities within a defined program's authorized scope and process.
• Assumed breach: An engagement model that starts the tester with an initial foothold already granted, compressing the test into privilege escalation, lateral movement, and objective phases.
• Purple team: A collaborative engagement format where red (offense) and blue (defense) teams work together in real time, trading detection-validation realism for faster capability-building.
• TTPs (Tactics, Techniques, and Procedures): The MITRE ATT&CK-style vocabulary for describing adversary behavior at increasing levels of specificity - a tactic is the "why" (e.g., persistence), a technique is the "how" (e.g., scheduled task creation), and a procedure is the specific implementation observed.
• Kill chain: A staged model of an intrusion's lifecycle, from initial reconnaissance through objective completion, used to structure both attacker planning and defender detection strategy.
• Get-out-of-jail-free letter: Informal term for the signed authorization letter a tester carries (physically, for on-site engagements) as evidence of authorized activity if challenged by security personnel or law enforcement during testing.
• Bug bounty program: A continuous, typically crowd-sourced vulnerability discovery program with a published scope, reward structure, and safe-harbor policy, run independently of any single time-boxed engagement.

Maintenance note: When updating this document, also update last_updated and consider whether any related documents need reciprocal links or updates.