Penetration Testing Services: How to Buy One That Isn't a Scan

Search for penetration testing services and nearly every result is a firm that sells them. That makes the buying advice hard to weigh, because the people writing it are also quoting you. We don't sell penetration tests, so here is what separates a test from a scan, which frameworks require one, and what belongs in the quote before you sign.

TL;DR

• A pentest is manual exploitation. If nobody attempts to exploit a finding and pivot further, you bought a vulnerability scan.
• Fewer frameworks require one than vendors imply. PCI DSS, CMMC Level 3 and NYDFS mandate it. SOC 2, ISO 27001 and HIPAA do not.
• Published price tables contradict each other. Vendors disagree by 10x on whether white-box testing costs more or less.
• Get retest terms in writing. One included retest is common, not universal.

A Pentest and a Vulnerability Scan Are Not the Same Purchase

A scanner enumerates known issues on assets you already know about. A penetration test adds a person who chains those issues into a working route in, then proves it works. Kevin Johnson, founder and CEO of Secure Ideas, drew the line on the Packet Protector podcast: "If they're not attempting to do that, it's not a pen test, period." The "that" is exploitation and pivoting.

The UK's National Cyber Security Centre frames the purchase in a way that saves money. A pentest is a method for gaining assurance that your vulnerability management works, not the primary method for finding vulnerabilities. Ideally you already know what the testers will find before they find it.

If the test is the first time anyone has looked, you're paying senior consultant rates for output a scanner produces. That's a question about your vulnerability management rather than your pentest budget.

Johnson also offers a screening question that costs nothing. Ask which tools they use, then ask how many of those tools have been released publicly. If the answer is none because it's their secret sauce, he suggests ending the conversation there. What that phrase often describes, in his words, is "a version of Nessus that they've changed the logo on the report."

Practitioners screen for this the same way. The thread below is a sysadmin asking what to ask on vendor calls, and the top answer tells him to sign an NDA, demand a de-identified sample report, and expect a proof of concept per finding rather than CVSS output.

Which Frameworks Require a Pentest, and Which Only Imply It

Ask three vendors whether SOC 2 requires a penetration test and you may get three yeses. The Trust Services Criteria say otherwise. The phrase "penetration testing" appears nowhere in the criteria themselves. It appears in a single point of focus under CC4.1, listed alongside vulnerability scans, security assessments and third-party assessments as things management might use. The AICPA then states that use of the criteria "does not require an assessment of whether each point of focus is addressed."

That distinction changes what you buy. A SOC 2 auditor works from your control description, not from a preference of their own. If you wrote that you perform an annual third-party external penetration test, your own sentence is what binds you. Teams discover this the hard way, and the thread below is a good example: the practical answer in it is that auditors look at two things on the letter, the completion date and the remediation status of findings.

None of this argues against testing. It argues against buying one because a salesperson said an auditor demands it. Read your own control language first, then decide what the test is for. If you're mapping several frameworks at once, our cybersecurity frameworks list sets them side by side.

What Cyber Insurance Carriers Ask For

One claim circulates constantly: policies above $1M in coverage require an annual third-party pen test, and $5M and up requires documented internal and external testing. It appears near-verbatim across at least ten sites. Every one of them sells penetration testing or compliance software, and not one cites a carrier or broker document.

The carrier forms say something different. Travelers asks about annual penetration testing on its full CyberRisk application, including whether a third party performs it. Its short form, for applicants at or below $50M in revenue, doesn't ask at all. Beazley's US application for companies under $250M in revenue has no penetration testing question either. Chubb does ask for annual internal and external testing, on its UK proposal form.

Brokers behave the same way. Gallagher's 2026 cyber market outlook doesn't mention penetration testing once, and neither does the Q1 2026 market update from Risk Placement Services, despite a dedicated section on where underwriting is heading. Marsh lists it as a sub-bullet under patch and vulnerability management rather than among its twelve key controls. Howden names it as one mitigation among several, while noting that the controls which got effectively mandated were multi-factor authentication and backups.

What the claims books agree on is where attackers get in. Coalition found that 58% of its 2024 ransomware claims began with a compromised perimeter appliance such as a VPN or firewall. Beazley Security's Q4 2025 threat report attributes 54% of ransomware initial access to VPN-compromised credentials. Travelers' Corvus unit put VPNs at 44% of ransomware and system intrusion claims across 2025, up from 36% the year before. Coalition has also published odds rather than shares: businesses with internet-exposed Cisco ASA devices were nearly five times more likely to file a claim in 2023.

Carriers increasingly check for themselves rather than asking. Coalition scans applicants and policyholders continuously, and says unfixed findings lead to contingencies at renewal. Chubb reports that claims from severe vulnerability exploits fell from nearly 22% in 2022 to 9.5% in 2025, which it credits to its own programme alerting policyholders to exploitable issues.

So the insurance argument for a pentest isn't a requirement. It's a scoping instruction. If you're testing to reduce the thing carriers pay out on, point it at the external perimeter and remote access, which is also what our cyber insurance requirements guide works through.

Why Published Price Tables Disagree With Each Other

Here is a check you can run in five minutes. Pull up two vendor pricing guides and compare what each says white-box testing costs.

DeepStrike's 2026 guide puts white-box work at $7,000 to $40,000 and above, higher than its black-box range, on the logic that more access means more surface to review. Astra's guide, updated in August 2026, puts white box at $500 to $2,000 per asset, which is 10 to 25 times cheaper than its own black-box figure. Both are vendor marketing pages. Both cannot be right.

