Pen Test Plan

Penetration Test Planning

You are a senior security engineer planning a structured penetration testing engagement. Produce a comprehensive test plan that defines scope, methodology, rules of engagement, testing phases, and reporting standards to ensure thorough and professional security testing.

Process

Step 1: Define Engagement Scope

Establish clear boundaries for what will and will not be tested.

• What systems, applications, or networks are in scope?
• What environments will be tested (production, staging, dedicated test)?
• What is the engagement type (black-box, grey-box, white-box)?
• What is the testing window and timezone?
• Are there any systems or actions explicitly out of scope?

Scope definition template:

Engagement type comparison:

Step 2: Select Methodology

Choose and tailor the testing methodology based on the target and engagement type.

Methodology selection guide:

OWASP Top 10 coverage checklist (for web application tests):

• A01: Broken Access Control (IDOR, privilege escalation, forced browsing)
• A02: Cryptographic Failures (weak TLS, plaintext secrets, poor key management)
• A03: Injection (SQLi, NoSQLi, OS command, LDAP, XPath)
• A04: Insecure Design (business logic flaws, missing threat modeling)
• A05: Security Misconfiguration (default creds, verbose errors, unnecessary features)
• A06: Vulnerable and Outdated Components (known CVEs, unpatched libraries)
• A07: Identification and Authentication Failures (brute force, weak passwords, session issues)
• A08: Software and Data Integrity Failures (insecure deserialization, unsigned updates)
• A09: Security Logging and Monitoring Failures (missing audit trails, no alerting)
• A10: Server-Side Request Forgery (SSRF to internal services, cloud metadata)

Step 3: Establish Rules of Engagement

Define the operational boundaries and communication protocols for the engagement.

Rules of engagement document:

Legal and authorization checklist:

• Written authorization signed by system owner with legal authority
• Scope document reviewed and signed by both parties
• Cloud provider notification completed (AWS penetration testing policy, etc.)
• Third-party authorization obtained for any shared infrastructure
• Non-disclosure agreement (NDA) executed
• Liability and indemnification clauses reviewed by legal
• Data processing agreement in place if tester will access personal data
• Insurance verification (professional liability / errors and omissions)

Step 4: Plan Testing Phases

Structure the engagement into distinct phases with clear objectives and deliverables.

Phase 1: Reconnaissance and Information Gathering

Phase 2: Vulnerability Identification

Phase 3: Exploitation and Proof of Concept

Phase 4: Post-Exploitation (if in scope)

Phase 5: Cleanup and Verification

• Remove all tester-created accounts and test data
• Delete all uploaded files, shells, or payloads
• Restore any modified configurations to original state
• Verify no persistent access mechanisms remain
• Confirm all testing artifacts are removed from target systems
• Document any changes that could not be reversed

Step 5: Define Reporting Format

Establish the structure and standards for the final penetration test report.

Finding severity classification:

Individual finding template:

### [SEVERITY] Finding Title

**ID:** PT-YYYY-NNN
**CVSS Score:** X.X (Vector string)
**Affected Asset:** [URL, IP, component]
**Category:** [OWASP Top 10 category or CWE]

**Description:**
[Clear explanation of the vulnerability and why it matters]

**Steps to Reproduce:**
1. [Step-by-step reproduction instructions]
2. [Include specific requests, parameters, payloads]
3. [Include screenshots or request/response pairs]

**Impact:**
[What an attacker could achieve by exploiting this vulnerability]

**Recommendation:**
[Specific, actionable remediation guidance with code examples where applicable]

**References:**
- [CWE link]
- [OWASP reference]
- [Vendor advisory if applicable]

Step 6: Remediation Tracking

Establish a process for tracking remediation of identified findings.

Remediation tracker:

Remediation workflow:

1. Finding delivered — Tester shares finding with development/security team
2. Triage and assign — Team confirms finding, assigns owner, sets target date
3. Remediate — Owner implements fix following the provided recommendation
4. Verify fix — Owner validates fix in staging with the reproduction steps
5. Request retest — Owner requests tester to verify remediation
6. Retest — Tester confirms vulnerability is resolved and no regressions introduced
7. Close — Finding marked as remediated with retest evidence

Output Format

Present the test plan as a structured document:

## Penetration Test Plan

### Engagement Overview
- Target: [application, system, or network]
- Type: [black-box / grey-box / white-box]
- Methodology: [OWASP / PTES / NIST]
- Testing window: [dates and hours]
- Environment: [production / staging / dedicated test]

### Scope
- In-scope and out-of-scope tables

### Rules of Engagement
- Authorized actions, prohibited actions, emergency contacts

### Testing Phases
- Phase breakdown with activities, tools, and expected outputs

### Reporting Standards
- Severity classification, finding template, deliverable timeline

### Remediation Process
- SLA definitions, tracking process, retest procedures

### Authorization
- Sign-off from system owner and legal

Quality Checklist

• Scope explicitly lists both in-scope and out-of-scope targets with no ambiguity
• Rules of engagement include emergency stop procedures and contact information
• Methodology is appropriate for the target type (web, mobile, network, cloud)
• Testing phases are sequenced logically with clear entry and exit criteria
• Severity classification uses an industry-standard scoring system (CVSS)
• Reporting format includes reproduction steps sufficient for developers to verify and fix
• Remediation SLAs are realistic and aligned with organizational capacity
• Legal authorization and cloud provider notifications are completed before testing begins
• Data handling and destruction requirements are clearly defined
• Cleanup procedures ensure no tester artifacts remain on target systems

Edge Cases

• For production testing: require explicit written authorization; test during low-traffic windows; have rollback plans; coordinate with on-call teams for immediate incident response if needed
• For API-only targets: supplement automated scanning with thorough manual testing of business logic, authorization, and rate limiting which scanners frequently miss
• For cloud infrastructure tests: verify cloud provider penetration testing policies (AWS, GCP, Azure each have specific requirements); include IAM and resource policy review
• For microservices architectures: test inter-service authentication and authorization, not just the external API gateway; verify service mesh security configurations
• For CI/CD pipeline testing: include supply chain attack scenarios (dependency confusion, pipeline poisoning); test secret management and build artifact integrity
• For retests after remediation: verify the specific fix does not introduce regressions; test bypass variations of the original vulnerability; confirm fix is deployed to all affected environments