TL;DR:
- The penetration testing process involves multiple structured phases that simulate attacks to identify vulnerabilities within IT systems. It includes planning, discovery, attack, and reporting, each with clear inputs and outcomes. Properly scoped tests and verified retesting are essential for effective security improvements and compliance.
The penetration testing process is a defined series of structured phases that simulate real-world attack scenarios to identify, exploit, and report on security vulnerabilities within an organisation’s IT systems. Known formally as a penetration test or pen test, it differs from a vulnerability assessment by going one step further: testers actively attempt to exploit weaknesses to confirm their real-world impact. Frameworks such as NIST SP 800-115 and the Penetration Testing Execution Standard (PTES) define the accepted methodology for this work. Tools like Kali Linux and Tenable provide the technical infrastructure, but the process itself is what determines whether a test delivers genuine security improvement or merely a list of theoretical risks. Understanding the role of penetration testing within a broader cybersecurity programme is the starting point for any security professional or decision-maker commissioning this work.
What are the main phases of the penetration testing process?
Two frameworks define the accepted standard for structuring a pen test: NIST SP 800-115 and PTES. They differ in granularity but share the same underlying logic.
NIST SP 800-115 organises the process into four phases: planning, discovery, attack, and reporting. Each phase has defined inputs and outputs, making it well-suited to organisations that need a clear, auditable structure aligned with federal or regulatory standards.
PTES defines seven phases: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. The additional phases reflect a more granular view of attacker behaviour, particularly the emphasis on threat modelling before any technical work begins. This makes PTES the preferred reference for teams conducting advanced or red-team engagements.
The table below maps both frameworks side by side, showing the primary output of each phase.
| NIST SP 800-115 phase | PTES equivalent | Primary output |
|---|---|---|
| Planning | Pre-engagement | Signed scope and rules of engagement |
| Discovery | Intelligence gathering, threat modelling, vulnerability analysis | Asset inventory, threat model, vulnerability list |
| Attack | Exploitation, post-exploitation | Confirmed exploits, access paths, impact evidence |
| Reporting | Reporting | Risk-rated findings with remediation guidance |
The key practical difference is that PTES separates threat modelling from vulnerability analysis. That separation forces testers to think like an attacker before they pick up a scanning tool. Organisations following NIST SP 800-115 achieve compliance alignment; those following PTES achieve a closer simulation of real adversary behaviour. Many mature security teams use both, applying NIST’s structure for governance and PTES’s depth for technical execution.
Key activities within each phase include:
- Pre-engagement or planning: Define scope, obtain written authorisation, agree on rules of engagement, and confirm emergency contacts.
- Discovery or intelligence gathering: Conduct OSINT, network scanning, and service enumeration to map the attack surface.
- Threat modelling and vulnerability analysis: Identify likely attack paths and validate vulnerabilities through both automated scanning and manual review.
- Exploitation: Attempt controlled attacks to confirm which vulnerabilities are genuinely exploitable.
- Post-exploitation: Assess lateral movement, privilege escalation, and the realistic business impact of a successful breach.
- Reporting: Produce risk-rated findings with reproduction steps and prioritised remediation advice.
How are rules of engagement developed and why are they critical?
Rules of engagement (ROE) are the formal agreement that defines what testers are permitted to do, on which systems, and under what conditions. ROE documents must be signed before any testing begins. Without a signed ROE, testers operate without legal protection and organisations risk unintended disruptions to live systems.
A well-constructed ROE covers five core elements:
- Scope definition: Specific IP ranges, domains, applications, and physical locations included in the test.
- Permitted and prohibited techniques: Explicit approval for passive reconnaissance, active scanning, exploitation, and post-exploitation activities, each requiring separate sign-off.
- Emergency stop procedures: Named contacts and escalation paths if testing causes unintended service disruption.
- Data handling rules: How captured credentials, sensitive data, and test artefacts are stored, transmitted, and destroyed after the engagement.
- Reporting timelines: Agreed deadlines for interim updates and the final report.
Tiered permission levels are a critical feature of a mature ROE. Passive reconnaissance, which involves no direct interaction with target systems, carries minimal risk. Active exploitation of production systems carries significant risk. Each tier requires explicit written approval from the appropriate stakeholder. A legal team may approve passive reconnaissance while a CISO must separately authorise exploitation of critical infrastructure.
The ROE also acts as the operational boundary for compliance. Organisations subject to UK GDPR, PCI DSS, or ISO 27001 need documented evidence that testing was conducted within defined and authorised parameters. That evidence starts with the ROE. Security professionals working in regulated sectors should review penetration testing guidance for UK legal teams to understand the specific authorisation requirements that apply.
Pro Tip: Involve your legal counsel, data protection officer, and IT operations lead in drafting the ROE. Each stakeholder will identify risks the others miss, and their sign-off provides a complete chain of authorisation.
What happens during discovery, exploitation, and post-exploitation?
These three phases are where the penetration testing plan becomes active technical work. They are also where the most common mistakes occur.
-
Reconnaissance. Testers begin with OSINT: reviewing public DNS records, WHOIS data, LinkedIn profiles, job postings, and code repositories for exposed credentials or configuration details. Network scanning tools such as Nmap identify live hosts, open ports, and running services. Enumeration then extracts version information, user accounts, and share names from identified services.
-
Vulnerability analysis. Automated scanners such as Tenable Nessus or OpenVAS generate a list of potential vulnerabilities. Overreliance on automated scanners is a well-documented pitfall. Scanners produce false positives and miss context-dependent vulnerabilities that only manual analysis reveals. Effective testers use scanner output as a starting point, not a conclusion.
-
Exploitation. This is the defining step that separates a penetration test from a vulnerability assessment. Exploitation confirms real-world risk by demonstrating that a vulnerability can be used to gain unauthorised access. Controlled attacks are executed within the boundaries set by the ROE, using tools such as Metasploit for known exploit modules or custom scripts for bespoke vulnerabilities.
-
Post-exploitation. Once access is gained, testers assess what an attacker could realistically do next. This includes lateral movement across the network, privilege escalation to administrator or domain admin accounts, and data exfiltration simulations. The goal is to quantify business impact, not simply to demonstrate that a system was compromised.
-
Cleanup and evidence handling. Testers remove all testing scripts, logs, and artefacts from target systems at engagement closure. Failure to do so creates confusion for incident response teams and may constitute a data handling breach. Evidence collected during the test is retained securely for the report and then destroyed per the data handling terms in the ROE.
Pro Tip: Before running any exploitation attempts, confirm that system backups and disaster recovery plans are current. A pre-test readiness check with the IT operations team prevents accidental production outages from becoming a crisis.
How does reporting and retesting fit into the pen testing process?
The report is the deliverable that justifies the entire engagement. A technically excellent test produces no value if the findings are not communicated in a way that drives remediation.
Effective penetration testing reports address two distinct audiences simultaneously. Executives need an executive summary that translates technical risk into business impact: what data was accessible, what the regulatory exposure is, and what the remediation priority order should be. Technical teams and developers need reproduction steps, tool output, and specific configuration changes. PTES reporting standards require risk ratings, reproduction steps, business impact descriptions, and recommended mitigations for both audiences within a single document.
Risk prioritisation is the most consequential part of the report. Not all vulnerabilities carry equal weight. A critical vulnerability in an internet-facing authentication system outranks a medium-severity finding on an isolated internal server. Prioritisation should be based on exploitability, asset criticality, and potential business impact, not solely on CVSS scores.
The report should include:
- Executive summary: Business-language overview of findings, risk exposure, and recommended priorities.
- Technical findings: Each vulnerability with severity rating, reproduction steps, and evidence screenshots.
- Risk ratings: Mapped to a consistent scale such as CVSS or a bespoke organisational framework.
- Remediation guidance: Specific, actionable fixes for each finding, not generic advice.
- Retesting scope: A defined list of findings that require verification after remediation.
Retesting after remediation confirms that reported fixes are effective and that no regressions have been introduced. A paper fix, where a team marks a vulnerability as resolved without verifying the change in the live environment, is a common failure mode. Retesting closes that gap. Organisations that integrate retesting into the contractual scope of the engagement achieve a complete remediation loop rather than a one-time snapshot. This approach also supports ongoing compliance programmes, where evidence of verified remediation is required for audit purposes. Security teams should align their corporate data protection practices with the retesting cycle to maintain a continuous risk management posture.
Key takeaways
The penetration testing process delivers measurable security improvement only when each phase, from signed ROE through verified retesting, is executed with precision and documented for both technical and executive audiences.
| Point | Details |
|---|---|
| Framework selection matters | NIST SP 800-115 suits compliance-driven programmes; PTES suits advanced adversary simulation. |
| ROE is a legal requirement | Signed rules of engagement protect testers and organisations before any technical work begins. |
| Exploitation confirms real risk | Controlled attacks validate whether vulnerabilities are genuinely exploitable, not merely theoretical. |
| Reports serve two audiences | Executive summaries and technical findings must coexist in every report to drive remediation. |
| Retesting closes the loop | Verifying fixes in the live environment prevents paper remediation and supports audit evidence. |
What I have learned from running penetration tests in practice
The most consistent failure I see is not technical. It is scoping. Organisations commission a penetration test with a vague brief, and testers either over-reach into systems that were never intended for testing or miss critical assets entirely because they were not listed. A poorly scoped test wastes budget and produces findings that do not reflect the actual risk profile of the business.
The second failure is treating the report as the end of the engagement. Retesting is rarely included in the initial contract, which means organisations remediate findings without ever confirming the fixes work. I have seen critical vulnerabilities marked as resolved that remained fully exploitable because the patch was applied to the wrong environment. Building retesting into the contract from the outset is not optional for a mature security programme.
Automation has its place, but it does not replace judgement. Scanners like Nessus and OpenVAS are fast and consistent, but they cannot reason about business context. A scanner will flag a default credential on an isolated test server as critical. A skilled tester will recognise that the same default credential on a production payment system is existential. That distinction only comes from human analysis.
The future of pen testing will involve more automation at the reconnaissance and scanning stages, with AI-assisted tools accelerating the identification of attack paths. That will make the exploitation and post-exploitation phases more important, not less, because those are the phases where human judgement about business impact is irreplaceable. Organisations that invest in understanding the full stages of penetration testing now will be better positioned to evaluate and direct AI-assisted testing as it matures.
— Computer
How Computerforensicslab supports your penetration testing programme
Computerforensicslab provides digital forensics and cybersecurity services to organisations across the UK, including support for penetration testing engagements, post-test remediation, and digital evidence collection. Whether you need expert assistance structuring a penetration testing plan, managing the evidence chain after a test, or responding to a security incident uncovered during testing, the team brings forensic-grade rigour to every stage. Computerforensicslab also supports compliance requirements by producing documentation that meets chain-of-custody standards for regulatory audit and legal proceedings. To discuss your organisation’s cybersecurity assurance needs, contact the team directly through the Computerforensicslab services page.
FAQ
What is the penetration testing process?
The penetration testing process is a structured series of phases, typically including planning, reconnaissance, exploitation, post-exploitation, and reporting, that simulate real-world attacks to identify and validate security vulnerabilities in an organisation’s systems.
What are the five phases of penetration testing?
The five commonly referenced phases are pre-engagement, reconnaissance and discovery, vulnerability analysis, exploitation, and reporting. PTES expands this to seven phases by separating threat modelling and post-exploitation as distinct stages.
How does a penetration test differ from a vulnerability assessment?
A vulnerability assessment identifies and lists potential weaknesses; a penetration test goes further by actively attempting to exploit those weaknesses to confirm their real-world impact and assess the potential business damage of a successful breach.
Why are rules of engagement critical in pen testing?
Rules of engagement define the legal and operational boundaries of the test, including permitted techniques, scope, and emergency procedures. Without a signed ROE, testers lack legal protection and organisations risk unintended system disruptions or data handling breaches.
How often should organisations conduct penetration tests?
Most compliance frameworks, including PCI DSS and ISO 27001, require at least annual penetration testing. Organisations undergoing significant infrastructure changes, mergers, or new application deployments should commission additional tests outside the regular cycle.