Our Pentesting Methodology & Process | 6-Phase Guide

A penetration testing methodology is a structured, repeatable framework that governs every stage of a penetration test, from initial scoping through to reporting and remediation.

This page explains how that framework works in practice, how it maps to recognised standards, and what you should expect before, during, and after an engagement.

TEST. FIND. FIX. PROTECT.

What Is a Penetration Testing Methodology?

A penetration testing methodology is a structured, repeatable framework that governs every stage of a penetration test, from initial scoping through to reporting and remediation. Methodology is what separates professional pentesting from ad-hoc hacking. It is the operating system of the engagement: it decides coverage, depth, and whether results can be defended to auditors, boards, and insurers.

Methodology is the part buyers should evaluate first, because two firms can use similar tools and still produce very different coverage. It ensures consistency, comprehensiveness, and alignment with industry standards. We align our work to PTES, NIST SP 800-115, and OWASP WSTG.

A methodology is not a checklist of tools. It is a decision-making framework that guides how testers think, plan, and execute. A methodology-driven provider is more likely to deliver complete, defensible, and repeatable results.

Our 6-Phase Pentesting Process

Our methodology follows six distinct phases, aligned to PTES and NIST SP 800-115. Each phase has a client-facing purpose, a tester activity, and a defined output so you know what you are paying for at every stage. The same phase model is applied across penetration testing services, then tailored for web application testing, network testing, and related engagements.

Phase 1 — Scoping & Pre-Engagement

Scoping and pre-engagement is the formal agreement of objectives, assets, constraints, and rules of engagement before any testing starts. The scoping call covers business objectives, critical systems, compliance drivers, and testing limits. You should provide an asset inventory, network diagrams, objectives, and proposed rules of engagement. Scope is written down so coverage is clear and scope creep is controlled.

If you cannot list every host, say so early. An honest unknowns list is safer than a tidy inventory that omits third-party SaaS or cloud accounts sitting on the real path.

Phase 2 — Intelligence Gathering

Intelligence gathering is passive and active reconnaissance used to map the real attack surface, not the surface assumed in a spreadsheet. Testers use OSINT, public records, and authorised active mapping to build a target list and attack-surface map. That map becomes the working input for threat modelling and later exploitation.

Clients typically see this as a short confirmation of in-scope hosts, exposed services, and unexpected findings such as forgotten subdomains or staging systems that still resolve publicly.

Phase 3 — Threat Modelling & Vulnerability Analysis

Threat modelling and vulnerability analysis is the process of ranking likely attack paths, then combining automated scanning with manual testing. Automated tools find known CVEs and common misconfigurations. Manual testers find business-logic flaws, chained exploits, and paths scanners cannot reason about. The output is a prioritised set of hypotheses ready for safe exploitation.

This is also where OWASP WSTG-style checks apply to applications and APIs: authentication, session handling, access control, and payment or admin workflows that a generic scanner will not interpret as an attacker would.

Phase 4 — Exploitation

Exploitation is the controlled attempt to prove that a finding can cause real-world impact, within agreed safety limits. Testing windows, allowed techniques, and emergency stop procedures are fixed in the rules of engagement. Testers exploit only far enough to demonstrate impact, then stop.

Not every vulnerability can be fully exploited on production. Where a proof would be unsafe, testers document a constrained proof and the residual risk instead of forcing a crash. Production risk is managed by agreement, not by hope.

Phase 5 — Post-Exploitation

Post-exploitation is the work done after initial access to show how far an attacker could actually go. Testers assess lateral movement, privilege escalation, and persistence where authorised. This phase converts a single vulnerability into a business-risk statement: what data, systems, or processes become reachable if the first foothold is real.

Skipping it leaves you with a list of holes, not a picture of blast radius. That picture is what boards and insurers usually need when they ask what the finding means in practice.

Phase 6 — Reporting & Remediation Support

Reporting and remediation support is the delivery of evidence, severity, and fix guidance that technical and non-technical stakeholders can both use. Reports include an executive summary, technical findings, CVSS scores, evidence of exploitability, and remediation guidance. After delivery, prioritisation support and retesting confirm that fixes actually close the path.

A report that only dumps scanner output is not a methodology output. You should be able to brief a non-technical stakeholder from the first pages and hand the rest to engineers without translation.

Use the table to check that a proposal covers pre-engagement, post-exploitation, and remediation support, not only scanning and a PDF.

How Our Methodology Aligns with Industry Standards (PTES, NIST, OWASP)

Industry-standard alignment is the practice of mapping our six phases to recognised frameworks so coverage is auditable, not invented in isolation. Different frameworks use 4, 5, 6, or 7 phases. That difference is granularity, not correctness.

A five-step marketing diagram can still be a complete test if pre-engagement, threat modelling, and post-exploitation happen inside other labels. A seven-step diagram can still be thin if those labels are not actually staffed.

PTES is a seven-phase standard covering pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. NIST SP 800-115 is a four-phase technical guide: planning, discovery, attack, and reporting. OWASP WSTG is the web-application testing guide used when the target is an application, API, or browser-facing workflow. OSSTMM and ISSAF remain useful alternative references for broader operational security and older programme structures.

We align with PTES for depth in pre-engagement and post-exploitation, and with NIST for its compliance-friendly structure. MITRE ATT&CK is used as a reference language for threat-informed testing and red team style narratives, not as a replacement for a pentest methodology.

Framework names on a proposal only help if the mapping is explicit. Ask the provider to show how their phases cover PTES pre-engagement and post-exploitation, not just a scan-and-report loop.

What to Expect During a Pentest Engagement

