“We already had a scan done last year” is something I hear more often than you'd think. An automated vulnerability scan and a professional penetration test are two fundamentally different things. A scan tells you which software versions have known flaws. A penetration test shows whether those flaws are actually exploitable — and what an attacker could realistically do with them. That difference emerges across five clearly defined phases.

Phase 1 — Scoping & Target Definition

Before anything is tested, client and tester jointly define in writing what may be examined. This isn't a formality — without this agreement, the exact same activity would be legally indistinguishable from a real attack. This phase defines which systems, domains, or IP ranges are in scope, which methods are excluded, the testing window, the escalation path for critical findings, and points of contact on both sides.

The outcome is a signed scope document (rules of engagement) that legally protects both parties.

Phase 2 — Reconnaissance & Enumeration

Now it's time to systematically map what's visible from the outside — and, where agreed, from the inside too: open services, technologies in use, subdomains, configurations. This mirrors exactly what a real attacker would do first. The difference: everything stays within the agreed scope, and it gets documented rather than exploited.

This phase results in a structured overview of the attack surface, along with an initial prioritization of possible weak points.

Phase 3 — Exploitation

Only now are identified vulnerabilities exploited in a controlled way — not to cause damage, but to demonstrate their real-world impact. This is what actually separates a penetration test from a plain scan: a scanner reports “version X is vulnerable.” A tester shows whether and how that translates into actual data access or privilege escalation.

Manual, targeted verification of every finding — not raw scanner output passed along unfiltered.

Critical or potentially destructive tests are discussed with the client in advance. Actively exploitable, critical gaps are reported immediately — even before the rest of the test is complete.

Phase 4 — Reporting

The report is the actual deliverable of a penetration test. It's written so both technical teams and decision-makers without an IT background understand what was found and what to do about it. That includes a plain-language management summary, every finding with a risk rating, evidence, and a concrete recommendation, plus a prioritized order for remediation.

A good report reliably answers two questions: how bad is it, really — and what should I fix first?

Phase 5 — Retest

After remediation, testers verify whether the reported vulnerabilities are genuinely closed — not just whether some change was made. In practice, this step is often skipped because the budget for the original test has already run out. But it's exactly where you find out whether findings actually turned into security.

Conclusion

This phase structure is based on recognized frameworks such as the OWASP Testing Guide and the BSI penetration testing methodology — adapted to each individual engagement rather than applied as a rigid template. Once you understand this, it's easy to spot the difference between a genuine offer and a repackaged scan: look at the depth of phase 3, and whether phase 5 is even included.