# Pentest Plan

> Plan penetration testing scope, methodology, and rules of engagement

- Skill: `bromso/pentest-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bromso/pentest-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bromso/pentest-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: bromso (https://skillmd.com/u/bromso)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bromso/pentest-plan

---


# Penetration Test Plan

Plan penetration testing for "$ARGUMENTS" covering test type, scope, methodology, rules of engagement, success criteria, and reporting requirements.

## Process

1. **Define penetration test type:**
   - **Black box** — testers have no prior knowledge of the target (simulates external attacker)
   - **Grey box** — testers have partial knowledge (user credentials, architecture docs, API documentation)
   - **White box** — testers have full knowledge (source code, architecture, admin access)
   - Select type based on testing objectives: black box for external threat simulation, grey box for authenticated attack paths, white box for comprehensive coverage
   - Document rationale for selected approach

2. **Define scope:**
   - **In-scope systems** — list specific applications, APIs, networks, hosts, and cloud resources to test
   - **In-scope test types** — network penetration, web application, API, mobile, social engineering, physical
   - **Out-of-scope systems** — explicitly list systems, networks, or techniques that are excluded
   - **Data constraints** — define handling of any sensitive data encountered during testing
   - **Third-party systems** — identify any third-party systems in scope and confirm authorization
   - Document scope boundaries clearly to prevent unauthorized testing

3. **Select methodology:**
   - **OWASP Testing Guide** — for web application and API testing
   - **PTES (Penetration Testing Execution Standard)** — for comprehensive network and application testing
   - **NIST SP 800-115** — for government and regulated environments
   - **OWASP Mobile Security Testing Guide** — for mobile application testing
   - Define testing phases: reconnaissance, scanning, exploitation, post-exploitation, reporting
   - Specify tools permitted and prohibited (if any restrictions apply)

4. **Define rules of engagement:**
   - **Testing windows** — permitted hours and days (business hours only, after hours, weekends)
   - **Notification** — who is aware testing is occurring (security team, SOC, management)
   - **Emergency contacts** — who to call if testing causes an outage or discovers active breach
   - **Prohibited techniques** — denial of service (unless explicitly authorized), social engineering of specific individuals, physical intrusion (unless in scope)
   - **Data handling** — no exfiltration of real customer data, test data only, secure deletion after testing
   - **Credential handling** — obtained credentials must be reported immediately and not reused outside testing
   - **Communication channel** — encrypted channel for reporting critical findings during testing
   - **Stop conditions** — circumstances that require immediate cessation of testing

5. **Define success criteria:**
   - What constitutes a successful test? (comprehensive coverage, critical findings identified, defense validation)
   - Minimum coverage requirements (percentage of in-scope systems tested, OWASP categories covered)
   - Expected deliverables: executive summary, technical findings, evidence (screenshots, logs), remediation recommendations
   - Finding severity classification aligned with organization's risk framework

6. **Define reporting requirements:**
   - **Executive summary** — non-technical overview for leadership
   - **Technical findings** — detailed vulnerability descriptions with CVSS scores
   - **Evidence** — proof-of-concept details, screenshots, reproduction steps
   - **Risk rating** — severity aligned with CVSS and business context
   - **Remediation recommendations** — specific, actionable guidance per finding
   - **Retest plan** — scope and timeline for verifying remediation
   - Report delivery: encrypted, limited distribution, defined retention period

7. **Set remediation timeline expectations:**
   - **Critical findings** — remediation within 72 hours, retest within 1 week
   - **High findings** — remediation within 2 weeks, retest within 1 month
   - **Medium findings** — remediation within 1 month, retest within next scheduled test
   - **Low/informational** — remediation within 1 quarter, tracked in vulnerability management
   - Define escalation process for overdue remediation

8. **Define tester qualifications:**
   - Required certifications (OSCP, CEH, GPEN, CREST, or equivalent)
   - Industry experience requirements (years, relevant sectors)
   - Background check and NDA requirements
   - Insurance requirements (professional liability, cyber insurance)
   - Preference for testers with experience in the organization's technology stack

9. **Write the artifact** to `.metapowers/security/$ARGUMENTS/pentest-plan.md` with heading:

   ## Penetration Test Plan

   Include sections:
   - **Test Type** — selected approach with rationale
   - **Scope** — in-scope and out-of-scope systems and test types
   - **Methodology** — selected testing standard and phases
   - **Rules of Engagement** — testing windows, contacts, prohibited techniques, and stop conditions
   - **Success Criteria** — coverage requirements and expected deliverables
   - **Reporting Requirements** — report structure, severity classification, and distribution
   - **Remediation Timeline** — expected fix timelines per severity level
   - **Tester Qualifications** — certification, experience, and contractual requirements

## Output

The penetration test plan written to `.metapowers/security/$ARGUMENTS/pentest-plan.md`. Present a summary to the user highlighting:
- Test type and scope definition
- Key rules of engagement and prohibited techniques
- Reporting and remediation timeline expectations
- Tester qualification requirements