Penetration Testing Methodology

Consultant-led penetration testing. An approach that works.

Every penetration test Exploitr delivers follows a structured methodology drawn from recognised industry frameworks. Here is how every engagement works, from the initial scoping conversation through to your final report and beyond.
Get a Fixed-Price Quote See the testing phases
CREST Pathway member Cyber Essentials certified UK Cyber Security Council member

Our approach

Manual testing, led by consultants

Security testing broadly falls into two categories: automated scanning, which identifies known vulnerabilities against a database of signatures, and manual penetration testing, which finds what scanners cannot. Every engagement we deliver sits in the second category.

Our methodology draws from the OWASP Web Security Testing Guide (WSTG) and NIST SP 800-115, with adversary-informed techniques aligned to the MITRE ATT&CK framework and guidance from the NCSC. For infrastructure testing, we also reference the Penetration Testing Execution Standard (PTES) alongside NIST. These frameworks are not labels applied after the fact: they shape how we plan and execute every assessment.

Each engagement is scoped individually, priced at a fixed rate before any work begins, and delivered by the same consultant from the initial scoping call through to the debrief. Nothing is outsourced or subcontracted.

Testing phases

How every engagement is structured

The phases below apply across all service types. The specific test cases, frameworks, and depth of each phase are determined by the scope agreed at the outset.

01

Scoping and rules of engagement

We agree the scope, target systems or applications, testing hours, and any restrictions before any work begins. A written rules of engagement document and fixed-price proposal are produced at this stage.

Scoping determines what is tested, how it is tested, and what is explicitly excluded. For network assessments, this covers IP ranges and services. For web applications, it covers the application surface, authenticated roles, and any restricted functionality.

A fixed-price proposal is confirmed before testing begins, and the rules of engagement document is signed by both parties. For guidance on how scoping typically works, see our articles on scoping a web application assessment and scoping a network penetration test.

02

Reconnaissance

We map the target environment before active exploitation begins. For external targets, this includes open ports, services, DNS records, and open-source intelligence. For applications, it covers routes, API endpoints, technologies in use, and session handling.

Reconnaissance is passive or semi-passive at this stage. For network testing, this involves port scanning, service enumeration, and open-source intelligence gathering. For web applications, it involves spidering the application, analysing HTTP traffic, and building a map of accessible functionality.

The output is a testing plan that ensures coverage of the full agreed scope before active exploitation begins.

03

Manual testing and exploitation

Testing is conducted manually and intelligence-driven throughout. Automated tools are used selectively to improve efficiency, for example for parameter fuzzing or directory enumeration. Every finding is discovered and validated by the consultant.

For web application and API testing, we follow the OWASP WSTG test cases across authentication, session management, authorisation, input validation, and client-side controls. For infrastructure testing, we follow NIST SP 800-115 and PTES.

Business logic vulnerabilities, authorisation flaws, and chained attack paths are found with human analysis and not by automated scanners alone. Critical findings are raised with your named technical contact immediately, not held until the report.

04

Post-exploitation and privilege escalation

Where the assessment type permits, we attempt to escalate privileges and move laterally to understand the real-world impact of successful exploitation. This is standard in internal network and assumed-breach engagements.

For internal network assessments, this involves testing Active Directory trust relationships, Kerberoasting, pass-the-hash, and lateral movement techniques aligned with MITRE ATT&CK. For application testing, it covers horizontal and vertical privilege escalation, IDOR, and access control testing across all authenticated roles.

The objective is to demonstrate what a real attacker could access or achieve, not only to confirm that a vulnerability exists.

05

Reporting

A written report is delivered within two business days of testing completion. Every finding includes a severity rating, reproduction steps, proof-of-concept evidence, and remediation guidance. Reports are written for both technical and non-technical audiences.

The report includes an executive summary for business stakeholders, and a technical findings section for engineering and security teams. Findings are rated using CVSS and mapped to CVE, CVSS, and MITRE ATT&CK where applicable.

