Methodology
Good security testing is repeatable. Our work follows published frameworks, so you know what was tested, how it was tested, and how each risk was rated.
Frameworks we follow
-
OWASP WSTG
OWASP Web Security Testing Guide
The core reference for our web application and API testing. It defines test cases for information gathering, configuration, identity, authentication, authorisation, session management, input validation, error handling, cryptography, business logic and client-side security. We supplement it with the OWASP API Security Top 10 and the OWASP MASTG for mobile apps.
OWASP WSTG (OWASP Web Security Testing Guide) -
PTES
Penetration Testing Execution Standard
Shapes the overall engagement lifecycle: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. It keeps every test structured from scoping to final report.
PTES (Penetration Testing Execution Standard) -
NIST SP 800-115
NIST Technical Guide to Information Security Testing and Assessment
Guides our planning, execution and post-testing activities for network and infrastructure assessments, including review techniques, target identification and analysis, and target vulnerability validation.
NIST SP 800-115 (NIST Technical Guide to Information Security Testing and Assessment)
How we rate risk
Each technical finding receives a Common Vulnerability Scoring System (CVSS) v4.0 base score, which maps to a severity level. We then consider business context, such as data sensitivity, exposure and compensating controls, and explain any adjustment in the report.
| Severity | CVSS score | What it typically means |
|---|---|---|
| Critical | 9.0 – 10.0 | Easily exploitable with severe impact, such as remote compromise or large-scale data exposure. Fix immediately. |
| High | 7.0 – 8.9 | Significant impact or a likely path to compromise. Fix as a priority. |
| Medium | 4.0 – 6.9 | Meaningful weakness that needs specific conditions to exploit. Plan a fix. |
| Low | 0.1 – 3.9 | Limited impact or difficult to exploit. Fix as part of normal maintenance. |
| Informational | 0.0 | No direct risk, but a good-practice improvement or useful observation. |
How our reports are structured
Reports are written for two audiences: leaders who need to make decisions and engineers who need to fix issues.
-
Executive summary
Scope, overall risk, the most important findings and recommended priorities, without jargon.
-
Scope and approach
Targets, dates, test type, accounts used, frameworks followed and any limitations.
-
Findings summary
A table of all findings by severity and status, so you can track progress at a glance.
-
Detailed findings
For each issue: description, affected assets, CVSS vector and score, evidence, steps to reproduce, impact and specific remediation guidance with references.
-
Appendices
Supporting material such as tool output, tested endpoints and the CVSS methodology.
Retest policy
A finding is only useful once it is fixed. Our penetration testing engagements include one retest of the findings in the original report, carried out within 90 days of the final report.
After the retest we issue an updated report showing each finding as resolved, partially resolved or unresolved, with evidence. A retest checks the reported findings only; it is not a new full test of the scope.
Want to see a sample report structure?
Contact us and we will walk you through how we would approach your environment.