September 24, 2026
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
Salman Khan
New Update: Our new blog is updated.
Free download
Fiza Nadeem is an SEO content writer at ioSENTRIX with 2.5+ years of experience in content writing, copywriting, and SEO.
The stages of penetration testing are the ordered steps a tester follows to turn an authorized attack into evidence: reconnaissance, scanning, vulnerability assessment, exploitation and reporting. Every serious methodology, whether the seven phases of the Penetration Testing Execution Standard (PTES) or the four phases in NIST SP 800-115, is a variation on that same sequence. The names change; the work does not.
This guide walks through each stage of the penetration testing process, shows how the five-stage model maps to PTES and NIST, and answers the question buyers ask most often: what happens in the last stage, and what should you get out of it.
The stages of penetration testing are the five phases a tester moves through in order: reconnaissance (learning about the target), scanning (probing it for live hosts, ports and services), vulnerability assessment (deciding which weaknesses are real and exploitable), exploitation (proving impact by using them) and reporting (documenting what was found, how bad it is and how to fix it). Some methodologies split these into more phases or fold them into fewer, but every penetration test includes this work in this order.
The Penetration Testing Execution Standard describes seven sections. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, describes four, and notes that there are "many acceptable ways of grouping the actions involved in performing penetration testing." What separates a penetration test from a vulnerability scan is not the number of boxes on the diagram. It is that a human tester carries a finding all the way from discovery to proven impact. If you want the basics first, start with what a penetration test is.
No. "Penetration testing steps," "stages of penetration testing" and "penetration testing phases" describe the same process, and vendors and standards use the words interchangeably. PTES calls its seven parts sections, NIST SP 800-115 calls its four parts phases, and most training material calls the five-part version stages or steps.
The only distinction worth keeping is between the phases of a test and the steps inside a phase. Reconnaissance is a phase. Pulling DNS records and searching public code repositories for leaked keys are steps inside it. When someone asks for "the steps of a penetration test," they usually want the phases.
Each phase feeds the next: reconnaissance tells scanning where to look, scanning tells vulnerability assessment what to examine, vulnerability assessment tells exploitation what to try, and exploitation gives reporting its evidence. Skipping a phase produces a report with findings nobody has proven.
Reconnaissance is the information-gathering phase. The tester builds a picture of the target before sending a single hostile packet: domains and subdomains, IP ranges, mail and DNS configuration, exposed services, cloud accounts, employee names and roles, technology choices and anything already leaked on the public internet.
Most of this is passive, built on open-source intelligence. An organization rarely knows its own full external footprint, and forgotten assets are where attackers start. Our two-part series on how OSINT is used in cybersecurity covers the techniques in depth. In PTES terms, this stage covers intelligence gathering and the start of threat modeling: deciding which assets matter and which attacker would want them.
Scanning is the active probing phase. The tester sends traffic to the in-scope systems to identify live hosts, open ports, running services and their versions, web technologies and, for applications, the pages, parameters and API endpoints that make up the attack surface. Network mappers, port scanners and web crawlers do most of the mechanical work.
Scanning also includes watching how the target behaves. Error messages, rate limits and inconsistent headers all hint at what sits behind the front door. The output is a map of entry points for the next phase to examine.
Vulnerability assessment is the analysis phase. The tester compares the services, versions and behaviors found in scanning against known weaknesses, misconfigurations and design flaws, then decides which ones are likely to be real and worth attempting. Automated scanners produce the first list; manual review removes the false positives and adds the flaws scanners cannot see, such as broken access control and business logic errors.
This is the phase most often mistaken for the whole test. A vulnerability assessment on its own tells you what might be wrong. It does not tell you what an attacker can do about it, which is why our comparison of vulnerability assessment vs penetration testing matters when you read proposals.
Exploitation is the proof phase. The tester attempts to use the vulnerabilities identified in stage 3 to gain access, escalate privileges, reach sensitive data or move to other systems, within the limits set in the rules of engagement. A successful exploit converts a "possible" finding into a confirmed one with evidence.
Post-exploitation is what happens after the first foothold. NIST SP 800-115 describes it as a loop: an exploit rarely grants maximum access on its own, so the tester escalates privileges, installs tools to reach further, and returns to discovery to find the next step. PTES separates this into its own phase. The point is to answer the question the business cares about: if this one flaw is used, how far does it go? A single medium-severity finding that chains into domain admin is not a medium.
Reporting is the delivery phase, and the only part of the test most of the organization will ever see. A good report contains an executive summary written for people who will not read the rest, each finding with its evidence and reproduction steps, a severity rating with the reasoning behind it, specific remediation guidance, and a mapping to any compliance framework the test was meant to support. Our glossary entry on the penetration testing report lists what to expect.
NIST SP 800-115 notes that reporting runs alongside the other phases, not only at the end: the rules of engagement are written in planning, logs are kept throughout, and the final report describes the vulnerabilities, gives a risk rating and explains how to mitigate them. A report that arrives weeks after testing ended, with no interim notice of critical findings, is a warning sign.
The Penetration Testing Execution Standard defines seven phases: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting. It is the most widely cited penetration testing methodology, and the five-stage model above is a compression of it, not a competitor.
The mapping is direct. PTES pre-engagement interactions, the scoping and rules-of-engagement work, happen before stage 1. Intelligence gathering and threat modeling are stage 1. Vulnerability analysis covers stages 2 and 3. Exploitation and post-exploitation are stage 4. Reporting is stage 5. The two phases PTES makes explicit and the five-stage model leaves implicit, pre-engagement and post-exploitation, are the two that most often go wrong in cheap tests. Our guide to rules of engagement in penetration testing covers the first; we cover the seven-stage view from a business perspective in What Are the 7 Stages of Penetration Testing for Businesses?
NIST SP 800-115 groups penetration testing into four phases: planning, discovery, attack and reporting. Planning sets rules, secures management approval and defines goals, and no testing happens in it. Discovery covers information gathering, scanning and vulnerability analysis, which is stages 1 through 3 above. Attack is stage 4, and the standard draws a feedback loop from attack back to discovery to show that each foothold produces new targets. Reporting is stage 5, running in parallel with everything else.
OWASP does not define phases for a penetration test in general. What it provides is the test content for specific targets. The OWASP Web Security Testing Guide describes what to test in a web application or web service, and it slots into stages 2 through 4 of any engagement that includes a web target. A tester who says they "follow OWASP" is describing their test cases, not their process; a tester who says they follow PTES or NIST SP 800-115 is describing their process. You want both, and the answer to "which one?" depends on what is in scope. For US federal and defense contexts, our guide to NIST-compliant penetration testing explains how SP 800-115 fits with SP 800-53 control CA-8.
The last stage of a penetration test is reporting, followed by remediation and a retest. Reporting delivers findings, evidence, severity and fixes. Remediation is your work. The retest, which the provider performs after you have fixed the findings, confirms that each fix closed the issue and produces the updated report or attestation letter that auditors and customers ask for.
Treat the retest as part of the engagement, not an optional extra. A finding marked "fixed" by the team that introduced it is an assertion. A finding marked "fixed" by the tester who originally exploited it and now cannot is proof.
Every type of penetration test follows the same five stages; what changes is the starting position and the target. An external test starts from the internet with no access. An internal test starts from inside the network, modeling a compromised workstation or a malicious insider. Our comparison of internal vs external network penetration testing explains when you need each.
Starting knowledge varies too. A black-box tester knows little more than the company name, so reconnaissance is long. A gray-box tester gets a low-privilege account or architecture notes, which shortens stages 1 and 2 and spends the time on exploitation. A white-box tester has source code or full configuration access. The stages are identical; the budget shifts between them. The same holds across targets: a web application penetration test, a cloud test and an AI and ML penetration test all run reconnaissance through reporting with different tooling and test cases in the middle.
The five stages of penetration testing are reconnaissance, scanning, vulnerability assessment, exploitation and reporting. Reconnaissance gathers information about the target, scanning probes it for live services and entry points, vulnerability assessment identifies which weaknesses are real, exploitation proves what an attacker could do with them, and reporting documents the findings with evidence, severity and remediation steps.
The seven stages come from the Penetration Testing Execution Standard: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting. They cover the same work as the five-stage model but break out scoping at the start and post-exploitation in the middle as phases of their own.
Nothing in substance. The seven PTES phases add pre-engagement (scoping, authorization and rules of engagement) before reconnaissance and separate post-exploitation from exploitation. The five-stage model treats scoping as a precondition rather than a stage and folds post-exploitation into exploitation. A provider can describe its process either way and still run the same test.
NIST SP 800-115 describes a four-phase penetration testing process: planning, discovery, attack and reporting. Planning sets the rules and goals, discovery covers information gathering, scanning and vulnerability analysis, attack verifies vulnerabilities by exploiting them and loops back to discovery as new access is gained, and reporting runs throughout the test and produces the final findings, risk ratings and mitigation guidance.
At least annually and after any significant change to the systems in scope. PCI DSS, for example, requires penetration testing at least once every 12 months and after significant infrastructure or application changes, and most other frameworks and auditors expect a similar cadence. Organizations that ship continuously often pair an annual full test with continuous penetration testing of what changed.
ioSENTRIX is a CREST-accredited penetration testing firm, ISO/IEC 27001 certified and SOC 2 Type 2 attested. Our penetration testing engagements follow the stages described here, aligned to PTES and NIST SP 800-115 and using OWASP test content for application targets, across web and API, mobile, cloud, network, ICS and IoT, embedded and AI and ML penetration testing. Every finding is exploited where it is safe to do so, reported with evidence and reproduction steps, and retested after you fix it. We do not check whether a control exists; we prove whether it works.
If you want to see what the five stages produce against your own environment, talk to us about scoping a test.