For a full breakdown of what a well-structured pentest report should contain, see our article on how to write a penetration test report. Findings are also available in real time throughout the engagement via Attack Surface Center, so you are not waiting until the end to see what has been found.

06

Debrief and free retesting

A debrief call follows the report to walk through findings with your technical and business teams. For externally-based assessments including web application, API, and external network testing, focused retesting of remediated vulnerabilities is included at no additional charge.

The debrief covers findings in plain language, prioritisation guidance, and answers questions from your team. Once remediation is complete, we revisit the specific findings to confirm fixes are effective. This is a targeted retest of addressed vulnerabilities, included as standard.

For a full walkthrough of what the testing window looks like from your team's perspective, see our article on what to expect during a web application pentest.

Standards and frameworks

The frameworks our methodology is built on

Our testing methodology draws on established, peer-reviewed frameworks rather than an ad hoc internal checklist. Below is a summary of the primary standards we reference and how they are applied across our service types.
01

OWASP Web Security Testing Guide (WSTG)

The primary reference for web application testing coverage. Our web application and SaaS assessments follow the WSTG test cases across authentication, session management, authorisation, input validation, API security, and client-side controls.
02

OWASP API Security Top 10

API-specific risks including broken object-level authorisation (BOLA), broken authentication, excessive data exposure, and rate limiting bypass. Applied to all API and web application assessments where APIs are in scope.
03

OWASP Mobile Application Security Verification Standard (MASVS)

The reference standard for iOS and Android security testing, covering data storage, cryptography, authentication, network communication, platform interaction, and code quality. Applied to all mobile application assessments.
04

NIST SP 800-115

NIST's technical guide to information security testing and assessment. Provides the framework for our network and infrastructure testing methodology, covering planning, discovery, attack phases, and reporting structure.
05

Penetration Testing Execution Standard (PTES)

A community standard covering the full engagement lifecycle: pre-engagement, intelligence gathering, threat modelling, exploitation, post-exploitation, and reporting. Referenced across network and infrastructure assessments. See our PTES glossary entry for an overview of the standard.
06

MITRE ATT&CK

A knowledge base of adversary tactics, techniques, and procedures (TTPs) drawn from real-world observations. Used to frame exploitation and post-exploitation techniques in network and infrastructure testing, and to map findings in technical reports. See our MITRE ATT&CK glossary entry.
07

NCSC guidance

We reference NCSC guidance on penetration testing as part of how we structure engagements and communicate results. The NCSC's penetration testing guidance for organisations provides useful context for buyers and commissioning teams.
08

CREST

Exploitr is enrolled in the CREST Pathway programme, which provides a structured route for penetration testing companies working towards CREST accreditation. Our methodology is aligned to CREST guidance on penetration testing, and we are actively working towards full accreditation & membership.
Reporting

Reports built for technical teams and business stakeholders

Every engagement produces a written report delivered within two business days of testing completion. Reports are written for two audiences: the technical teams responsible for remediation, and the business stakeholders who need to understand the risk and sign off on remediation priorities.

Findings are tracked live in Attack Surface Center throughout testing, so your team can see what is being found without waiting for the report.

  • Executive summary: A concise overview of the engagement, key findings, and overall risk exposure, written for non-technical stakeholders including board members, senior management, and compliance auditors.
  • Technical findings: Each vulnerability documented with a severity rating (aligned to CVSS), reproduction steps, proof-of-concept evidence, affected component, and remediation guidance. Findings are mapped to CVE, CVSS, and MITRE ATT&CK where applicable.
  • Scope and methodology section: A documented description of the testing approach, the scope agreed during the engagement, the standards and frameworks applied, and any items that were excluded from testing.
  • Live findings in Attack Surface Center: View findings as they are logged during testing, track remediation progress, and collaborate with your team in real time through Attack Surface Center.
  • Retesting included: For externally-based assessments including web application, API, and external network testing, focused retesting of remediated vulnerabilities is included as standard at no additional charge.
Penetration test findings tracked and reported in the Attack Surface Center platform

