The Pentesting Process: Step-by-Step Guide

The Pentesting Process: Step-by-Step

Penetration testing is a simulated cyber attack against your systems, network, or web applications, performed with explicit authorisation to identify and prove exploitable vulnerabilities.

This guide walks through scoping, testing, and reporting so you can commission an authorised engagement with a clear view of each phase.

The aim is TEST. FIND. FIX. PROTECT.: prove real risk, then close it.

What Is Penetration Testing?

Penetration testing is a simulated cyber attack against your systems, network, or web applications, performed with explicit authorisation to identify and prove exploitable vulnerabilities. A vulnerability scan lists potential weaknesses. A pentest attempts exploitation so you can see whether those weaknesses actually lead to access, data exposure, or control.

Authorised pentesting is legal. The authorisation is the difference. In the UK, unauthorised access is a criminal offence under the Computer Misuse Act 1990. A signed rules of engagement document records the system owner's consent, the in-scope assets, and the limits of the test. Without that written consent, the activity is not a pentest.

Pentesting Company works from London, UK, and treats that written consent as the legal backbone of every engagement, not a formality. Organisations often commission this work to support programmes such as ISO 27001, PCI DSS, or Cyber Essentials Plus, but the engagement itself remains a scoped technical test, not an audit certificate.

Scan versus pentest: a scan reports possible issues. A pentest proves impact under agreed rules, then documents evidence you can remediate. If you only need a known-CVE inventory, a scan may be enough. If you need proof that an attacker can actually reach data or control, you need a pentest.

Phase 0: Scoping and Rules of Engagement

Phase 0 is the pre-engagement work that defines what may be tested, who authorises it, and how testers stop if something goes wrong. Scoping is the most important phase. Without a clear scope, the test is either too broad or too narrow to be useful.

Most published walkthroughs start at reconnaissance. In a professional engagement, no packet is sent until this phase is written down.

Scoping meetings lock the asset list: IP ranges, applications, environments, and out-of-bounds systems. Rules of engagement set testing hours, data handling, notification rules, and emergency contacts. Legal sign-off and a scheduled window follow before any packet is sent.

Ask which methodology the provider follows (for example PTES or OWASP for web applications) so the walkthrough you buy matches a documented process, such as our pentesting methodology. You can start a scoped engagement with an authorised penetration testing provider once those documents are agreed.

Client pre-engagement checklist

• Asset inventory (hosts, apps, APIs, cloud accounts)
• Network diagrams and environment labels (production, staging)
• Named emergency contacts and escalation path
• Agreed testing window and change freeze if needed
• Written in-scope and out-of-scope definition
• Signed authorisation from the system owner
• Agreed access (VPN, credentials, or jump host) if the method is grey or white box

Two common scoping failures waste the later phases. Underscoping to save effort leaves crown-jewel systems untested. Overscope without an inventory sends testers into unknown hosts and forces emergency stops. Maintain a current asset list so the tester is not discovering your estate for the first time during the window.

Testing method choices change speed and depth. Black box gives the tester no internal knowledge and closest mimics an external attacker, but takes longer to map the surface. White box supplies diagrams, source, or credentials so testers go deeper, faster. Grey box sits between those extremes.

External testing starts from the internet and answers whether an outsider can break in. Internal testing assumes a foothold inside the network and looks for lateral movement after a breach of the perimeter.

The stop button is a named emergency path. If a tester hits an unexpected critical system, causes instability, or finds something outside the agreed bounds, they stop immediately and call the Phase 0 contact. That protocol belongs in the rules of engagement before testing starts. Define the testing hours in the same document so scanning does not collide with a release or a change freeze you never mentioned.

Pentest versus red team: a pentest is a scoped hunt for exploitable weaknesses with evidence and fixes. A red team exercise is a broader adversary simulation, often longer, with stealth and detection testing as the goal. Choose a pentest when you need proven vulnerabilities and a remediation list.

Phase 1: Reconnaissance and Information Gathering

Reconnaissance is the phase where the tester gathers publicly available information or agreed internal intelligence about the target's systems, people, and infrastructure.

Passive reconnaissance uses open-source intelligence and does not touch your systems. Active reconnaissance interacts with in-scope assets (for example DNS queries or banner collection) and is only lawful because Phase 0 authorised it.

