Anatomy of a report
What is inside a Vanorika security report.
Every report follows the same eight sections in the same order. Here is each one, what goes in it and why it is there, followed by a sample you can explore.
Security test report
- Client
- Zuva Shop (fictional)
- Report
- Web application security test
- Reference
- SAMPLE 01
- Version
- 1.0, final
Section by section
Eight sections, always in this order.
- 01
Cover
- What is in it
- Your name, the report title, a reference, the date, the version and whether it is a draft or final.
- Why it is there
- Everyone discussing the report knows they are reading the same version.
- 02
Summary for the owner
- What is in it
- What was tested, where you stand in plain words, the findings by severity in one sentence, and what to do first.
- Why it is there
- An owner or board can understand the risk in two minutes without reading the technical detail.
- 03
Scope and authorisation
- What is in it
- What was in scope and out of scope, the test window, the environment, and the written authorisation: who approved it, their role, the date and a reference.
- Why it is there
- Testing without written permission is not testing. This page proves the work was authorised and shows exactly what was and was not looked at. How authorisation works
- 04
Method
- What is in it
- What was done, and the limits of the work: time boxed, a point in time, and no guarantee that other issues do not exist.
- Why it is there
- An honest report says what it cannot prove, so nobody mistakes a test for a guarantee. Read the methodology
- 05
Findings
- What is in it
- Confirmed findings only, ordered by severity. Each has an ID, a title, the severity in words, the affected asset, a plain summary of what could happen to the business, the technical detail, evidence with secrets masked, the fix and its retest status.
- Why it is there
- Developers get what they need to fix it and owners get what it means. Severity is set on the impact shown in your setup, not on a tool's default score.
- 06
Needs validation
- What is in it
- Observations that could not be confirmed, what would confirm them, and who needs to provide it. None of them carries a severity.
- Why it is there
- An unconfirmed issue is never dressed up as a finding to make a report look bigger.
- 07
Retest notes
- What is in it
- What was tested again, when, and the result for each finding.
- Why it is there
- A fix only counts as closed once it has been tested again.
- 08
About the tester and contact
- What is in it
- Who did the work and how to reach them.
- Why it is there
- You deal directly with the person who tested your systems.
What you receive
Included with every security test.
- A written report with all eight sections above
- A plain language summary for the owner
- A record of the written authorisation and scope
- Evidence and a fix for every confirmed finding
- A retest after you fix, with the result recorded
The findings, up close.
A real engagement ends with a document like this one. Every finding in plain language, ranked by risk, with a fix you can hand to your developers and a retest to confirm it is closed. This sample is for a made-up shop so you can see the shape of it.
- Target
- Zuva Shop, web and API
- Type
- Authorised, manual
- Findings
- 6 across four levels
- Retest
- Confirmed fixes
Executive summary
The shop was solid on the surface but had two serious gaps behind it: an admin area anyone could open, and an orders feature that let one customer read another customer's details. Both would have mattered to real people. All of the serious findings were fixed and confirmed on retest, with one medium item left for the next sprint.
What we found
The /admin area loaded for anyone who typed the address. No login or role check stood in the way.
Why it matters
A stranger could read orders, change prices and export customer records straight from the browser.
The fix
Require authentication and an admin role on every admin route, checked on the server, not just hidden in the menu.
Yours would read like this, with your systems and your findings. Authorised, by hand, retested until the serious ones are closed.
Everything above is a fictional sample for illustration. Real reports are private to the client and never published.
See all security services