What makes our methodology different

Manual testing, delivered by the same person throughout

Methodology is only part of what determines the quality of a penetration test. Who delivers it and how they work matters too.

No automated scans presented as penetration tests

We use tools to improve efficiency where appropriate, not to replace the work or the human-touch. Every finding is discovered and validated manually by the consultant assigned to your engagement. You will not receive a repackaged vulnerability scanner output.

The same consultant, start to finish

Your consultant is confirmed before testing begins and stays with the engagement through scoping, testing, report delivery, and the debrief call. Nothing is handed off to a different person partway through.

Nothing outsourced or subcontracted

All testing is performed by our in-house team. Your data and your environment are not passed to a third-party provider. Our lead consultant holds OSCP and OSCE certifications from OffSec.

Scoped to your environment

We scope every engagement individually. The testing approach, the frameworks applied, and the depth of coverage reflect your specific environment, compliance requirements, and the risk profile of what is being tested.

Critical findings raised immediately

If a critical vulnerability is found during testing, you hear about it the same day, not at report delivery. For application testing, this means your team can begin remediation before the testing window has closed.

Get a fixed-price quote for your next assessment

Submit your requirements and we will respond with a written, fixed-price proposal within one business day. All enquiries are confidential and there is no obligation to proceed.

Request a Quote Book a Scoping Call

Common questions

Penetration testing methodology: frequently asked questions

Our methodology draws from the OWASP Web Security Testing Guide (WSTG) and OWASP API Security Top 10 for application testing, NIST SP 800-115 and the Penetration Testing Execution Standard (PTES) for network and infrastructure testing, and the MITRE ATT&CK framework for adversary technique selection and findings mapping. For mobile application testing, we reference the OWASP MASVS.

We also take into account NCSC guidance on penetration testing for engagements delivered to UK organisations.

All testing is manually led. Automated tools are used selectively, for example for large-scale parameter fuzzing or directory enumeration, but every finding is reviewed and validated by the consultant. Business logic flaws, authorisation vulnerabilities, and chained attack paths are identified with the human analysis that automated tools cannot replicate.

You will not receive a repackaged vulnerability scan.

The core principles are consistent across all service types: manual, intelligence-driven testing by an in-house consultant, with a fixed price confirmed before work begins. The specific frameworks and test cases are applied depending on what is in scope.

For web application testing, we follow the OWASP WSTG. For API testing, the OWASP API Security Top 10. For network and infrastructure, NIST SP 800-115 and PTES. For mobile applications, the OWASP MASVS. See the services overview for a full breakdown by service type.

These terms describe how much information is shared with the tester before the engagement begins.

Black-box (or closed book) testing simulates an external attacker with no prior knowledge of your environment. Grey-box testing provides the tester with partial information, typically credentials or access as an authenticated user. This is the most common approach for web application and API assessments. White-box (aka. transparent or open book) testing gives the tester full access to source code, architecture documentation, and credentials.

For a full comparison and guidance on which approach to choose, see the services FAQ.

Scoping happens during the initial conversation, by call or by email. We ask about the systems or applications that are to be tested, their complexity, any compliance context, and your objectives. From that we produce a fixed-price written proposal that confirms the targets that are in scope, the methodology and approach that will be applied, the deliverables that you will receive, and the wider rules of engagement like any testing windows or exclusions.

For more detail on how scoping typically works in practice, see our articles on scoping a web application assessment and scoping a network penetration test.

Critical findings are escalated to your named technical contact the same day they are discovered, and are not held until the report is delivered. This gives your team the option to begin remediation before the testing window closes, where we can re-test the findings there and then.

You can also view any findings in real time throughout the engagement via Attack Surface Center, our attack surface management platform.

We do not use AI tools to perform penetration testing. Our methodology is based on manual, intelligence-driven testing by experienced consultants.

While AI can assist in certain tasks, it cannot replace the nuanced analysis and decision-making required to identify complex vulnerabilities and business logic flaws. See our AI policy for more information.