Penetration Testing Checklist: Phases, Tools, and What to Expect

A penetration test (pentest) is an authorized simulated attack on your systems to identify security vulnerabilities before malicious actors do. Unlike automated vulnerability scanning, a pentest involves human intelligence — a skilled tester probes for logic flaws, chains vulnerabilities, and attempts to achieve a specific objective (e.g., access admin functions, exfiltrate data).

This guide explains the types, phases, and tools involved, and what your team should do before and after a pentest.

Types of Penetration Tests

By Knowledge Level

Type	What the tester knows	Best for
Black Box	Only the target domain/IP	Realistic external attacker simulation
Grey Box	Some information (API docs, user credentials, architecture overview)	Most efficient; balances realism with thoroughness
White Box	Full access to source code, architecture, credentials	Deepest coverage; code-level findings

Most web application pentests are grey box: the tester has credentials for different user roles and access to API documentation, but no source code.

By Scope

Web Application Pentest: Focuses on a specific web application — authentication, authorization, business logic, injection, session management. Follows OWASP Testing Guide (OTG) methodology.

External Network Pentest: Tests your public-facing infrastructure — internet-accessible servers, firewalls, VPNs, cloud infrastructure. Focuses on CVE exploitation, misconfigurations.

Internal Network Pentest: Tests your internal network assuming an attacker has gained initial access (simulates a compromised employee or supply chain attack). Focuses on lateral movement, privilege escalation, Active Directory attacks.

Red Team: A full attack simulation with a specific objective (e.g., steal customer data, access the finance system). Uses all attack vectors — phishing, physical access, technical exploitation. More realistic but more expensive.

Cloud Infrastructure Pentest: Focuses on your AWS/GCP/Azure configuration — IAM misconfigurations, exposed services, S3 buckets, metadata service exploitation.

API Pentest: Focused specifically on REST/GraphQL APIs — authentication bypass, broken object-level authorization (BOLA), mass assignment, rate limiting.

The 5 Phases of Penetration Testing

Phase 1: Reconnaissance

The tester gathers information about the target without directly interacting with it (passive) or by probing it (active).

Passive reconnaissance:

# WHOIS, DNS records
whois yourdomain.com
dig ANY yourdomain.com

# Certificate Transparency for subdomain enumeration
curl "https://crt.sh/?q=%.yourdomain.com&output=json" | jq -r '.[].name_value' | sort -u

# Shodan for internet-facing assets
# (manual research, not shown here)

# LinkedIn/social: employee names, tech stack hints
# GitHub: leaked credentials, API keys, architecture hints

Active reconnaissance:

# Port scanning
nmap -sV -sC -oA scan-results yourdomain.com

# Subdomain enumeration with brute force
subfinder -d yourdomain.com -all
amass enum -active -d yourdomain.com

# Web content discovery
ffuf -w /usr/share/wordlists/dirb/common.txt -u https://yourdomain.com/FUZZ
gobuster dir -u https://yourdomain.com -w wordlist.txt

Phase 2: Scanning and Vulnerability Assessment

Testers use the information from recon to identify specific vulnerabilities.

# Web vulnerability scanning
nikto -h https://yourdomain.com

# Automated web app scanning
nuclei -u https://yourdomain.com -t cves/ -t exposures/ -t misconfigurations/

# SSL/TLS testing
testssl.sh yourdomain.com

# Technology fingerprinting
whatweb https://yourdomain.com
wappalyzer (browser extension)

Phase 3: Exploitation

Manually verify and exploit identified vulnerabilities to determine actual impact.

Common web app exploitation with Burp Suite:

Intercept and modify requests
Test for SQL injection: ' OR 1=1--, UNION attacks
Test authentication: password spray, credential stuffing, token manipulation
Test authorization: IDOR (change user IDs), vertical privilege escalation (access admin endpoints as regular user)
Test for SSRF, XXE, file upload vulnerabilities
Business logic flaws (negative prices, skip payment steps, coupon stacking)

# Manual SQL injection testing
sqlmap -u "https://yourdomain.com/api/users?id=1" --dbs --batch

# Cross-site scripting
# Test in all input fields: <script>alert(1)</script>
# DOM-based: javascript:alert(1) in URL parameters

# Authentication testing
hydra -l admin -P /usr/share/wordlists/rockyou.txt yourdomain.com http-post-form \
  "/api/auth/login:username=^USER^&password=^PASS^:Invalid credentials"

Phase 4: Post-Exploitation

After gaining initial access, testers attempt to:

Escalate privileges
Move laterally to other systems
Access sensitive data
Establish persistence
Exfiltrate data (to demonstrate blast radius)

The goal is not just to find a vulnerability but to demonstrate the real-world impact of exploiting it.

Phase 5: Reporting

The deliverable of a pentest. A good pentest report includes:

Executive Summary:

Overall risk rating (Critical/High/Medium/Low)
Number of findings by severity
Key narrative: "An attacker could access all customer PII by exploiting finding #1 and chaining it with finding #3"

Technical Findings (for each finding):

Title and CVE reference (if applicable)
Severity (CVSS score + business impact)
Affected component
Description of the vulnerability
Step-by-step proof of concept (screenshots, HTTP requests/responses)
Business impact
Remediation recommendation
References

Methodology: What was tested, what was out of scope, testing dates.

Before the Pentest: Scope Definition

The scope document is critical. Define:

In scope:
- api.yourdomain.com (all endpoints)
- app.yourdomain.com
- admin.yourdomain.com (with admin credentials provided)
- AWS account ID: 123456789 (IAM assessment, S3 review)

Out of scope:
- yourdomain.com (marketing site, separate team)
- third-party services (Stripe, Auth0)
- Physical premises
- Social engineering / phishing

Testing window: 2026-01-15 to 2026-01-26
Start/end times: 9am–6pm PST (business hours only)

Rules of engagement:
- No denial of service testing
- Do not test accounts not provided for the engagement
- Notify security@yourdomain.com if critical vulnerabilities found during testing
- Do not modify or delete production data

Sign a written engagement agreement before any testing begins. This protects both parties legally.

After the Pentest: Remediation

Triage findings: Assign severity and owner for each finding
Critical and High: Fix before the report is finalized or within 30 days
Mediums: Fix within 90 days
Request a retest: Good pentest firms offer a retest of fixed findings at no additional cost within the engagement period
Track remediation: Use a ticket tracker (Jira, Linear) with due dates
Don't shelve the report: The biggest pentest failure is spending $20k on a report and then doing nothing with it

Frequency

Scenario	Recommended frequency
No pentest history	Start immediately
Normal SaaS	Annual
Processing payment cards (PCI-DSS)	Annual minimum
Healthcare (HIPAA-sensitive)	Annual + after major changes
After major architecture changes	On-demand
SOC 2 Type 2	Annual (required for most auditors)
Enterprise deal requires it	Before close