How We Test
Every engagement follows the same documented method: recognised standards, five defined phases, findings rated consistently, and rules of engagement agreed before anyone touches your systems.
Five phases, and what each one gives you
Each phase has a defined output, so at every point in the engagement you know what has been produced and what comes next.
Scoping and rules of engagement
We agree targets, authenticated roles, testing windows, and what is explicitly out of bounds — then send a fixed-fee proposal within 24 hours. An NDA is signed before any of this is discussed.
You receive:Signed NDA, agreed scope, rules of engagement, fixed-fee proposal
Reconnaissance and mapping
We map the real attack surface as an external adversary would: exposed hosts and services, application entry points, APIs, authentication flows, and anything in scope that you may not have known was reachable.
You receive:Attack-surface map, confirmed in-scope inventory
Manual exploitation
The core of the engagement. Consultants test by hand — chaining weaknesses, abusing business logic, escalating between roles and tenants — to establish what an attacker could actually achieve, not what a signature matched.
You receive:Validated findings with working proof-of-concept for each
Reporting
Every finding is written up with its impact, a reproduction path, a CVSS v3.1 score, and remediation guidance aimed at the team that has to fix it — alongside an executive summary for people who will not read the technical detail.
You receive:Dual-audience report, risk-rated findings, remediation roadmap
Retest and certification
Once your team has applied fixes we retest to confirm the findings are genuinely closed rather than merely moved. Included in the original fee, not quoted as a second engagement.
You receive:Retest report and formal retest certificate
What we test against
Which of these apply is decided at scoping and recorded in the engagement document, so the report can be checked against a published standard rather than against our word.
PTES
Penetration Testing Execution Standard
The overall shape of an engagement — pre-engagement scoping, intelligence gathering, threat modelling, exploitation, post-exploitation, and reporting.
OWASP WSTG
Web Security Testing Guide
The per-test-case reference for web application work: authentication, session management, authorisation, input handling, and business logic.
OWASP ASVS
Application Security Verification Standard
Used to agree a verification level up front, so both sides know what depth of assurance the engagement is buying.
OWASP API Top 10
API security risks
API testing is scoped in its own right rather than as an afterthought to the web application in front of it.
OWASP MASVS / MSTG
Mobile application standards
Mobile work covers the client binary, local storage, transport, and the backend the app talks to.
NIST SP 800-115
Technical Guide to Information Security Testing
The assessment methodology auditors most often recognise, which matters when a report has to satisfy a third party.
OSSTMM
Open Source Security Testing Methodology Manual
Operational security testing for network and infrastructure scope, where measurable coverage matters more than a signature list.
MITRE ATT&CK
Adversary tactics and techniques
Used to map what we did to real adversary behaviour, so your detection team can check whether they saw it.
How severity is decided
Every finding carries a CVSS v3.1 base score plus a severity that accounts for its context in your environment. Where the two disagree, the report explains why.
Critical
CVSS 9.0 – 10.0
Direct compromise of the system or its data — remote code execution, authentication bypass, or mass exfiltration. Reported to you immediately, before the engagement ends.
High
CVSS 7.0 – 8.9
Serious impact with a realistic attack path — privilege escalation, access to another tenant's data, or exposure of credentials.
Medium
CVSS 4.0 – 6.9
Real risk that needs a precondition or chaining with another issue to become serious. Worth scheduling rather than dropping everything for.
Low
CVSS 0.1 – 3.9
Limited impact on its own, but useful to an attacker as a stepping stone or in aggregate. Reported so the decision to accept it is yours.
Informational
No CVSS score
Hardening and defence-in-depth observations with no direct exploitability. Kept clearly separate so it never pads the finding count.
Testing safely, on your terms
A penetration test is an authorised attack on systems you depend on. These constraints are agreed in writing before the first request is sent, and they apply to every engagement.
Ask about your constraintsWhere tooling stops and testing starts
Automation is genuinely better than a person at some things — enumerating a large surface, brute-forcing discovery, checking coverage. We use it for exactly those, and the output is treated as input to the test rather than as the test.
Everything that decides whether a finding is real belongs to a consultant: chaining two medium issues into a critical one, recognising that an identifier can be changed to reach another customer's data, noticing that a payment step can be skipped. No scanner has the context to see any of that.
Nothing reaches your report without a working proof-of-concept produced by hand.
Questions about how we work
If your security team has a question this does not answer, ask it during scoping — they will be talking to the consultant.
PTES gives the engagement its overall shape, and the technical depth comes from whichever standard fits the target — OWASP WSTG and ASVS for web, the API Top 10 for APIs, MASVS for mobile, OSSTMM and NIST SP 800-115 for network and infrastructure. The scoping document records exactly which apply to your engagement.
Want this methodology applied to your environment?
Scoping is free. You will get a fixed-fee proposal within 24 hours, with the standards that apply to your engagement written into it.