Red flags in the report: every finding is a CVE with a stock description and raw CVSS (a relabelled scan); no manual findings (no chained bugs, logic flaws or access-control bypasses); no proof-of-concept or reproduction steps; no business context or risk-based severity; a template report with your logo dropped on; a clean result with no evidence of effort. Red flags in the process: no real scoping conversation; an unusually cheap/fast quote; refusal to share a sample report; no named testers or certs; no critical-finding escalation; no readout call; retesting billed as a whole separate engagement. A good test shows human effort, proves impact, explains business risk, and closes the loop with a retest. The ten flags, explained, below.
// 01 Flag 1–3: it's a scan wearing a costume
The most common bad pentest is a vulnerability scan relabelled. Three tells give it away. (1) Every finding is a CVE with a stock description — the exact text a tool emits, nothing that required a human. (2) There are no manual findings: no access-control bypasses, no business-logic flaws, no vulnerabilities chained together into a real attack — all the things a scanner structurally cannot find. (3) Severity is raw CVSS only, pasted from the tool, with no adjustment for your context. A scan is a fine input to a pentest, but on its own it is not one — and if the whole report could have been generated by running a tool and exporting the results, that's exactly what happened. You paid pentest prices for a scan.
// 02 Flag 4–5: no proof, no context
Two more report failures separate real testing from theatre. (4) No proof-of-concept. A genuine finding shows how it was exploited — the request, the response, the screenshot, the reproduction steps — so your team can confirm it and fix it. “Possible SQL injection detected” with no demonstration is a scanner's guess, not a tester's finding; it may not even be real. (5) No business context. A good report explains what a finding means for you: this flaw exposes customer data, this one lets a low-privilege user reach admin, this one is theoretical and low priority. Without that, you get a flat list where a cosmetic issue sits next to a critical one and nobody can tell which is which. The whole point of a report is to help you prioritise — a list with no proof and no context does the opposite.
// 03 Flag 6–7: the template & the suspicious “clean”
Template report
Generic boilerplate with your logo dropped on — identical structure and language regardless of your environment. Real reports are tailored.
Effortless “clean”
“No vulnerabilities found” with no evidence of what was tested or attempted — suspicious, not reassuring.
A clean report isn't automatically good. It might mean you're genuinely strong — or that testing was shallow. The way to tell is evidence of effort: a credible clean result documents what was tested, which attack paths were attempted, and why the tester is confident. A clean result with no depth, no attempted exploitation and no reasoning should be met with suspicion, not relief. Learn to read for this in how to read a pentest report.
// 04 Flag 8–10: the process gives it away early
You can often spot a bad pentest before the report — in how the provider behaves. (8) No real scoping conversation, just a price: a provider who doesn't ask probing questions about your assets and objectives isn't planning to test deeply (see how scoping should work). (9) An unusually cheap and fast quote: real testing takes tester-days, and a price that undercuts everyone while promising to “test everything” instantly is quietly telling you it's a scan. (10) No retest, no readout, no transparency: refusing to share a redacted sample report, no named testers or verifiable certifications, no defined critical-finding escalation or readout call, and retesting treated as a whole separate engagement rather than part of the service. Each of these says the same thing: depth and partnership are not what you're buying.
// 05 What a good test looks like instead
Invert every flag and you have the standard to demand. A good test is scoped through a real conversation to your actual risk. It's human-led, so the report contains findings a scanner never could — chained vulnerabilities, logic flaws, access-control bypasses — each with a proof-of-concept and reproduction steps. Severity is risk-based and explained in business terms, so you know what to fix first and what to ignore. The report is tailored to your environment and mapped to your compliance framework where relevant. And the engagement closes the loop: a readout call to walk through the results, and a retest confirming your fixes worked, producing evidence you're now secure. That's the difference between a document that makes you feel safe and a test that tells you whether you are — the standard set out in our methodology. If your last test tripped these flags, that's the cue to change providers.
// 06 Frequently asked questions
How can I tell if my pentest was actually a scan?
Look at the findings. A relabelled scan is a long list of generic CVEs with stock descriptions and raw CVSS scores, but no findings needing human insight — no chained vulnerabilities, logic flaws or access-control bypasses, and no proof-of-concept showing real exploitation. If every finding could have come straight from a tool's output, you likely received a scan dressed up as a pentest.
What should a good report contain?
An executive summary in business language; each finding with a clear description, risk-based severity reflecting real impact (not raw CVSS alone), reproducible steps or proof-of-concept, and specific remediation guidance. It shows evidence of manual testing, maps to your compliance framework where relevant, is tailored to your environment (not a template with your logo), and distinguishes what matters from noise.
Is finding no vulnerabilities a red flag?
It can be. A clean report isn't automatically good — it may mean a strong environment, or shallow testing. The tell is evidence of effort: a credible clean result shows what was tested, what techniques were attempted, and why the tester is confident. If it claims no issues but shows no depth or reasoning, treat it with suspicion rather than relief.
What process red flags indicate a bad provider?
No real scoping conversation, just a price; an unusually cheap and fast quote; refusal to share a redacted sample report; no named testers or verifiable certifications; no critical-finding escalation path; no readout call; and retesting treated as an expensive separate engagement. A provider who can't explain their methodology, or promises to test everything cheaply and instantly, is signalling shallow depth.
// 07 Related reading
- 15 questions to ask a vendor — catch the flags before you buy.
- Manual vs automated testing and how to read the report.
- How to choose a provider and why retesting matters.