security
Penetration Test Plan Prompt
Penetration tests without a detailed plan often miss systematic coverage of all attack vectors. This prompt creates a structured test plan aligned with OWASP methodology that ensures consistent coverage and produces a report structure that satisfies compliance requirements. The rules of engagement section is critical for preventing misunderstandings about what testers are permitted to do.
Prompt Template
You are a senior penetration tester with expertise in web application and API security.
Create a penetration test plan for the following target:
Target system: {{target}}
Scope: {{scope}}
Out of scope: {{out_of_scope}}
Testing type: {{testing_type}}
Timeline: {{timeline}}
Known tech stack: {{tech_stack}}
Special requirements: {{requirements}}
Provide a comprehensive pentest plan including:
1. **Objective** — what the test is designed to achieve
2. **Methodology** — testing framework (OWASP WSTG, PTES, etc.)
3. **Test phases** — with estimated hours per phase
4. **Test cases** — specific tests grouped by category (auth, injection, access control, etc.)
5. **Tools list** — recommended tools for each test category
6. **Rules of engagement** — what is permitted and what requires prior approval
7. **Reporting structure** — sections of the final report and delivery timelineVariables
{{target}}The target system, e.g., "web application at app.example.com", "REST API at api.example.com"{{scope}}What is in scope, e.g., "all endpoints under api.example.com, authentication flows"{{out_of_scope}}What is explicitly excluded, e.g., "third-party payment processor, AWS infrastructure"{{testing_type}}Black box, grey box, or white box testing{{timeline}}Duration, e.g., "5 days", "2 weeks"{{tech_stack}}Known technology stack{{requirements}}Special requirements, e.g., "compliance with PCI DSS assessment requirements", or "None"Example
Input
target: REST API at api.example.com for a fintech application scope: All API endpoints, authentication, and authorisation flows out_of_scope: Payment processor (Stripe), AWS infrastructure, social login providers testing_type: grey box (API documentation provided) timeline: 5 days tech_stack: Node.js, PostgreSQL, JWT authentication requirements: Must satisfy PCI DSS requirement 11.3
Output
**Phase 1 — Reconnaissance (4h)** - Map all API endpoints from documentation and dynamic discovery - Identify authentication mechanisms and session management - Tools: Burp Suite, ffuf, jwt.io **Phase 2 — Authentication Testing (8h)** - Test for: credential stuffing, brute force, JWT vulnerabilities, OAuth flows - OWASP WSTG-AUTHN-* test cases **Phase 3 — Authorisation Testing (8h)** - IDOR testing across all resource endpoints - Horizontal and vertical privilege escalation - OWASP WSTG-ATHZ-* test cases
Related Tools
FAQ
- What is the difference between black box, grey box, and white box testing?
- Black box: tester has no prior knowledge (simulates external attacker). Grey box: tester has limited information like API docs or a user account (most common). White box: tester has full access to source code and architecture (most thorough).
- Do I need a written agreement before a pentest?
- Always. A signed scope agreement (Statement of Work) defining exactly what is and is not permitted protects both parties legally. Without it, legitimate testing could be indistinguishable from actual attacks.
- How do I prioritise findings in the pentest report?
- Use CVSS v3 scoring as a baseline, then adjust for business context: a medium-CVSS finding that exposes customer PII should be raised to critical. The AI-generated test plan includes a severity matrix for this purpose.
Related Prompts
Threat Modeling Prompt
Threat modeling is most valuable when done during design, not after implementation. This p...
Security Code Audit PromptSecurity audits require a systematic approach that covers every vulnerability category, no...
Dependency Vulnerability Check PromptDependency audits are most valuable when they prioritise by actual impact rather than just...