NexusSec.Most businesses buy their first penetration test without being able to judge what they are buying. The proposals look similar, the price range is wide, and the deliverable arrives after the money is spent. Knowing what a good report looks like is the cheapest quality control available to you.
Scan or test?
An automated vulnerability scan runs a tool against your systems and lists what it recognises. A penetration test uses those results as a starting point and then has a person attempt to exploit what was found, chain issues together, and establish what an attacker could actually reach.
Both have a place. The problem is that a scan is sometimes sold at test prices, and the giveaway is in the report. See VAPT versus vulnerability scanning for the longer version of that distinction.
What the report should contain
- An executive summary a non-technical director can read. What was tested, what was found, what it means commercially, what happens next. One page. If the report opens with a CVSS distribution chart, it was written for the tool's convenience rather than yours.
- Findings ranked by business impact, not just severity score. A medium-severity issue on the server holding customer data usually matters more than a high-severity one on an isolated test box. A report that cannot make that distinction has not understood your environment.
- Evidence for each finding. A request and response, a screenshot, the specific parameter, the account that was reached. Enough that your own engineer can reproduce it and confirm it is fixed.
- Reproduction steps and a concrete fix. "Apply vendor patches" is not remediation advice. Which version, which setting, which rule.
- Scope stated plainly, including what was not tested. A report that quietly omits scope boundaries is one you cannot show a customer or an auditor with confidence.
- A retest position. Whether a retest is included, and whether the report will be reissued to show findings closed. This matters, because what you usually need to hand a client is a clean result rather than a list of problems.
Three things that should worry you
A very large number of findings, mostly medium. This is the signature of an unfiltered tool export. A tester's job includes discarding the noise and telling you which handful of things actually matter.
No evidence attached to findings. If a report asserts a vulnerability without showing it, you have no way to verify the finding or confirm the fix, and neither does anyone you show the report to.
Identical wording across sections. Boilerplate that could describe any company suggests the report was assembled from a template rather than written about your environment.
Who reads it, and why that shapes the format
A penetration test report usually has three readers with different needs, and a good one is built for all three rather than only the technical one.
Your director needs to know whether the business is exposed and what it costs to fix. Your IT person, or whoever does the remediation, needs enough technical detail to reproduce and close each finding. And increasingly there is a third reader you never meet: a customer's procurement team, an auditor, or an insurer's underwriter, who will judge your security posture partly on the quality of the document you hand them.
That third reader is the reason scope statements and remediation status matter more than they used to. A report that cannot be shown to an outside party without embarrassment has only done part of its job.
Ask for a sample before you buy
Any provider doing real work has a redacted sample they can send. Asking for one costs you nothing and tells you more than the proposal does. If a sample is not forthcoming, that is information too.
Ask two more questions while you are at it: who performs the testing, and what happens if they break something. The answers separate firms that do the work from firms that subcontract it, and they establish whether anyone has thought about the risk to your live systems. Our own position on both is set out on the VAPT services page.
Frameworks worth knowing about
You do not need to adopt a framework to buy a good test, but knowing the vocabulary helps you read a proposal critically. The CIS Critical Security Controls and the NIST Cybersecurity Framework cover the control areas most reports organise their findings around, and the CIS Benchmarks give vendor-specific hardening guidance that good remediation advice tends to echo. For India-specific advisories on the perimeter devices most commonly deployed here, CERT-In publishes them.
An argument against buying from us
If what you actually need is to know what you have and where you are exposed, a full penetration test may be the wrong first purchase. A security assessment answers that question for less, and frequently identifies work worth doing before a test would be a good use of money. Testing a network nobody has documented tends to produce findings everyone could have predicted.
Where a customer, tender or insurer has explicitly asked for a penetration test, buy the test. Where the driver is your own uncertainty, start with the assessment.
