How to Choose a Penetration Testing Company: The Buyer's Checklist
A practical guide to evaluating penetration testing providers — certifications, methodology, reporting quality, and the questions you should ask before signing.
The Problem With Choosing a Pentest Provider
Penetration testing is one of the few cybersecurity services where the quality of the work is invisible until the engagement is over. You cannot evaluate a pentest the way you evaluate a SaaS product -- there is no free trial, no demo environment, and no way to compare providers side-by-side on the same target. By the time you realize the engagement was subpar, you have already paid for it and your compliance deadline may have passed.
This creates a market where mediocre providers thrive. They produce automated scan output dressed up in a branded template, charge a fraction of what a skilled manual tester costs, and deliver a report that technically satisfies the checkbox requirements of your audit. The findings are real in the sense that a scanner found them. They are useless in the sense that no human ever tried to chain them together, test business logic, or explore the attack paths that actually matter to your organization.
Choosing the right penetration testing company requires knowing what to look for, what questions to ask, and which answers should make you walk away.
Certifications That Actually Matter
The penetration testing industry has a certification ecosystem that ranges from genuinely rigorous to essentially meaningless. Understanding which certifications indicate real capability helps you filter providers quickly.
Tier 1: Hands-On Technical Certifications
These certifications require the holder to actually compromise systems under exam conditions. They are difficult to pass and correlate strongly with practical testing ability.
- OSCP (Offensive Security Certified Professional) -- The industry standard for manual penetration testing. The exam is a 24-hour practical test where candidates must compromise multiple machines and write a professional report. An OSCP holder has demonstrated they can find and exploit real vulnerabilities under time pressure.
- OSWE (Offensive Security Web Expert) -- The web application equivalent of OSCP. Focuses on white-box source code review and exploitation of custom web applications. If your engagement involves complex web applications with custom business logic, OSWE-certified testers bring significant value.
- OSEP (Offensive Security Experienced Penetration Tester) -- Advanced certification covering Active Directory attacks, antivirus evasion, and complex network pivoting. Relevant for internal network and AD-focused engagements.
- CREST CRT/CCT -- CREST certifications are the gold standard in the UK, Europe, and increasingly globally. The Certified Tester and Certified Simulated Attack exams are rigorous, practical assessments. CREST-accredited companies must also pass organizational audits covering their processes, data handling, and quality assurance.
Tier 2: Valuable but Less Definitive
- GPEN (GIAC Penetration Tester) -- SANS-based certification with a strong knowledge component. Good indicator of foundational knowledge but the exam is multiple-choice, not practical.
- eWPT / eCPPT (INE/eLearnSecurity) -- Practical certifications with real-world exam scenarios. Solid indicators of capability, though less recognized than OSCP by enterprise buyers.
What to Watch For
A provider listing only CEH (Certified Ethical Hacker) or CompTIA PenTest+ as their team's qualifications is a yellow flag. These are entry-level certifications that demonstrate knowledge of concepts but do not require practical exploitation skills. They are fine as a starting point but should not be the ceiling for a team you are paying to find real vulnerabilities.
Ask specifically: "Which of your testers hold OSCP, OSWE, or CREST certifications, and will a certified tester be assigned to my engagement?" The answer should be specific names or at minimum a guarantee, not a vague reference to "our team's qualifications."
Methodology Questions to Ask
A provider's methodology determines whether you get a thorough assessment or an automated scan with a human signature on the cover page. These questions separate the two.
"Walk me through your testing process for a web application."
A competent provider will describe something that resembles a structured approach: scoping and reconnaissance, automated scanning as a baseline, manual testing of authentication flows, authorization controls, business logic, input validation across all user roles, session management analysis, and API testing. They should mention testing with authenticated sessions across different privilege levels.
If the answer is essentially "we run our tools and review the output," that is a vulnerability scan, not a penetration test. You will pay pentest prices for scanner output.
"How do you handle business logic testing?"
Business logic vulnerabilities -- price manipulation, workflow bypasses, privilege escalation through legitimate functionality -- cannot be found by automated scanners. They require a tester who understands what the application is supposed to do and then tries to make it do something else. The provider should describe a process for understanding your application's business rules and systematically testing whether they can be circumvented.
"What does your scoping process look like?"
Good providers invest significant effort in scoping before quoting. They want to understand your environment's complexity, the technology stack, the number of user roles, API endpoints, and any compliance requirements that shape the engagement. A provider that quotes a flat rate based on a one-paragraph description of your application has not done enough due diligence to deliver a quality assessment.
"Do you provide retesting after remediation?"
This is a non-negotiable for any engagement that matters. After you fix the findings, you need confirmation that the fixes are effective. Most quality providers include one round of retesting in their engagement price or offer it at a reduced rate. If retesting is not part of the conversation, the provider may be optimized for volume over quality.
For a deeper look at each phase of a professional engagement, see our guide on what to expect from a penetration test.
Red Flags That Should Disqualify a Provider
Some indicators are strong enough to remove a provider from consideration entirely.
Unwillingness to Share a Sample Report
A professional penetration testing company should be able to share a redacted sample report. This is your single best indicator of deliverable quality. If they will not share one, they either do not have reports worth showing or they have not invested in their reporting process. Either way, you are taking a gamble on the most important part of the engagement -- the deliverable you are actually paying for.
When reviewing a sample report, check for the elements described in our guide to pentest report quality. The report should go well beyond a list of scanner findings.
No Named Testers or Team Information
You should know who will be testing your systems. The provider does not need to share full resumes, but they should be able to tell you how many testers will be assigned, their relevant certifications, and their approximate experience level. If the provider treats their testing team as a black box, there is a reasonable chance your engagement will be staffed by junior analysts running automated tools.
Fixed-Price Quotes Without Scoping
A provider that quotes a firm price for "a web application penetration test" without asking detailed questions about your application is not planning to do a thorough job. The cost of testing a five-page marketing site and a complex SaaS platform with 200 API endpoints, role-based access control, and payment processing are vastly different. A provider that charges the same for both is either overcharging for the simple one or underdelivering on the complex one.
See our penetration testing cost guide for realistic pricing expectations across different engagement types.
Purely Automated Deliverables
If the sample report looks like it was generated entirely by a tool -- Nessus, Burp Suite, or Qualys output with a logo on top -- you are looking at a vulnerability scan, not a penetration test. A pentest report should contain narrative descriptions of attack chains, manual findings that no scanner would produce, and business-context risk analysis specific to your environment.
Engagement Models: Project vs. PTaaS
The penetration testing market offers two fundamentally different engagement models, and the right choice depends on your organization's maturity and needs.
Traditional Project-Based Engagements
The classic model: you scope an engagement, a team tests your environment over a defined period (typically one to four weeks), and you receive a report. This model works well for compliance-driven testing where you need a point-in-time assessment, initial assessments of applications or networks you have never tested before, and organizations with annual testing requirements.
The limitation is the point-in-time nature. Your environment changes continuously -- new features, infrastructure changes, dependency updates -- but your pentest reflects the state of things during the testing window.
Penetration Testing as a Service (PTaaS)
PTaaS platforms combine continuous or recurring testing with a technology layer that provides real-time findings, remediation tracking, and retesting workflows. The testing may be fully manual, hybrid (automated scanning with manual verification and business logic testing), or primarily automated with periodic manual deep dives.
PTaaS works well for organizations with continuous deployment pipelines, teams that want findings integrated into their development workflow rather than a PDF delivered quarterly, and environments that change frequently enough that annual testing is insufficient.
The key question for any PTaaS provider is how much manual testing is actually included. Some PTaaS offerings are essentially continuous vulnerability scanning with a pentest label. Ask specifically about the ratio of automated to manual testing and how business logic testing is handled in a continuous model.
Understanding the difference between penetration testing and vulnerability scanning is essential context for evaluating PTaaS offerings, since the line between the two can blur in a continuous model.
How to Evaluate Report Quality
The report is the deliverable. Everything else -- the methodology, the certifications, the team -- exists to produce a report that helps you understand and reduce your risk. When reviewing a sample report, look for these elements.
Executive summary written for non-technical stakeholders. The first section of the report should communicate risk in business terms. A board member reading only the executive summary should understand what was tested, what the overall risk level is, and what the top priorities for remediation are.
Findings with business context. Each finding should explain not just what the vulnerability is, but what it means for your organization specifically. "SQL injection in the search function" is a finding. "SQL injection in the search function allows an unauthenticated attacker to extract the entire customer database, including payment card data subject to PCI DSS" is a finding with context.
Proof-of-concept evidence. Every finding above informational severity should include evidence that the vulnerability is real and exploitable. Screenshots, request/response pairs, and reproduction steps allow your development team to verify and fix the issue without guessing what the tester found.
CVSS scoring with justification. Severity ratings should follow CVSS methodology with enough explanation that you can understand why a finding received its score. Arbitrary "high/medium/low" labels without methodology backing are a sign of an immature reporting process.
Prioritized remediation guidance. Recommendations should be specific and actionable, not generic advice copied from a vulnerability database. The report should help your team understand what to fix first and how to fix it.
The Scoping Conversation
Before engaging any provider, you need to clearly define what you want tested. Ambiguity in scope leads to unmet expectations on both sides. Come to the scoping conversation prepared to discuss:
- Target inventory -- Which applications, networks, or systems are in scope? Provide URLs, IP ranges, and environment details.
- User roles and access levels -- For application testing, how many distinct user roles exist? Will you provide test accounts for each?
- Compliance requirements -- Are you testing to satisfy PCI DSS, SOC 2, ISO 27001, or other framework requirements? This shapes the methodology and reporting format.
- Testing windows -- Are there time restrictions on when testing can occur? Production environments may require off-hours testing.
- Out-of-scope systems -- Explicitly define what should not be tested. This prevents accidental testing of third-party systems or production databases.
- Communication protocols -- How should the tester report critical findings discovered during testing? A critical vulnerability found on day one should not wait until the final report.
Making the Decision
After evaluating multiple providers against the criteria above, your decision should weight these factors in roughly this order:
- Testing team quality -- Certifications, experience, and the specific people assigned to your engagement matter more than anything else. A skilled tester with basic tools will find more than a junior analyst with enterprise tooling.
- Methodology rigor -- Manual testing of business logic, authentication, and authorization is what separates a pentest from a scan. Confirm this is part of the standard approach.
- Report quality -- Review sample reports carefully. This is what you are paying for.
- Retesting included -- Verification that fixes work should be part of every engagement.
- Communication and professionalism -- Responsiveness during the sales process is a strong predictor of responsiveness during the engagement.
- Price -- Relevant, but the cheapest option rarely delivers the best value. A $5,000 engagement that misses critical vulnerabilities is more expensive than a $15,000 engagement that finds them.
Next Steps
If you are evaluating penetration testing providers and want to understand what a properly scoped engagement looks like, our PT Scoping Wizard walks you through the process of defining your testing requirements. It produces a structured scope document you can share with any provider for accurate, comparable quotes.
For an overview of what the engagement process looks like end-to-end once you have chosen a provider, read what to expect from a penetration test. And if you are still working out your budget, our penetration testing cost guide covers realistic pricing across different engagement types.
Explore our full range of security assessment services to find the right fit for your organization.
Continue Reading
How Much Does a Penetration Test Cost? A Realistic Pricing Guide
Penetration testing pricing demystified — typical costs by test type, what drives price differences, and how to budget for security assessments that actually matter.
Penetration Test vs. Vulnerability Scan: What You Actually Need
Penetration testing and vulnerability scanning are not interchangeable. Learn the real differences in methodology, depth, cost, and when each one is required.
API Security Testing Checklist
A systematic checklist for testing API security covering authentication, authorization, rate limiting, input validation, error handling, CORS, TLS enforcement, and versioning with practical curl and httpie command examples.