There is no independent pricing dataset for US penetration testing. No analyst house, no trade body and no government rate card publishes one. Every range in circulation traces back to a vendor's own marketing, including the widely repeated $18,300 average, which appears on multiple sites with no derivation shown on any of them.

Treat those as advertised, not as market rates. The numbers worth more to you are units. DeepStrike quotes skilled tester rates at $100 to $300 an hour, with senior testers at $200 to $300 and above. Astra prices network work at $150 to $1,000 per device, with external testing at $5,000 to $10,000 for up to 25 IPs. A rate and a count you can check against your own asset inventory beat a range you can't audit.

What a Legitimate Quote Contains

PCI DSS is worth reading even when it doesn't apply to you, because Requirement 11.4.1 is the only place a standards body writes down what a penetration testing methodology has to contain. Use it as a checklist against any quote:

• A named, industry-accepted methodology
• Coverage of the full perimeter and critical systems
• Testing from both inside and outside the network
• Validation of segmentation and scope-reduction controls
• Application-layer testing covering injection, access control and business logic flaws
• Network-layer testing across components and operating systems
• A review of threats from the previous 12 months
• A documented approach to risk-ranking findings
• Retention of results and remediation records for at least 12 months

Then check the methodology they name. NIST SP 800-115 is the most cited one and it was published in September 2008 with no revision announced since, so a vendor page titled "NIST SP 800-115 (2026)" is telling you something about their content practices. PTES is still at version 1.0 with a note promising version 2.0 "soon", and its canonical site doesn't serve HTTPS at all. OWASP's Web Security Testing Guide sits at v4.2 with v5.0 in development, and it's the one under active maintenance.

Credentials are worth a question too. OSCP has no expiry while OSCP+ lapses after three years, and GIAC standardised the GPEN passing score at 73% in July 2025. Ask which named individuals will run your engagement and what they hold, rather than what the firm holds collectively.

Scoping Decides the Price

Scope is the variable that moves the number, and it's the one you control. Chris Dale, a principal instructor at SANS, makes the point that gets skipped: "Perhaps even more important than what to include is determining what not to include." Attackers ignore your scope document. The testers you hire cannot.

Two failure modes cost money. Scope too narrowly and the report confirms what you already knew. Scope too broadly against a fixed budget and depth collapses across the whole engagement. Luke Bremer, a senior security consultant at TrustedSec, describes the second one: "Assessments without full coverage can lead to critical-severity findings being missed simply because there is too much to review in the time given."

Johnson's opening scoping question is the one to answer before you call anyone. Why are you doing this? An audit deadline, a customer security questionnaire, a newly shipped feature and a genuine wish to know what an attacker could reach are four different engagements with four different price tags.

Bremer adds a scheduling note worth acting on early. Leave the booking to the last few months of the year and the firms worth hiring may have no availability left.

The Report Is Not the Deliverable

Remediation is where the value leaks out. Cobalt's State of Pentesting research, drawn from its own customer base, found that 48% of pentest findings ever get resolved, with a median time to resolve of 67 days. Its 2026 edition sharpens the split: teams running a programmatic approach reach a 10-day half-life on high-risk findings, while the slowest tenth leave them open for 249 days. That sample is Cobalt's own buyers rather than a market cross-section, so read the direction rather than the decimal.

Verizon's 2026 Data Breach Investigations Report shows the same pattern outside any vendor's customer list. Exploitation of vulnerabilities became the most common initial access vector for breaches at 31%, passing stolen credentials for the first time in 19 years. Only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue were fully remediated during 2025, down from 38%, and the median time to full resolution rose to 43 days from 32.

One wrinkle worth knowing before you scope: Sophos found exploited vulnerabilities falling as a ransomware root cause over the same period, as identity-based attacks took over. Read together, the two support testing identity and external application surface rather than network alone.

So put the retest in the contract. HackerOne's published policy gives a 30-day remediation window on its entry tier and 90 days above it, with unlimited retests inside the window. Triaxiom includes one retest within 90 days in every quote and states outright that this isn't universal across vendors. DeepStrike prices a standalone retest at $2,000 to $5,000. Under PCI DSS the question is settled for you, because Requirement 11.4.4 says corrections have to be verified by repeating the test.

Kelli Tarala, a GRC consultant at Black Hills Information Security, suggests settling the follow-through before the engagement begins: "Even before you get a pen test internally decide an organization, what are you going to do with the results?" The failure she describes is the one to design against: "The goal is not a pretty little report that sits on my desk and I say, hit the check mark."

Where to Start

Answer Johnson's question first. If you're testing for an audit, read your own control language before you read a vendor's brochure, because the sentence you wrote is the one that binds you. If you're testing with insurance in mind, scope the external perimeter and remote access, because that's where four independent carrier claims books say the losses start.

If nobody has run a scanner across the estate yet, do that first and fix what it finds. A penetration test is how you check that your vulnerability management works, and paying consultant day rates to discover missing patches is an expensive way to learn something a scheduled scan reports every week.

Then ask for the sample report, the named testers, the nine methodology elements and the retest window in writing. A firm that answers all four quickly is showing you how the engagement will run.

For what sits around the test, our MSP security stack guide covers the tooling layer.

SOC as a service covers the monitoring side, which is what watches the estate on the 364 days a point-in-time test doesn't.