We're getting our first pentest report, what should a good report include and what should we watch out for?

Look at the CVSS scoring logic for each vulnerability in the report. A generic 'Critical' or 'Medium' tag isn't enough. The vector string should be explicitly stated, and request bodies or PoC commands proving the finding is genuinely exploitable must be included. Without those, your developers will be flying blind when trying to patch it.

When the report lands on your desk, check these three things: 1) Did they go out of scope, or did they scan all the subdomains outlined in the contract? 2) Can each finding's vulnerability be reproduced step by step? 3) Are the remediation recommendations tailored to your OS and the libraries you actually use?

edit: I wrote something wrong above, sorry about that.

On our first test in Paris, which we paid 5,200 Euro for, we got 48 findings. Upon review, we realized 22 were just trivial server version banners. We pushed back, filtered them out, and focused on the remaining 6 critical flaws. It's not the page count of the report that matters, it's the number of verified critical findings.

Set up a meeting with your developer once the report is delivered. Try triggering the top two highest-priority vulnerabilities directly in your dev environment using the exact steps described in the document. If your dev can't reproduce the issue by following those steps, the report is deficient—ask the pentester for a live demo.

we panicked seeing pages of ssl warnings in our first report turns out the scanner just dumped it automatically. the guy hadn't even manually tested a single api injection. tbh reject any report that doesn't have screenshots or payloads right away.

note: I wrote this based on my own experience, it might not apply to everyone.

Did you agree on a black-box or white-box scope when drawing up the contract? If you gave them source code or a test account, the report should document much deeper logical privilege escalation flaws. The scope type directly dictates what you should expect from the report.

Most companies shelve the pentest report the moment they get it. Just as critical as the report's quality is whether your deal includes a post-remediation re-test. If a re-test isn't included, that report is nothing more than an expensive document showing past issues.

I felt relieved reading this answer, so it's not just me. An automated scan report is not the same as a penetration test.

I'm also curious if anyone does it differently.

Three different views emerged, they all complement each other. An automated scan report is not the same as a penetration test.

Hope this helps.

If you're going this route, sort this out first. Don't hesitate to ask; those who don't ask always pay more.

Good luck with that.

This thread is archived.

noted thanks.

You're right, I've been down that road too. Just because everyone does it doesn't mean it's right.

Correct me if I'm wrong.

do you think this works at any scale? if you get three different answers on a topic the question was asked wrong.

the answer varies greatly by industry; there is no one-size-fits-all rule. good luck with that.

You're right.

There's a common mistake people make when doing this. If 2FA is on, a stolen password alone is useless.

If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection. If you have questions, write them; I'll answer as best I can.

Timely topic.

i agree, and I'd like to emphsize that... processes without records never improve, because you don't know what to fix.

the answer varies greatly by industry; there is no one-size-fits-all rule. this is my opinion, I'm not claiiming it's absolute truth.