Sample report
Read the report
before you buy the test.
This is a complete AppSec Labs penetration test report — 132 pages, 32 findings, every chapter and appendix intact. The template, the methodology, the severity model, the evidence conventions and the remediation guidance are exactly the ones we ship. The customer in it is ours to invent, because a client’s report is theirs alone.
What this is
Real work. An invented customer, on purpose.
The most-requested artifact in a penetration testing deal is the one almost nobody publishes — because publishing one usually means publishing a client’s. This is how we get to hand you the whole thing instead.
It is the work we do
Produced from the same house template as a live deliverable, by the same people, to the same standard. The findings are modelled on what our engagements actually turn up — weighted towards authorisation and business-logic defects rather than header hygiene, and chained into one end-to-end attack path the way a real one is.
Your report will never become a sample
Confidentiality is not something we relax for marketing. Rather than hand out a client’s engagement with the names taken out, we wrote a complete one of our own — "Contoso Ltd." is a reserved fictional company and every host sits in .example, which RFC 2606 set aside so it can never be registered. You get the same undertaking.
No form, no email address
The download is a link. We would rather you read it and decide than trade it for your contact details.
At a glance
What is in the document
- 132pages
- 32findings
- 3critical
- 6high
The remaining findings are 9 medium, 10 low and 4 informational. They are in the document in full — a report that quietly drops the low-severity work is hiding how much of the test actually happened.
Chapter by chapter
How it is put together
The order is deliberate: the reader who has ten minutes and the reader who has to fix it are not the same person, and the document serves both without making either read the other’s chapter.
Document control
Who tested, who received it, what changed between versions, and how the document is meant to be handled. A report with no provenance is hard to put in front of an auditor.
Chapter A — who did the work
The firm, the people, and the basis of the methodology. Short, because the reader came for the findings.
Chapter B — executive summary
Written for someone who will read two pages and no more: the risk position, the one attack chain that matters, the five fixes that remove most of the risk, and — unusually — what the engineering team got right.
Chapter C — testing methodology
What was in scope, what was tested against each role, what was deliberately not tested, and where the assessment was constrained.
Chapter D — summary of vulnerabilities
Every finding on one page: severity, title, affected component, status. This is the table that gets pasted into a ticket tracker.
Chapter E — the findings in full
32 findings, each on its own pages, in the anatomy set out below.
Chapter F — remediation roadmap
The findings re-ordered as work: what to do first, what it costs in engineer-days, and which structural changes stop the same class recurring.
Appendix A — attacks and tests
The catalogue the engagement drew on, so the scope of the testing is inspectable rather than asserted.
Appendices B–D
The severity model and CVSS basis, the environment, accounts and tooling used, and a control mapping for the compliance readers.
Anatomy of a finding
What every finding carries
This is where a report is won or lost. Chapter E, finding 3 is a good one to read first — a tenant-scoping defect on a reporting endpoint, which is the kind of flaw a scanner cannot reach and a checklist does not describe.
Threat level, and why
Severity is argued from exploitability and business impact in this system, not inherited from a generic score. The CVSS v3.1 vector, the CWE and the OWASP category are printed in full, so you can disagree with the rating and so the finding can be tracked against whatever framework your programme reports on.
Business impact, in the client's terms
What an attacker gets. Written about payroll and tenants, not about "possible information disclosure".
Reproduction steps
The exact requests, in order, with the values that matter highlighted. An engineer reproduces the finding without asking us anything.
Evidence
Request and response panes, terminal sessions and application state, annotated. Rendered as vector, so it stays sharp at any zoom.
Root cause
The defect in the design or the code — not a restatement of the symptom.
Mitigation, with the corrected code
What to change, shown before and after where a code-level fix exists. The retest verifies this specific change.
Against severity inflation
We mark findings down more often than up
A padded report is the buyer’s real fear, and it is a reasonable one. Four numbers out of our own production records, most of which cut against us:
- 6,643findings on record
- 114 : 3we lowered in severity, against raised
- 5median findings in a project
- 234of 890 projects found nothing
Recomputed from findings recorded on our platform between October 2021 and August 2026 — 6,643 findings across 890 projects for 167 customers — on the severity we authored, not the severity left behind after a fix. Earlier work predates the platform and is not counted, so these are floors. The severity revisions are measured across the 5,771 findings still open.
What it is not
Three things worth saying plainly
It is not a specimen of your report
Yours will be shorter or longer, and shaped by what your system actually is. 32 findings is well above our median of 5.
Its figures are illustrative
The monetary values, user counts and tenant names exist to make the business-impact sections concrete for a system nobody can log into. Ours are the production numbers above.
It is a report, not a verdict
A penetration test report is by construction a list of defects. The sample includes a section on what the engineering team got right, because a real one should.
Want to know what yours would look like?
Tell us what the system does and who logs into it. We will come back with scoping questions, a clear proposal and a realistic date — and if a penetration test is not what you need yet, we will say so.