You have budget approved for a penetration test. Now you have to pick who runs it, and the market makes that genuinely hard. Every vendor claims "manual, expert-led testing," every proposal looks similar, and the cheapest quote is often an automated scanner with a cover page while the most expensive is not always the deepest.
The wrong choice costs more than money. A shallow test that misses an exploitable flaw gives you a false sense of security and a compliance checkbox that does not reflect reality, until an attacker finds what the tester did not. The right choice gives you findings your engineers can actually fix and evidence an auditor will accept.
This guide is the buyer's version: how to decide between an individual tester, a firm, and a platform, the specific skills and certifications that signal real capability, the red flags that reveal scanner-only testing dressed up as a pentest, and how to read a sample report so you can tell depth from noise before you sign anything.
Individual, Firm, or Platform: What You Are Actually Hiring
"Penetration tester" covers three very different things, and picking the wrong category is the most common and most expensive mistake.
An individual contractor is a freelance tester you engage directly. Lower cost and a direct line to the person doing the work, but single-person coverage, limited availability, and no bench if they are booked or leave mid-engagement.
A firm or consultancy brings a team, a documented methodology, compliance credibility, and named consultants. It is the traditional default for annual compliance and complex scopes, at a higher price and a two-to-four-week turnaround.
A code-aware platform runs continuous, autonomous testing that plugs into your pipeline. It fits fast-shipping teams that need coverage between engagements, and it is a different model than paying for a person's time, one we break down in the automated pentesting guide.
The honest way to choose is by your situation, not the vendor's pitch.
Your situation | Best fit |
|---|---|
One-off compliance test, stable app, annual cadence | Firm, or a platform with an audit-grade report |
Fast-shipping SaaS, weekly deploys, code-heavy | Code-aware platform, plus a periodic manual engagement |
Tight budget, a single small app, low complexity | Vetted individual contractor |
Complex business logic, red-team scenarios | Firm or elite individual with domain depth |
Regulated enterprise, multiple apps, continuous evidence | Platform for coverage plus a firm for the annual sign-off |
Most mature programs end up hybrid: continuous automated testing for coverage between engagements, and a periodic human engagement for the deep business-logic work automation cannot reach. The continuous vs annual comparison covers why.
The Skills That Separate a Real Penetration Tester From a Scanner
Ignore the marketing and evaluate for capability. Five skill areas separate a real tester from someone running a scanner.
Manual exploitation and attack-chain construction. The defining skill is chaining vulnerabilities into a working exploit, not producing a flat list of isolated findings. Ask a candidate to walk you through a recent engagement where they combined two or more low-severity issues (an IDOR plus a privilege escalation, an SSRF plus a credential exposure, or a mass-assignment flaw plus an insecure deserialization sink) into a critical breach. On the infrastructure side, that same skill shows up as chaining reconnaissance and OSINT into an initial foothold, then Kerberoasting or pass-the-hash into lateral movement and Active Directory compromise. Someone who only runs tools cannot tell that story convincingly.
Modern-architecture coverage. Your stack is probably API-first, cloud-native, and multi-tenant. The tester needs real depth in API security (REST, GraphQL, gRPC, including mass assignment, XXE, and injection in each), authentication and authorization (OAuth, JWT, SAML, session handling), cloud IAM and misconfigurations, and multi-tenant isolation. A tester whose methodology assumes Windows Server 2008 will miss most of your actual attack surface. The types of penetration testing guide covers the gray-box knowledge model that catches these.
Business-logic testing. Automated tools test known patterns. A skilled human finds the application-specific flaw: a discount code that stacks to make an order free, a workflow that can be replayed to double-credit an account, a race condition in a payment flow. This needs understanding of business intent, and it is exactly where human expertise earns its premium.
Exploit validation, not detection. The tester must prove a vulnerability is exploitable with a working proof-of-concept, a curl command or a script, rather than flag a theoretical issue from a version banner. This is the difference between a pentest and a vulnerability scan, which we cover in What Is VAPT? Vulnerability Assessment vs Penetration Testing.
Clear, developer-ready reporting. A finding is worthless if your team cannot act on it. Look for the exact file and line where possible, reproducible steps, a business-impact explanation, and remediation guidance written for your stack, not a generic "implement input validation."
Penetration Testing Certifications: What They Signal and What They Do Not
Certifications are a useful filter, not a guarantee. They tell you someone passed a bar, not how they will perform on your specific stack. Weight the hands-on ones.
OSCP (OffSec Certified Professional). The strongest single signal of practical skill. The OSCP requires passing a roughly 24-hour hands-on exam that compromises live machines, so it is one of the few certs that proves real exploitation ability rather than multiple-choice knowledge.
CREST. CREST is an accreditation body for both individuals and firms, widely recognized by auditors and often required in the UK and increasingly elsewhere. A CREST-accredited firm is a strong compliance signal.
OSWE (OffSec Web Expert). The web-application counterpart to OSCP, focused on source-code review and advanced web exploitation. A strong signal for anyone testing a code-heavy web product.
GPEN and GWAPT (GIAC). GPEN indicates network-penetration depth, GWAPT web-application depth. Well regarded and often held alongside OSCP.
OSEP and GXPN. Advanced evasion and exploitation certifications (OffSec and GIAC) that indicate a tester who can get past modern defenses, relevant for red-team-style work.
PNPT (TCM Security). A practical, report-graded exam that includes a client debrief, so it signals both exploitation and communication skill.
CEH. Broadly known, but more theory-weighted than hands-on. Treat it as a baseline, not proof of exploitation skill.
The practical rule: prioritize hands-on certs (OSCP, GPEN, OSEP) and firm-level accreditation (CREST) over knowledge-only ones. And remember that a great tester without the exact cert alphabet can still outperform a certified one, so certs narrow the field but the sample report and the interview decide it.
Red Flags When Hiring a Penetration Tester
The most expensive hiring mistake is paying pentest prices for scanner output. These signals reveal it before you sign.
Vague scope acceptance. A serious tester asks detailed questions about your architecture, auth model, and critical flows. A vendor who accepts "test the application" with no clarifying questions is planning to point a tool at it.
No sample report, or a sample full of theoretical findings. If they will not share a redacted sample, walk away. If the sample lists "potential" issues with no proof-of-concept exploits, that is a scan, not a pentest.
"Proprietary methodology" with no detail. A real tester maps to a recognized standard (PTES, OWASP WSTG, NIST SP 800-115, or OSSTMM) and can explain their phases. "We use proprietary techniques" with nothing behind it is a dodge.
Pricing far below market. A quote 40% under everyone else usually means automated scanning only. Real manual testing has a labor floor.
No retest policy, or a per-retest charge. If confirming your fix costs another engagement, the vendor profits from an incomplete fix. Insist on retesting terms up front, the contract guide has the clause language.
A findings count as the headline. "We find 200+ issues" is a scanner boast. The right metric is confirmed, exploitable findings with a working PoC, not raw volume padded with informational noise.
Green Flags: How to Spot a Real Penetration Testing Provider
The inverse list is just as useful. Weight these up.
Detailed technical scoping questions about your specific stack during the sales conversation, before any contract.
A sample report with working PoC exploits, curl commands, and file-level remediation, not a generic template.
A clear methodology mapped to PTES or OWASP WSTG, with the phases and deliverables per phase spelled out.
Unlimited or included retesting as standard, so validating your fix does not trigger a new invoice.
Attack-chain narratives in past work, showing they pivot from initial access to business impact rather than listing isolated bugs.
Code-aware options. For a code-heavy product, a tester or platform that can use source access to build deeper chains and give file-and-line remediation will out-find an external-only engagement.
How to Evaluate a Penetration Testing Company: Read the Sample Report
Before you shortlist anyone, get a redacted sample report and read it like an auditor and an engineer at once. Five checks tell you almost everything.
Is there a working PoC for every critical and high finding? A curl command or script that reproduces the issue. No PoC means no proof of exploitability.
Is remediation specific to a stack? "Use a parameterized query in this Django view" beats "implement input validation." Generic advice signals a template.
Are findings chained, or just listed? Look for at least one attack-path narrative that combines issues into real impact. Chaining is the hardest thing to fake.
Is severity justified with CVSS and a vector? A CVSS score with its vector string is auditable. A bare "High" with no reasoning is not.
Does it map to your compliance framework? SOC 2, ISO 27001, PCI DSS, or HIPAA control mapping in the report saves you assembling it later. The SOC 2 and PCI DSS requirement guides cover exactly what each auditor wants.
If two of these five are missing, keep looking, regardless of how polished the rest of the proposal is.
What a developer-actionable finding actually contains
The difference between a report your engineers can act on and one they cannot is concrete. Every finding should carry all five of these elements.
Element | Why it matters | Example |
|---|---|---|
CVSS score | Risk quantification | CVSS 9.1 (Critical) |
Curl PoC | Exact reproduction |
|
File and line numbers | Pinpoints the vulnerable code |
|
Remediation diff | Shows the exact fix |
|
Business impact | Leadership context | "Attacker can escalate privileges to admin, accessing all customer PII" |
The contrast with vague reporting is stark. A weak report says "the application exhibits insufficient authorization controls," a sentence no developer can act on. A strong one says: "IDOR in /api/users/{id} allows any authenticated user to modify other users' profiles. Exploit: curl -X PUT https://api.example.com/users/456 -H 'Authorization: Bearer victim_token' -d '{"email":"attacker@evil.com"}'. Fix: validate that req.params.id matches req.user.id before updates." One is a finding, the other is a shrug.
Questions to Ask a Penetration Tester Before You Hire
Take every serious candidate through the same set, so the comparison is apples to apples.
On capability: Walk me through a recent engagement where you chained two or more vulnerabilities into a critical exploit. How do you test for Broken Object Level Authorization across an API with 50-plus endpoints? What is your approach to a multi-tenant SaaS, and can you describe a tenant-isolation bug you found?
On process: Which methodology do you follow, and what are the deliverables per phase? How do you handle a finding you cannot fully exploit, do you report it as confirmed or as a candidate? What does your retesting policy cost and how fast is it?
On evidence: Can I see a redacted sample report? Do critical findings include working PoCs? How do you map findings to my compliance framework?
On fit: How do you handle testing windows and production safety? What is your turnaround from scoping to report? Who exactly does the testing, the person I am talking to, or someone else?
The answers separate the testers who prove exploitability from the ones who run a tool and format the output. If you are turning this into a formal solicitation, the RFP template turns these questions into a scored, sendable document.
Understand the Engagement Model Before You Compare Quotes
Two quotes with the same dollar figure can mean very different things, because the pricing structure changes what you are actually buying. Know which model you are being offered.
Fixed-price per engagement. A set fee for a defined scope. Predictable, and the standard for a compliance pentest, but scope creep triggers change orders, so the scope has to be tight up front.
Time and materials. You pay for hours worked. Flexible for exploratory or research-heavy testing, but with no efficiency incentive and an open-ended total, so cap it.
Retainer. Ongoing access to a firm's testers across the year, which suits teams that need frequent, smaller engagements rather than one annual test.
Crowdsourced and bug bounty. Platforms like Bugcrowd, Synack, and HackerOne have many researchers compete or hunt against your scope, with real-time findings. Coverage can be broad, but quality varies by researcher and the model is pay-per-valid-finding or a managed program fee rather than a fixed engagement.
Subscription or outcome-based. The platform model: a per-seat subscription, or payment tied to a confirmed exploit. It trades the fixed per-test fee for continuous coverage, and the cost comparison breaks down how the total lands against manual.
The trap is comparing a fixed-price manual quote against a subscription as if the numbers mean the same thing. They do not: one buys a snapshot, the other buys the whole year.
Lock Down the Legal and Operational Terms
The contract details are where a good engagement is protected and a bad one goes sideways. Confirm all four before you sign, and the contract guide has the exact clause language.
Rules of engagement. Testing windows, approved and off-limits systems, rate limits, escalation paths, and a break-glass procedure if something goes wrong in production.
A statement of work (SOW) that names the exact scope, deliverables, methodology, and timeline, so "test the application" never becomes a mid-engagement dispute.
NDA and IP protection, especially if the tester gets source access, with a data-handling and deletion clause (all test data and findings deleted within 30 days, with written attestation).
Retesting and significant-change terms written into the SOW, not left to a follow-up invoice, since confirming a fix is part of the job, not an upsell.
When a Penetration Testing Platform Beats Hiring a Person
For a fast-shipping, code-heavy product, the individual-versus-firm question is sometimes the wrong one. A code-aware platform is not a person you hire for two weeks, it is continuous testing that runs on every deploy, and it changes three things about the buying decision. This is the model CodeAnt AI is built on, and it is worth seeing how each of the three shifts plays out.
It closes the coverage gap between engagements. A vulnerability introduced this week is caught this week rather than at next year's test. CodeAnt runs on every deploy, so the exposure window that a once-a-year hire leaves open, the 11 months where new code ships untested, effectively disappears.
It gives file-and-line findings. Because the same CodeAnt code intelligence that reviews your pull requests drives the offensive testing, every finding lands with the exact file, line, and a working proof-of-concept, which makes remediation faster than an external-only engagement that never sees your source can offer.
It removes the retest friction entirely. Re-validation runs automatically after each fix rather than as a scheduled, billed engagement, so there is no per-retest invoice and no waiting for a consultant's calendar. CodeAnt also prices this differently from a person's time: you pay only when a high or critical is confirmed exploitable, not for hours or seats sitting idle.
For a regulated team, the pattern that works is CodeAnt for continuous coverage plus a periodic firm engagement for the human sign-off an auditor may still want. The platform is not a replacement for judgment, it is the layer that keeps you covered on the 364 days a hired engagement does not.
Hire for Proof, Not for a Report
The market makes every pentest vendor look similar, so the buyer's job is to filter for the one thing that matters: can they prove a vulnerability is exploitable, and hand your engineers something they can fix? Weight the hands-on certifications, insist on a sample report with working PoCs and chained findings, ask the questions that expose scanner-only testing, and match the model (individual, firm, or platform) to how fast you actually ship.
For code-heavy teams shipping continuously, the calculus increasingly favors a platform for the coverage a point-in-time hire cannot give.
That is where CodeAnt AI fits: the same code intelligence that reviews your pull requests drives the offensive testing, so every finding lands with a working PoC and the exact file and line, retests are unlimited and automatic, and you pay only when a high or critical is confirmed exploitable. It is the continuous coverage layer that sits alongside the periodic human engagement, not a replacement for judgment, but the thing that closes the gap a once-a-year hire leaves open.
Where to start this week
Before you shortlist anyone, get one redacted sample report from each candidate and run the five checks above (working PoC, stack-specific remediation, chained findings, justified CVSS, compliance mapping). Then run a free code-aware scan on your highest-risk application so you have a concrete baseline to compare every proposal against. The sample report plus that baseline will tell you more than any sales call.
Run a free code-aware pentest →
Related reading
How to Write a Penetration Testing RFP: turn your evaluation questions into a scored, sendable document
SaaS Penetration Testing: The Contract Clauses That Decide What Gets Tested: the clause language for after you have chosen
How Much Does an AI Pentest Cost vs a Manual One?: the true total cost behind the quote
Best AI Penetration Testing Platforms: the platform field compared
Black Box vs White Box vs Gray Box Penetration Testing: the knowledge model your tester should be using