Passive work stays on public records, leaked metadata, certificate transparency, and published infrastructure clues. Active work is constrained by the same rules of engagement that named IPs, applications, and forbidden targets. Imprecise Phase 0 wording later creates legal and operational risk, because it decides what the tester may touch.

Typical items on the attack-surface list include:

• Subdomains and forgotten hostnames
• Exposed IP ranges and third-party services
• Email formats and staff naming patterns that aid phishing-style pretexting only if that is in scope

That shopping list of surface area feeds Phase 2. Nothing in this phase is random browsing. It is a structured inventory of what the later scan and exploit work is allowed to pursue. If the client promised an inventory in Phase 0, this phase should reconcile public findings against that list, not replace it.

Phase 2: Scanning and Vulnerability Discovery

Scanning is active interaction with in-scope targets using tools to identify open ports, running services, and candidate misconfigurations. Port scanners such as Nmap and web application proxies such as Burp Suite are typical categories, used as instruments, not as the whole test.

A vulnerability assessment is automated detection of known issue signatures. A professional pentest does not stop at that scan. Each candidate finding is manually verified to prove whether it is a real, reachable threat rather than a false positive or a dead configuration. Web application work often maps candidates against classes such as the OWASP Top 10, then still requires a human to confirm exploitability in your specific build.

Scanner versus pentester: the scanner produces a candidate list. The tester confirms reachability, context, and whether the issue can actually be used. The output of this phase is that verified candidate list for Phase 3, not a final risk register. If a provider treats the scanner PDF as the deliverable, you bought an assessment, not a pentest.

Phase 3: Exploitation and Proof of Concept

Exploitation is the attempt to use verified vulnerabilities to gain access, move laterally, or extract agreed evidence of impact, strictly inside the scoped rules. Testers do not deliberately cause permanent damage, wipe data, or step outside the agreed boundary. Frameworks such as Metasploit may appear here as controlled proof tools, not as a licence to run every module against production.

Proving impact means more than noting an open port. The tester shows that a specific weakness can lead to data exposure, privilege gain, or system compromise, then stops at the point of proof. Safe parameters are a function of the Phase 0 rules: exploit far enough to evidence risk, not far enough to destroy production data or crash systems for effect. Chaining two modest findings into one path to data is often more useful than a single flashy exploit that never reaches a business asset.

Stop-and-escalate still applies. Unexpected critical findings, instability, or out-of-scope systems trigger an immediate halt and a call to the emergency contact. The process is:

• confirm the candidate
• attempt controlled exploitation
• capture evidence
• stop at proof
• escalate if anything breaks the agreed envelope

Phase 4: Reporting and Deliverables

A professional pentest report is a structured deliverable with an executive summary, a scope recap, a risk register with severity ratings, evidence for each finding, and remediation guidance.

CVSS is a common scoring standard for technical severity. It is not a proprietary score, and it should not be the only ranking used. A CVSS 9.8 on an isolated lab host is not the same business problem as a lower score on the payment or identity path.

The report has two audiences. Management needs a short executive summary of business risk and next actions. IT and DevOps need the technical section: reproduction steps, evidence, affected assets, and fix guidance.

A useful report ranks findings by likelihood and business impact as well as the raw CVSS number, so you can sequence remediation rather than chase every medium finding equally.

• Executive summary and residual risk narrative
• Scope recap (in bounds, out of bounds, method used)
• Risk register with severity, likelihood, and business impact
• Evidence and reproduction notes per finding
• Remediation guidance mapped to owners

Ask a credible provider for a redacted report sample before you sign. That sample is a standard quality signal. If the sample is only a tool dump with no impact narrative, the live report will not help you prioritise.

What Happens After the Report: Remediation and Retesting

Remediation planning is the work of turning the ranked risk register into a fix schedule based on business impact, not just ticket volume. Assign owners, sequence critical paths first, and treat the pentest as the start of improvement, not the finish. Ignoring the report is the most expensive outcome: you paid for proof and then left the same path open.

A retest is a follow-up check, usually inside a defined window, that verifies claimed fixes actually close the original issue. Ask about retesting scope before you sign the contract. A retest should replay the original evidence, not become a free second full pentest of new systems. Close-out is formal: the retest confirms the fix (or records residual risk), and the engagement is complete.

How to use the report

1. Triage by combined severity, likelihood, and business impact.
2. Assign owners and a fix window for each accepted finding.
3. Book the retest against the original evidence, not a new full hunt.

Frequently Asked Questions