How to choose a penetration testing vendor: the questions that matter

Penetration testing vendors are hard to tell apart from the outside. Every site promises expert testers, comprehensive coverage, and actionable reports. The differences that matter are not on the homepage; they surface when you ask specific questions and listen for specific answers. Here are the ones worth asking before you sign.

Will every exploitable finding come with a proof of exploit?

This is the single most clarifying question. A vendor that proves exploitable findings with a working demonstration is selling a penetration test. A vendor that hedges, or whose sample report is full of potential and possible issues, is selling scan output at pentest prices. Ask to see a sanitized sample report and check the findings for proof, not just severity labels.

What methodology do you follow, and how do you scope?

A credible vendor will name a recognized methodology (OWASP, NIST SP 800-115, PTES) and walk you through how they scope an engagement, including how much access they want and why. Be wary of a vendor that does not push you toward giving them more access; the ones who understand testing know that lighter-access engagements find more, and they will tell you so.

Questions worth asking outright

• Will every exploitable finding include a working proof of exploit and reproduction steps?
• Is a retest to confirm fixes included, or billed separately, and is it bounded?
• Who actually performs the test, and what are their qualifications?
• How do you handle a critical finding discovered mid-engagement?
• Will the report map findings to the framework I need (SOC 2, PCI, HIPAA)?
• How do you minimize false positives, and what does your QA look like?
• What does the report look like for an engineer, a leader, and an auditor?

Listen for false positives

Ask how they keep false positives out, and listen closely. A serious tester treats a false positive as a failure, because every unproven finding is time stolen from your engineers. A vendor that shrugs at false positives is telling you their report will create work rather than remove it. We cover why proof is the antidote in what is a proof-of-concept exploit.

What happens after the report

The engagement is not done at delivery. A good vendor includes, or clearly offers, a retest to confirm your fixes worked, and gives your team a way to ask questions about findings. If the relationship ends the moment the PDF lands, you bought a document, not a security outcome.

Uvy was built to answer these questions the right way by default: every exploitable finding proven, a bounded retest to confirm closure, reports written for all three audiences, and a relentless focus on keeping false positives out. See how it works.