What Is Penetration Testing? A Practical Guide to the Seven Stages

Penetration testing is an authorized, time-bounded attempt to find and safely prove weaknesses in a system. A tester thinks like an attacker, but operates under written rules, minimizes harm, preserves evidence, and produces remediation advice.

That definition matters because a pentest is not simply a vulnerability scan. A scanner can report that software appears outdated. A penetration tester investigates whether the condition is real, whether it is reachable, what an attacker could achieve, and which control would break the attack path.

The short answer

A professional pentest usually moves through seven connected stages:

1. Pre-engagement and scoping
2. Intelligence gathering
3. Threat modeling
4. Vulnerability analysis
5. Exploitation
6. Post-exploitation
7. Reporting and retesting

These align with the Penetration Testing Execution Standard, while NIST SP 800-115 frames technical testing around planning, conducting tests, analyzing findings, and developing mitigation strategies.^[1][2]

Pentesting, vulnerability scanning, and red teaming are different

A vulnerability assessment prioritizes breadth. It identifies and classifies as many weaknesses as practical. A penetration test prioritizes validation: can a realistic attacker turn a weakness into meaningful impact? A red-team exercise tests detection and response against an objective, often through several technical and human pathways over a longer period.

Imagine an internet-facing application with an old library:

• A scanner identifies the version and maps it to a CVE.
• A pentester verifies the version, reachability, prerequisites, compensating controls, and safe proof of impact.
• A red team may use that or another route to pursue an agreed objective while the defenders attempt to detect and contain the activity.

The labels are sometimes used loosely in sales material. The rules of engagement and deliverables tell you what the work actually is.

Stage 1: Pre-engagement and scoping

The most important pentest work happens before the first packet reaches a target.

The client and testing team define:

• business objectives;
• included IP ranges, domains, applications, APIs, accounts, and locations;
• excluded systems and third-party services;
• allowed and prohibited techniques;
• testing windows and traffic limits;
• data handling and retention;
• emergency contacts and stop conditions;
• reporting and retest expectations.

This is more than paperwork. If shop.example.com uses a third-party payment provider, permission to test the shop does not automatically include the provider. If availability is critical, even an ordinary content-discovery scan may need a conservative rate limit.

The output is a shared definition of safe success.

Stage 2: Intelligence gathering

The tester builds a model of the exposed environment. Passive reconnaissance may use public records, certificates, documentation, code repositories, and search results. Active reconnaissance directly queries authorized targets through DNS resolution, host discovery, port scanning, or application browsing.

The goal is not to gather trivia. It is to answer useful questions:

• What assets exist?
• Which ones accept traffic?
• Which technologies and trust boundaries are visible?
• Where does identity enter the system?
• Which assets look forgotten, privileged, or unusually exposed?

A good asset table records the source and confidence of each observation. A hostname that contains admin is a lead, not proof of an administration interface.

Stage 3: Threat modeling

Threat modeling connects assets to plausible attackers and consequences. A public marketing site and an employee identity portal may share a technology stack but have different threat priorities.

For each target, consider:

• valuable data and actions;
• likely attacker access and capability;
• entry points and trust boundaries;
• privileged workflows;
• defensive controls;
• business consequences of control failure.

MITRE ATT&CK can help describe observed behavior using a common vocabulary. Its enterprise knowledge base organizes adversary activity from reconnaissance and initial access through lateral movement, exfiltration, and impact.^[3] ATT&CK is not a pentest checklist; it is a useful map for reasoning about behaviors and coverage.

Stage 4: Vulnerability analysis

Now the tester turns observations into hypotheses. An exposed service, unusual response, permissive role, or version match may deserve investigation.

This stage combines tools with judgment:

• scan results are manually verified;
• false positives are removed;
• configuration is compared with intended policy;
• application roles and object ownership are tested;
• potential weaknesses are ranked by feasibility and impact.

The OWASP Web Security Testing Guide groups application tests around areas such as identity, authentication, authorization, sessions, input validation, business logic, client-side behavior, and APIs.^[4] Its value is coverage: it helps testers avoid focusing only on familiar injection payloads.

Stage 5: Exploitation

Exploitation proves that a security boundary can be crossed. It should use the minimum action needed to establish the finding.

For example, suppose User B can request User A’s invoice by changing /api/invoices/1841 to /api/invoices/1842. A safe proof might retrieve one synthetic test invoice, record the authorization failure, and stop. Downloading every invoice adds harm without improving the proof.

Professional exploitation follows three rules:

1. Stay within the authorized target and technique.
2. Stop once evidence is sufficient.
3. Record exact, reproducible steps.

An exploit succeeding once is not the whole result. The tester must also identify prerequisites, affected population, reliability, and relevant defensive controls.

Stage 6: Post-exploitation

Post-exploitation asks what the proven access means. Depending on permission, a tester may evaluate:

• reachable data;
• privilege escalation;
• credential exposure;
• segmentation boundaries;
• lateral movement;
• persistence risk;
• paths to a defined business objective.

This stage is especially sensitive. Access to one credential does not imply permission to use it everywhere. Persistence should never be established merely because it is technically possible.

The most useful outcome is often an attack path:

Exposed repository
  → low-privilege service credential
  → readable build logs
  → deployment secret
  → unauthorized production change

Every arrow should be labeled as observed, validated, or hypothetical.

Stage 7: Reporting and retesting

The report is the product. A finding should tell both decision-makers and implementers:

• what failed;
• where it failed;
• how it was safely reproduced;
• what an attacker could achieve;
• how likely that path is in context;
• how to correct the root cause;
• how to verify the correction.

A severity score is useful, but it cannot replace explanation. The same technical flaw may be minor in a disposable test environment and critical in a tenant-isolated financial service.

During retesting, the tester checks more than whether the original request now returns an error. A sound retest includes a negative test—unauthorized access fails—and a positive test—authorized use still works.

What a pentest cannot prove

A pentest samples a changing system during a limited period. It cannot prove that no vulnerabilities exist. It may miss dormant code, rare race conditions, recently introduced assets, or paths excluded by scope.

That limitation is not a failure. Pentesting is one control within a larger program that also needs secure design, code review, dependency management, configuration assurance, logging, monitoring, incident response, and recurring validation.

A practical quality checklist

A credible penetration test has:

• written authorization and a precise scope;
• methods proportionate to system risk;
• manual validation of important results;
• clear separation of fact and inference;
• minimal collection of sensitive data;
• reproducible evidence;
• remediation tied to root causes;
• a retest path.

If a provider cannot explain these elements, a long list of tools will not compensate.

Build your own reference system

Pentesting becomes easier when definitions, tool syntax, and field workflow live in one linked knowledge base. The free CyberVault sample includes detailed notes on scope, rules of engagement, reconnaissance, scanning, access control, common web flaws, Nmap, Burp Suite, and evidence-driven field practice.

Sources