Steps of Pentesting: What Most Guides Get Wrong About the Process

The Steps of Pentesting Are Simple. Executing Them Isn't.

Every guide lists the same steps of pentesting: recon, scanning, exploitation, post-exploitation, reporting. You already know this. What nobody tells you is that 80% of failed pentests die in the first two phases because testers rush to exploitation before they actually understand the target.

The 2023 Equifax retrospective showed their original security assessments missed the Apache Struts vulnerability (CVE-2017-5638) not because scanners couldn't find it — but because the scope definition was sloppy and the asset wasn't even in the testing inventory. Process failures, not tool failures.

Let's walk through the real phases, focusing on where people actually mess up.

Phase 1: Scoping and Rules of Engagement

This isn't a formality. This is where you decide whether the pentest will be useful or theater. Most guides skip this entirely or call it "pre-engagement."

• Define what's off-limits explicitly. Production databases? Third-party integrations? If it's not written down, assume it'll cause a problem.
• Agree on testing windows. A pentest that triggers a PagerDuty storm at 2 AM destroys trust with engineering teams.
• Clarify the goal. "Find vulnerabilities" is not a goal. "Determine if an unauthenticated attacker can access customer PII through the public API" is a goal.

Phase 2: Reconnaissance — Go Deeper Than You Think

Recon is where good pentesters separate themselves. Amateurs run nmap and move on. Professionals spend 40-60% of their total time here.

Passive recon that actually matters:

• Search GitHub for leaked API keys, old config files, internal docs. Use trufflehog or gitleaks against the org's public repos.
• Check DNS records, certificate transparency logs (crt.sh), and archived versions on the Wayback Machine.
• Look at job postings — they reveal tech stacks, frameworks, and sometimes internal tool names.

Active recon done right:

# Don't just scan ports. Fingerprint services and versions.
nmap -sV -sC --script=vuln -oA target_scan 10.0.0.0/24

# Enumerate web directories with context-aware wordlists
feroxbuster -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt --smart

The output of this phase should be a detailed asset map, not just a list of open ports.

Phase 3: Exploitation — Precision Over Spray-and-Pray

Here's the counterintuitive part: the best pentesters exploit fewer vulnerabilities, not more. They pick the chain that proves maximum business impact.

Consider this vulnerable Node.js endpoint versus its fixed version:

// VULNERABLE: User input directly in SQL query
app.get('/user', (req, res) => {
  const query = `SELECT * FROM users WHERE id = '${req.query.id}'`;
  db.query(query);
});

// FIXED: Parameterized query
app.get('/user', (req, res) => {
  const query = 'SELECT * FROM users WHERE id = ?';
  db.query(query, [req.query.id]);
});

Finding this SQL injection matters. But chaining it with a privilege escalation to dump admin credentials? That's what makes the report impossible to ignore.

Phase 4: Reporting — Where Value Is Delivered

The pentest itself is worthless if the report doesn't drive action. Yet most reports are 80-page PDFs that nobody reads.

What works:

• Executive summary: 1 page max. Business impact in plain language. No CVSS scores here.
• Technical findings: Each finding gets a reproduction path (exact curl commands or screenshots), impact assessment, and a specific fix — not "apply patches."
• Prioritized remediation: Rank by exploitability × business impact, not just severity. A critical CVE on an internal-only dev server is less urgent than a medium-severity auth bypass on your payment API.

Tools like PreBreach can help catch common web vulnerabilities continuously between formal pentests, so your next engagement focuses on deeper logic flaws instead of rediscovering the same XSS.

What to Do Right Now

1. Audit your last pentest scope document. If it doesn't have explicit goals, testing windows, and exclusions — rewrite it before your next engagement.
2. Run gitleaks against your own public repos today. You'll probably find something. Fix it, then rotate those credentials.
3. Read your last pentest report's executive summary. If a non-technical executive couldn't act on it, demand better from your next tester.