Methodology
Consistent enough that findings are comparable between engagements and testers. Flexible enough that we follow what your systems actually do rather than working through a checklist and calling it a day.
What we build on
We do not invent methodology. We follow the established standards, and document which applied to your engagement so your auditors can verify it.
PTES
The Penetration Testing Execution Standard, providing the overall engagement structure.
NIST SP 800-115
Technical guide to information security testing, widely referenced by assessors.
OWASP
WSTG, ASVS, API Top 10, MASVS and the LLM Top 10, depending on target type.
MITRE ATT&CK
Technique mapping for network and red team work, so findings map to detection.
Six phases
Scoping and authorisation
Before anything technical happens, we agree in writing what is in scope, what is explicitly excluded, when testing runs, and what we are permitted to do when we find a way in.
- Target inventory with explicit exclusions
- Rules of engagement, including which techniques are permitted
- Testing window, escalation contacts and communication channel
- Written authorisation signed by someone able to grant it
- NDA and data handling terms confirmed
Deliverable: signed scope and authorisation document.
Reconnaissance
We map what exists before deciding what to attack. This regularly surfaces assets the client did not know were exposed — which is frequently the most valuable output of the phase.
- Passive collection: DNS, certificate transparency, public records
- Active enumeration within the authorised scope
- Technology fingerprinting and version identification
- Application mapping — every route, parameter and role boundary
- Attack surface documentation, including anything unexpected
Deliverable: attack surface inventory, shared with you during testing.
Vulnerability identification
Automated tooling gives coverage across the surface. Manual testing gives depth where it matters. Neither alone is sufficient, and most of the engagement is spent on the manual half.
- Authenticated and unauthenticated testing across every role
- Systematic work through the applicable OWASP testing guide
- Configuration and hardening review against relevant benchmarks
- Manual analysis of business logic and workflow assumptions
- Every candidate issue manually verified — we do not report scanner output
Deliverable: verified candidate findings, with false positives already removed.
Exploitation and escalation
A finding becomes meaningful when you can see what it costs you. We exploit within the agreed rules, chain issues where they combine, and stop at the point impact is proven rather than pushing further for its own sake.
- Controlled exploitation to confirm the issue is real, not theoretical
- Chaining — where two medium findings become one critical path
- Privilege escalation and lateral movement within scope
- Impact demonstration: what data, what accounts, what actions
- Proof of concept documented sufficiently for your team to reproduce
Restraint is part of the method. We demonstrate access without exfiltrating production data beyond what is needed to evidence the finding, we do not modify or destroy data, and we do not pivot outside the authorised scope even when a path exists. Anything that could disrupt service is agreed with you before it happens.
Deliverable: immediate notification of any Critical, within 48 hours of confirmation.
Analysis and reporting
Two documents for two audiences, because the person who fixes the finding and the person who funds the fix need different things.
- Technical report — each finding with description, affected components, reproduction steps, evidence, CVSS v3.1 vector and specific remediation guidance
- Executive summary — overall posture, risk themes and prioritised recommendations in business language
- Findings prioritised by real risk in your context, not raw CVSS alone
- Draft issued for factual review before finalisation
- Attestation letter confirming scope and dates, on request
Deliverable: draft within five working days of testing completion.
Remediation support and retest
A report nobody acts on has bought you nothing. This phase exists to make sure the findings actually close.
- Walkthrough session with your engineers to work through each finding
- Availability for questions while remediation is in progress
- Retest of remediated findings, included within six months
- Reissued report with updated status for each finding
- Updated attestation reflecting the remediated position
Deliverable: retest report confirming which findings are closed.
How we rate severity
Every finding carries a CVSS v3.1 base score and full vector string. But CVSS describes the vulnerability, not your business — so we also assign a contextual priority.
| Rating | CVSS | What it means for you |
|---|---|---|
| CRITICAL | 9.0–10.0 | Exploitable now, with severe consequence. Notified within 48 hours of confirmation; remediate immediately. |
| HIGH | 7.0–8.9 | Significant compromise of data or function. Remediate within the current cycle. |
| MEDIUM | 4.0–6.9 | Real risk, usually requiring specific conditions or existing access. Plan into the next release. |
| LOW | 0.1–3.9 | Limited direct impact, but frequently a component of a larger chain. |
| INFO | 0.0 | No direct risk. Hardening opportunities and observations worth knowing. |
Where we differ from the score. A CVSS 6.1 cross-site scripting flaw in your admin panel may matter more to you than an 8.6 issue on a system holding nothing. When our contextual priority differs from the raw score, the report says so and explains why. You should be able to argue with our reasoning — that requires us to show it. Try the CVSS calculator to see how the metrics combine.
See the methodology applied to your systems.
Start with one free verified finding, or book a scoping call.