A professional pentest engagement is a controlled, time-boxed exercise with agreed communication, testing windows, and stop procedures so production systems stay protected. The aim is evidence of risk, not surprise downtime. Schedule active testing away from peak trading or release freezes where you can. Have someone available who can interpret alerts and approve a pause.

Communication

Communication cadence is a daily status update plus immediate contact for critical findings. Unexpected high-impact issues are raised as soon as they are confirmed, with evidence captured and exploitation kept within the agreed limit. You should nominate a single point of contact and an urgent channel before day one. Daily notes should say what was tested, what is blocked, and what is planned next, so operations are not guessing why logs look noisy.

Testing Windows

Testing windows are the hours agreed in scoping for active work against live systems. Out-of-hours testing can be arranged when peak trading risk is high. Windows exist so operations teams know when load, logs, and alerts may change. Passive review and report writing can continue outside those windows without touching production.

Safety Protocols

Emergency stop procedures are the agreed way to halt testing if an unexpected issue appears. The client can stop the test. Testers can also pause if behaviour looks unsafe. Production protection comes from written rules of engagement, careful exploitation, and rollback plans where relevant. Have a point of contact, access arrangements if needed, and an urgent comms path ready before testing starts. If something unexpected happens, testers stop the relevant activity, notify the named contact, preserve evidence, and only resume after you agree.

Pentesting vs. Vulnerability Assessment vs. Red Teaming

A vulnerability assessment, a penetration test, and a red-team engagement are three different services with different depth, duration, and outcomes. Choose the one that matches the decision you need to make, not the most dramatic label.

Pentesting is one method inside a wider programme that can also include vulnerability management, audits, and social-engineering tests. It does not replace those methods.

Over-buying a red team when a pentest answers the question wastes time. Under-buying a scan when you need exploit evidence leaves auditors and boards with a list, not proof.

External tests suit internet-facing assets. Internal tests simulate an insider or a foothold already inside the network. Combine types when the decision needs both perimeter and inside-out evidence.

How to Scope a Penetration Test

Scoping a penetration test is the process of defining what will be tested, why, under which constraints, and with which emergency rules. Poor scope is the most common reason engagements miss the systems that matter or cost more than they should. A thorough test of fewer systems usually beats a shallow pass over everything.

A scoping call is where the provider asks about business objectives, critical systems, compliance requirements, and testing constraints. Rules of engagement then lock testing windows, emergency contacts, allowed techniques, and systems that are off-limits.

Common mistakes are under-scoping to save money, over-scoping to feel thorough, omitting third-party systems that sit in the real path, and leaving compliance requirements vague.

Cost depends on scope, test type, complexity, and whether retesting is included. Ask what drives the proposal rather than comparing day rates in isolation.

What to prepare for your scoping call

• Asset inventory (hosts, apps, APIs, cloud accounts, third parties in path)
• Network diagrams and trust boundaries
• List of critical systems and data classes
• Business and compliance objectives, including deadlines
• Preferred testing windows and emergency contacts
• Systems, techniques, or environments that are off-limits
• Named point of contact with authority to pause testing

After the Report: Remediation, Retesting, and Prioritisation

Post-report work is the conversion of findings into a sequenced fix plan, then retesting to confirm the attack path is closed. The report is a decision pack, not the end of the engagement. Do not park findings until the next compliance deadline. Fixes are cheaper while testers still remember the path and evidence is fresh.

Reports contain an executive summary for non-technical stakeholders, technical findings with CVSS scores, evidence of exploitability, and remediation guidance.

Prioritise using CVSS, business context, and exploitability together. Not every high-CVSS finding is equally urgent in every environment.

Remediation support means guidance on fixes and help ranking work. It is not usually a commitment to implement changes in your estate unless that is separately agreed.

Retesting is scheduled after fixes land. Confirm in writing whether retesting sits inside the original engagement or is billed separately, because that detail is scope-dependent.

• Fix first: vulnerabilities that are exploitable, internet-facing, and impact critical systems.
• Fix second: vulnerabilities that require local access or have lower impact.
• Monitor: informational findings and hardening recommendations.

UK Compliance Considerations for Penetration Testing

UK compliance-driven pentesting is the use of a standards-aligned methodology to produce evidence that technical and organisational controls have been tested, not merely documented. Methodology quality matters because auditors and the ICO look for due diligence, not a tool export.

Cyber Essentials requires a defined set of basic technical controls. A pentest does not replace the certification assessment, but it is an effective way to find gaps before you submit.

UK GDPR requires appropriate technical and organisational measures. A documented, scoped pentest with remediation follow-up is one way to demonstrate due diligence.

ICO expectations include testing security controls. A pentest report with CVSS, evidence, and retest notes is usable evidence of that testing.

PCI DSS requires regular penetration testing in cardholder environments. ISO 27001 and SOC 2 both treat independent testing as support for certification and ongoing control operation.

HIPAA is a common US reference on generic pentest pages. It is not the usual UK driver. Cyber Essentials, UK GDPR, ICO scrutiny, and PCI DSS usually matter more to UK buyers.

Questions to Ask Any Pentesting Provider

A methodology checklist is a set of questions that tests whether a provider can explain how they think, not only what they charge. Price still depends on scope. These questions test rigour.

• Which frameworks does your methodology align with (PTES, NIST, OWASP)?
• Who will actually perform the test? What are their qualifications and experience?
• What does the report include? Is there an executive summary for non-technical stakeholders?
• Is retesting included after remediation?
• How do you handle findings during the test? Will you notify us immediately if you find something critical?
• How do you protect production systems during testing?
• What does your scoping process involve? What do you need from us?

A provider that answers these questions clearly and specifically is more likely to deliver a thorough, professional pentest.

Frequently Asked Questions