Most organisations buying their first penetration test are really buying reassurance. That is understandable, and it is also the reason so many of them end up with a PDF that reassures nobody.
This is what the deliverable should look like, and how to judge one you have already paid for.
A scan is not a test
An automated scanner reports what might be wrong. It matches versions against a vulnerability database and flags anything that looks outdated. That is useful, cheap, and you should run one continuously.
It is not a penetration test. A scanner cannot chain three low-severity issues into one that matters, cannot reason about your business logic, and cannot tell the difference between a finding that is exploitable and one that is blocked by something else in your stack.
If the report you received is a scanner export with a logo on it, you bought a scan. The tell is usually the finding count: a genuine test of a mid-sized application produces a handful of findings that matter, not ninety.
Every finding should be proved
The single most useful question to ask a tester is: can you show me?
A finding worth acting on comes with the steps taken, the request that was sent, the response that came back, and a description of what an attacker gains. Not a CVSS score and a paragraph of generic remediation advice copied from a template.
Proof matters for two reasons. It tells your engineers exactly what to fix, and it protects you from spending a sprint on something that turned out not to be exploitable in your environment.
Severity should reflect your business
A vulnerability rated critical in the abstract may be irrelevant to you, and a medium may be the one that ends up in the newspaper. Severity is only meaningful once someone has asked what the affected system does, what data it holds, and who can reach it.
Be sceptical of a report where every severity matches the scanner default. That is a sign nobody thought about your context.
The retest is part of the job
Fixing a finding and never verifying the fix is how issues come back. A test should include a retest after remediation, and the final report should state what was fixed and confirmed rather than what was originally found.
That final document is the one you hand to a customer, an auditor, or an investor. It should stand up to someone reading it closely.
Questions worth asking before you buy
- Who is doing the testing, and will the person scoping it be the person running it?
- What is in scope, and just as importantly, what is out?
- Will findings be proved with reproduction steps?
- Is a retest included, or billed separately?
- What happens if you find something critical mid-engagement? How fast do we hear about it?
The answers tell you more than any certification list.
If you would like to talk through what a test would look like for your stack, get in touch. We reply within one business day.