VAPT report sample

Why we publish a sample report

Security testing is bought largely blind. Proposals describe methodology in language that is nearly identical across firms, and the deliverable, the only thing you actually receive, is usually seen for the first time after you have paid for it.

Publishing a redacted sample is the simplest way to fix that asymmetry. Read it before you commission anything, from us or from anyone, and you will know what questions to ask.

What you should be looking for is not the findings. It is the structure: whether a developer could act on a finding without calling the author, whether severity is argued or asserted, and whether the report tells you clearly what was not covered.

How to read any penetration test report

Start with the scope section, and read it as a statement of what was not tested. Every report has boundaries. A report that does not state them clearly is hiding them, and the gap between what you believed was tested and what was tested is where post-engagement surprises live.

Next, look at a single finding in detail. Does it contain the exact request or payload, the precise conditions, and steps somebody who was not present could follow? If reproduction is described in prose rather than shown, the finding was probably not reproduced.

Then look at severity. A severity copied from a public database tells you how bad this class of issue is in general. A severity argued from what an attacker could reach on your estate tells you how bad it is for you. The second requires the tester to have understood your architecture.

Then check for a clean statement. Does the report say plainly what was tested and found sound? Reports that only enumerate problems are optimising for the appearance of value.

Finally, look at the remediation section. Is it sequenced by what to do first, or is it an undifferentiated list that hands the prioritisation problem back to you?

What separates a test from a scan

The distinction matters commercially because both are sold under the same name at very different prices.

A scan runs tooling, collects output and formats it. It finds known vulnerabilities in known software versions, which is genuinely useful and should be running continuously anyway. What it cannot find is anything that requires understanding what your application is for.

Authorisation flaws are the clearest example. Automated tooling does not know that account 4,00,112 and account 4,00,113 belong to different people, so it cannot tell you that one can read the other's records. Business logic abuse is the same: whether a claim can be submitted twice through different routes is a question about your process, not your code.

In our experience the findings clients care most about, the ones that change a launch date, are almost always in those two categories. They are found by a person, by hand, and they are the reason manual days are the number worth comparing between proposals.

What to do with a report once you have one

Hold the walkthrough and let your engineers argue. That session is the most useful hour of the engagement. Findings get downgraded when a compensating control the tester could not see turns out to exist, and occasionally upgraded when your team knows something about the data that the tester did not.

Track remediation against the finding, not against a ticket title. The commonest failure we see on retest is a fix that closes the specific case in the report and leaves the same class of issue open two endpoints away.

Retest everything, and be suspicious of any firm that bills for it separately. A report describing a vulnerability that is still present is not a deliverable.

Then feed the findings backwards. If the same class of issue appears in consecutive assessments, the problem is in your development process rather than in your code, and another test will not fix it.

What should be in scope, and what usually is not

Scope decisions are made early, quickly and often wrongly, because they are made before anyone has looked at the estate. Three that recur.

Authenticated testing is sometimes cut to reduce cost. It is the single worst place to economise, because the findings that change decisions, authorisation flaws and business logic abuse, are only reachable with a valid session at each privilege level.

Integration and third party interfaces are frequently excluded because they belong to somebody else. They are still your exposure, and they are frequently the weakest part of an otherwise sound application because they were built quickly under delivery pressure.

Non-production environments holding production data are almost never in scope and are a common actual breach path, because the controls applied to production were not applied to the copy.

How often, and against what

An annual test against a fortnightly release cycle tells you about an application that no longer exists. The pattern that works is a full assessment annually, focused testing on significant changes, and continuous automated scanning underneath both.

Retest after remediation is not the same as the next annual test. It closes the specific findings and, more usefully, tells you what proportion of your fixes were partial.

If the same class of issue appears across consecutive assessments, the problem is in the development process rather than in the code, and another test will not fix it. That is the point at which secure development training or a code review gate is worth more than more testing.