What you get at the end.
Seven sections, the same every time, in a PDF you can hand to an auditor or a client's procurement team. Half of it is what we found; the other half is what we tested and what held.
Every report, the same shape.
- 01
Executive summary
Posture, top risks and the headline numbers, in plain terms. Written so a board or a client's procurement team can read it without an engineer translating.
- 02
Scope & methodology
Exactly what was in scope, what was excluded, when it ran and which methodology was followed. The boundary is stated, not implied.
- 03
Findings
Grouped by severity, critical first. Each one carries evidence, reproduction steps and a recommendation your engineers can act on.
- 04
Remediation priority
What to fix first and why — ordered by real exposure, not just by score. Anything being actively exploited moves to the front.
- 05
Compliance & frameworks
The findings aggregated up to OWASP categories, MITRE ATT&CK techniques and NIST CSF functions, so the report drops straight into an audit file.
- 06
Verified controls
What was tested and held. This is the half most reports omit — without it you cannot tell a clean result from an incomplete test.
- 07
Sign-off
Who ran it, under what authorisation, and the retest record once the fixes land.
Ten fields, none optional.
The platform refuses a finding that is missing any of these, which is why you never get a report row that says only “SSL issue”.
severitycritical / high / medium / low / infocvss_scoreCVSS v3.1, 0.0–10.0affected_componentthe exact host, endpoint or fileevidencerequest / response or output that proves itowaspOWASP Top 10 categorycweCWE identifiermitre_attackATT&CK techniquenist_csfNIST CSF functioncveconfirmed by a tool, or marked unconfirmedrecommendationwhat to change, specificallyWant to read a real one?
We will send a redacted report from a past engagement — a real one, with the client and their systems removed.