Methodology
Our testing is repeatable, measurable and transparent. It builds on recognised open methodologies, and we document every step.
Frameworks we build on
Web application security
OWASP Top 10:2025 for risk classification, ASVS 5.0.0 for verification requirements and WSTG v4.2 for structured test cases.
API and mobile security
OWASP API Security Top 10:2023 and OWASP Mobile Top 10 2024, supported by MASVS controls and MASTG test guidance for mobile engagements.
PTES and NIST SP 800-115
A structured engagement from authorisation and reconnaissance to analysis, controlled exploitation and reporting, with agreed safeguards for production.
FIRST CVSS v4.0
Technical severity is documented with a score and vector. Business impact, exposure and exploitation likelihood provide additional remediation context.
ISO/IEC 27001:2022, KVKK and NIS2
Readiness support linking technical findings to relevant security controls. Legal applicability and obligations should be confirmed with qualified advisers.
PCI DSS v4.0.1
Scoped technical reviews and readiness support for payment environments. We do not provide QSA assessments, ASV scans or PCI certification.
Testing phases
1. Pre-engagement and scope
Objectives, assets, test type (black, grey or white box), time window and contacts are defined.
2. Authorisation
No active testing starts until written authorisation and rules of engagement have been signed.
3. Reconnaissance
The attack surface is mapped through passive and active information gathering.
4. Vulnerability analysis
Automated tools and manual review are combined, and false positives are removed.
5. Controlled exploitation
The real impact of findings is demonstrated without harming data integrity or availability.
6. Reporting
The executive summary and technical report are written and presented.
7. Retest
Fixed findings are tested again and the result is documented.
Severity ratings (CVSS v4.0)
The CVSS score reflects technical severity. To set priorities, we weigh it against the business importance of the asset and the likelihood of exploitation.
| Severity | CVSS v4.0 range | Recommended response |
|---|---|---|
| Critical | 9.0 – 10.0 | Act immediately; reported as soon as it is found during testing. |
| High | 7.0 – 8.9 | Fix as a priority in the short term. |
| Medium | 4.0 – 6.9 | Fix within the planned maintenance cycle. |
| Low | 0.1 – 3.9 | Address when convenient or alongside other work. |
| Informational | 0.0 | No direct risk; hardening and good-practice advice. |
Sample finding
The record below is a fictional example prepared to show how findings are structured in our reports. It does not relate to any real client.
- Title
- Unauthenticated SQL injection in the login API
- Severity
- Critical
- CVSS v4.0
9.3 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N- Affected asset
POST /api/v1/auth/login (example)- Impact
- An unauthenticated attacker can read and modify customer records in the database.
- Evidence
- Reproduction steps, request/response samples and screenshots (sensitive data masked).
- Recommendation
- Use parameterised queries, restrict the database user's privileges and add rate limiting to the login endpoint.
- Mapping
- OWASP Top 10 A05:2025 Injection · ASVS 5.0.0 V1 · ISO/IEC 27001:2022 A.8.28
Sample reporting flow
Kickoff
Scoping meeting and sign-off of the rules of engagement.
Testing period
A short daily status note; immediate notification for critical findings.
Draft report
A draft report and findings list are shared once testing is complete.
Debrief
A summary presentation for management and a finding-by-finding session for the technical team.
Final report
The final report, incorporating your feedback, delivered encrypted.
Retest
Retesting of fixes and an updated status report.
Rules of engagement
- No system is actively tested without written authorisation.
- Only assets within the agreed scope are tested.
- Denial-of-service and social engineering are only performed if explicitly in scope.
- A channel to stop the work immediately is defined for both parties.
- Personal data encountered during testing is touched as little as possible and never copied.
- Test data and temporary access are removed at the end of the engagement.
See your weaknesses before attackers do.
Let's define the scope together. You'll receive a written proposal with the right type of test and a clear timeline.