What a good security audit report contains, and how to read one
You are buying a document you have never seen
Most people who order a security audit have never read one. The PDF arrives, they scroll to the red boxes, forward it to a developer, and hope. And because they have no reference point, a 60-page scanner export and a 20-page written assessment look about equally serious.
They are not the same thing. A scanner export lists what a tool noticed. A report states what a human verified, why it matters in your application, and what to fix first. Telling them apart takes about ten minutes once you know where to look.
The parts a serious report has
The OWASP Web Security Testing Guide devotes a chapter to reporting — the most useful free yardstick available. Its structure, condensed:
Scope and limitations, in writing
Which hosts, which domains, which API endpoints. Whether testing was authenticated and with which roles. What was deliberately excluded. WSTG asks for an explicit Limitations subsection covering out-of-bounds areas, broken functionality, lack of time, lack of access or credentials.
This is the section most people skip and the one that determines what the rest is worth. "No SQL injection found" means nothing until you know which forms were reachable, and whether the tester had an account at all. Half of an application usually lives behind a login.
A report should also state its own expiry. WSTG suggests a disclaimer: the assessment is a "point in time" one, the environment may have changed since, and there is no guarantee every possible issue was identified. A provider who refuses to write that sentence is selling you something no one can deliver.
Executive summary
Two to three pages for someone who will not read the rest: why the test was commissioned, what came out of it in business terms, what to do about it strategically. Not a copy of the findings table with the same jargon. If the executive summary contains HTTP headers, nobody wrote one.
Methodology
Which framework was followed — the OWASP Top 10, the Application Security Verification Standard, NIST SP 800-115 — which tools were run, and what was done by hand. Without it you cannot judge coverage or compare this year's report to last year's.
Findings, each one justified
WSTG's finding template is a good checklist. Each entry should carry a reference ID, a title, an assessment of likelihood or exploitability, the impact, a risk rating, a technical description, remediation steps, and supporting references.
Add one thing WSTG leaves optional: a CWE identifier. CWE catalogues weakness classes — CWE-89 is SQL injection, CWE-79 is cross-site scripting — where CVE names one vulnerability in one product. A CWE ID turns "input validation issue" into something a developer can look up, and lets you check the findings against the CWE Top 25.
Evidence you can reproduce
The request sent, the response received, the exact sequence of steps. A finding you cannot reproduce is a finding you cannot verify as fixed. WSTG also asks that sensitive material — passwords, personal data, card numbers — be masked in the report itself, since the report is now a document describing how to break into your application.
Remediation, prioritized and specific
"Sanitize your inputs" is not remediation. "Replace the string concatenation in OrderRepository.findByRef() with a parameterized query" is. And priority is not just severity: a good report tells you what to do this week, this quarter, and what is acceptable to leave alone.
Re-test
WSTG suggests that a re-test report include a subsection summarizing the previous findings, their updated status, and cross-references to the current test. Without a re-test, nobody ever confirms that the fix worked — and fixes fail more often than people expect, usually because they patch the one endpoint that appeared in the report rather than the pattern behind it.
What a severity number actually means
Most findings carry a CVSS score: a 0–10 value with a label. None is 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0.
The number itself is worth little. What matters is the vector string next to it, in CVSS v3.1 notation:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — 7.5, High.
Read left to right: reachable over the network, low attack complexity, no privileges required, no user interaction, no scope change, high confidentiality impact, no integrity or availability impact. Now change one metric — the endpoint turns out to sit behind an admin login, so privileges required goes from None to High — and the same bug scores 4.9, Medium. Same code, different exposure, half the score.
That is the point: the vector is the auditor's reasoning made checkable. A report that gives you "High" with no vector and no documented scale is asking you to take severity on faith.
The base score is not your risk
FIRST, which maintains CVSS, is explicit about this in its user guide: "CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk." The base score covers only the intrinsic characteristics of a flaw, independent of any threat activity or of your environment. CVSS v4.0 makes the distinction visible in its naming — CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE — depending on whether threat and environmental metrics were applied.
In practice: a Medium on your payment flow can be more urgent than a High on a staging page nobody visits. A report that ranks strictly by base score has outsourced your prioritization to a formula that has never seen your business. The OWASP Risk Rating Methodology is the usual corrective — likelihood (threat agent and vulnerability factors) combined with impact, where impact includes financial damage, reputation, non-compliance and privacy breach, not just technical loss.
For known vulnerabilities in your dependencies, two public sources sharpen this further: EPSS, which estimates the probability that a published CVE will be exploited in the wild within 30 days, and the CISA Known Exploited Vulnerabilities catalog — covered in more detail here — which lists what is being exploited right now. A CVSS 9.8 nobody exploits is often less pressing than a 6.5 in the KEV catalog.
Signals you are holding a scanner export
| Signal | What it tells you |
|---|---|
| Findings named after tool plugins ("ZAP alert: X-Content-Type-Options missing") | Nobody rewrote the output |
| Everything rated High or Critical | Severity inflation to justify the invoice |
| No reproduction steps | Nothing was verified by hand |
| No written scope, no list of what was not tested | You cannot tell what the report covers |
| The same remediation paragraph on five findings | Boilerplate, not analysis |
| A severity with no vector string and no documented scale | The rating is unfalsifiable |
| Zero business logic findings | No scanner finds those; if there are none, none were looked for |
| "Your application is now secure" | No one can promise that |
The last one deserves emphasis. An audit tells you what was found in a defined scope at a point in time. Anyone claiming more is either careless or selling.
Questions to ask before you sign
This is where a provider is qualified or not. The purely budgetary questions — tester-days, manual proportion, retest included or billed — are in the pricing article; the ones about what gets delivered are here.
- What exactly is in scope — hosts, subdomains, API endpoints — and will it be written in the report?
- What is explicitly out of scope?
- Will testing be authenticated? How many accounts and roles do you need from me?
- Can I see a redacted sample report before I pay?
- Does every finding include steps I can reproduce myself?
- How is severity rated — CVSS, OWASP Risk Rating, your own scale — and is that scale explained in the report?
- What proportion of the work is manual? How are false positives removed?
- Is a re-test included after I deploy fixes, within what window, and at what cost?
- Do you issue an attestation, and does it carry any recognised qualification?
- Am I told what came back clean, or only what failed?
- How is the report delivered and protected, and what happens to the report and the evidence after the engagement? It is now a map of my weaknesses.
- What authorization do you need from me in writing before you start?
If the answers are vague on scope, reproduction and re-test, the price is irrelevant.
If you want one
That is the standard I hold my own work to — and if you have not yet done the basic cleanup on your own site, start there. Here is the offer, exactly.
That is what iwantreport.dev sells: one web application and its API, tested against the OWASP Top 10, the API Security Top 10, the CWE Top 25 and the OWASP ASVS — a scanner on the first pass, then every result reproduced by hand before it enters the report. Written report within 48 hours, one re-test included, 200 €, 30-day money-back guarantee: just ask by email within 30 days of delivery. Out of scope: internal network, source code review, phishing and social engineering, load or denial-of-service testing, and mobile applications.