How to Choose a Penetration Testing Company (2026 Buyer’s Guide)
A practitioner's 2026 buyer's guide on how to choose a penetration testing company: what to look for, the red flags to avoid, and the questions to ask.

A prospect forwarded us a competitor’s pentest report a while back and asked one question: is this any good? It was 60 pages, branded, confident. It was also a Nessus scan with the tool’s name swapped out. No manual testing. No business logic. No proof that anyone had actually broken into anything. Just CVSS scores and a “medium” rating on a missing HTTP security header.
We see that report, or a close cousin of it, all the time. And it gets to the heart of how to choose a penetration testing company, because the deliverable looks nearly identical whether a senior tester spent two weeks living inside your app or a script ran overnight. The invoice can look similar too. This guide is about reading past the cover page and telling real testing apart from scan-and-dump.
We run offensive engagements for a living. We know what a good one costs to deliver, and we know exactly where the corners get cut when it is cheap. Here is what we would check if we were sitting on your side of the table.
Key takeaways
- Judge the tester, not the logo. Ask who is on your engagement, their years in offensive security, and their certs (OSCP, OSWE, CREST, GPEN) – not the vendor’s marketing.
- Demand a methodology mapped to a public standard (OWASP WSTG, OWASP ASVS, PTES) and a redacted sample report you can read before you sign.
- Retesting after your fixes should be included, not a paid add-on. A pentest with no validation retest is half a service.
- The clearest red flag: a fixed low price, a 24-hour turnaround, and no scoping call. That is an automated scan wearing a suit.
- Manual business-logic and access-control testing is where the real risk lives. Scanners miss almost all of it.
What does a penetration testing company actually sell?
A penetration test is a time-boxed, goal-driven attack on your systems by a human trying to break in the way a real adversary would. That is the whole point. A person reasons about your specific application, chains small issues into a real breach, and proves impact. A vulnerability scan feeds that work, but on its own it is not a penetration test.
This matters because both get sold under the same word at wildly different quality. So when you are working out how to choose a penetration testing company, you are really working out one thing: am I buying human expertise, or automation with a markup? We dug into that split in a separate piece on penetration testing vs vulnerability scanning, but the short version is simple. Scanners find known signatures. Testers find logic.
Here is the uncomfortable part. The findings that actually get companies breached – broken access control, IDOR, authentication bypass, SSRF that pivots into cloud metadata, business-logic abuse in a checkout or funds-transfer flow – are almost never surfaced by a tool. OWASP ranks Broken Access Control as the number one web risk, and in our engagements access-control and logic bugs are consistently the highest-severity things we report. No scanner walks your multi-step workflow and notices that a request like GET /api/v2/accounts/1043/statements happily returns account 1044 when you change one digit. A person does.
What should you look for in a penetration testing company?
Four things: the people, the method, the deliverable, and what happens after the fixes. The rest is packaging.
Senior testers, named and credentialed
Ask directly. Who will be on my engagement? How many years have they spent doing offensive work? What have they published, presented, or reported? A strong shop answers without flinching. Certifications are a reasonable proxy for hands-on skill – OSCP and OSWE from Offensive Security, CREST CRT and CCT, GPEN and GXPN all make you actually exploit things instead of ticking multiple-choice boxes. One caveat we will repeat: certs are a floor, not a ceiling. A tester with a wall of badges and no instinct for logic flaws will still hand you a scanner dump.
Watch for the bait-and-switch. A polished senior consultant sells the work, then a junior with a scanner delivers it. Get the named tester in writing.
A methodology you can check against a standard
A credible vendor maps their work to something public. For web apps that means the OWASP Web Security Testing Guide (WSTG) and OWASP ASVS for coverage depth, and PTES for the shape of the overall engagement. If a vendor cannot tell you which categories they cover, and how they test authentication, session management, access control, injection, and business logic, that is a problem you can hear in the first call.
Ask what portion of the test is manual. On a web engagement, the automated pass – a Burp Suite active scan, some nuclei templates, ffuf for content discovery – is maybe the first day. The value comes after that. That is when a human is tampering with JWTs, testing every object reference for IDOR, and abusing the one workflow the developers assumed nobody would ever poke at.
A sample report you would actually act on
Insist on a redacted sample before you buy. Read it as an engineer, not as a buyer. A good finding has a clear title, business impact in plain English, exact reproduction steps (the request, the parameter, the payload), evidence, a severity you can defend, and a specific fix. Not “cross-site scripting detected – remediate.”
If the sample is a scanner export with a new logo, you have your answer. The test: your developers should be able to reproduce and fix a finding from the report alone, with no follow-up call to translate it.
Retesting included, not upsold
This one sorts the serious firms fast. After you remediate, someone has to verify the fixes actually work and did not open new holes. That retest belongs inside the engagement, not on a later invoice. We treat it as part of the job, because a pentest that stops at “here are the bugs” leaves you guessing whether you are safe. A clean retest also happens to be exactly what your auditors and enterprise customers want to see.
What are the red flags when choosing a pentest vendor?
The loudest one: a fixed, suspiciously low price, a 24-to-48-hour turnaround, and no scoping conversation. Real testing cannot be priced accurately without understanding your scope – how many applications, how many roles, how many API endpoints, whether it is authenticated, what your goals are. A firm that quotes before it asks is quoting for a scan.
A few more we run into constantly:
- “We use AI-powered testing” as the entire pitch. Automation helps us too. But if the differentiator is a tool rather than the people driving it, you are buying the tool.
- No proof of exploitation. “Potentially vulnerable” plus a CVSS score and no reproduction is a scanner guess. Real findings show the request and the result.
- Report and run. A good engagement ends with a call where the testers walk your engineers through the criticals and answer the awkward questions.
- Everything is critical, or everything is info. Miscalibrated severity means nobody reasoned about your actual risk. Also watch for reports padded with low-value informational findings to look thick.
- They dodge the “who is testing” question. If they will not name the tester or the certs, assume the answer is one you would not like.
What questions should you ask a penetration testing company?
Take these into the sales call. The answers tell you more than any brochure.
- Who specifically will test my systems, and what is their offensive-security background and certifications?
- What percentage of this engagement is manual versus automated, and which standard (OWASP WSTG, PTES, ASVS) do you follow?
- Can I see a redacted sample report before I sign?
- Is a validation retest after remediation included in this price?
- How do you handle business-logic and access-control testing specifically?
- What do you need from me to scope this accurately, and what does the timeline look like?
- Will there be a live debrief with my engineering team?
Specific, confident, consistent answers are a good sign. Vague ones, or every question routing back to a price sheet, are your cue to keep looking.
How CyberXplore approaches it
We built our web application penetration testing service around the things buyers should be demanding: named senior testers, a methodology mapped to OWASP WSTG and ASVS, reports your developers can act on without a translator, and a free retest after you remediate. Every critical finding ships with the exact request, the payload, and reproduction steps, plus a live debrief with your team. We would rather over-explain a bug than hand you a CVSS number and leave. If you want a scoped, honest quote for your environment, request a quote and we will start with a scoping conversation, not a price tag.
FAQ
How much should a penetration test cost?
It depends on scope and depth, so treat any fixed price quoted without a scoping call with suspicion. A single small web app is a very different job from a large authenticated platform with dozens of API endpoints and several roles. The right question is not “what is cheapest” but “what am I getting for this” – manual testing, a real report, and a retest, or a scan in a PDF.
What certifications should a penetration tester have?
OSCP and OSWE from Offensive Security, CREST CRT or CCT, and GPEN or GXPN are all solid signals, because they require candidates to actually exploit systems rather than memorize theory. Treat certs as a minimum bar, not proof of excellence. Years of real engagement experience and a nose for business-logic flaws matter just as much.
Is a penetration test the same as a vulnerability scan?
No. A vulnerability scan is an automated check for known issues and misconfigurations. A penetration test is a human actively trying to break in, chaining findings and proving real-world impact. A good pentest uses scanning as one early input, then spends most of its time on the manual work tools cannot do, like access-control and logic testing.
How long does a penetration test take?
Most focused web application engagements run one to three weeks of active testing, plus reporting, depending on scope. A same-day turnaround almost always means an automated scan rather than manual testing. Leave room for a retest after your team fixes the findings.
Should retesting be included in the price?
Yes. After you remediate, a tester should verify the fixes actually closed the issues and did not open new ones. If a vendor bills separately for that validation retest, fold it into the total cost and ask yourself whether the first engagement was ever really complete without it.
What is the single biggest red flag?
A low fixed price with a fast turnaround and no scoping conversation. Accurate testing cannot be quoted without understanding your applications, roles, and goals. A quote that lands before anyone asks a real question is almost certainly for an automated scan, not a penetration test.



