Is a Cheap Pentest Worth It?

Usually not. As of August 2026, the floor for a credible penetration test sits around $4,000, and below that line you are almost certainly buying an automated vulnerability scan with a human logo on the cover. That is not just our view; DeepStrike says under $4,000 is "usually just automated scans, not true pentests," and pentestingcost.com draws the same line at $3,000. There are real situations where a cheap scan is the right purchase, and we cover them below. But if the test is for SOC 2 evidence, a customer's security review, or a genuine "can we be breached" question, the cheap option tends to fail at exactly the moment you need it to hold up.

Key takeaways

• Below roughly $4,000 you are almost certainly buying an automated vulnerability scan with a human logo on the cover.
• The floor is arithmetic, not greed. At the cheapest published rate of $150 an hour, a $4,000 engagement buys roughly 27 hours across scoping, testing, reporting and retest, before tooling, insurance, report review, or margin.
• A cheap test skips four specific things: manual business logic testing, chained exploitation, evidence quality, and the retest.
• Auditors usually accept a scan-grade report as vulnerability scanning evidence, not as penetration testing, and enterprise procurement teams often require a real test as a condition of signing. You defer the spend, you do not save it.
• A cheap scan is the right buy in three cases: pre-pentest hygiene, cadence between annual tests, and early stage with no external pressure. Just never represent it to a customer as a penetration test.

Where the money actually goes

Penetration testing is skilled labor. The price mostly tracks hours of human attention on your specific environment, so you can sanity-check any quote with arithmetic.

pentestingcost.com publishes $150 to $250 an hour for independent contractors and $200 to $350 for a mid-market consultancy, and DeepStrike publishes $100 to $300 across the market. Run the arithmetic against the cheapest of those rates. A $4,000 engagement, DeepStrike's floor, buys roughly 27 hours at $150: scoping, reconnaissance, manual testing of authentication and authorization, exploitation, writing findings a developer can act on, and a retest window at the end. That is already tight, and it is before the firm pays for tooling, insurance, a second set of eyes on the report, or its own margin.

So when a vendor quotes $1,000 or $1,500 for a "penetration test," one of two things is true. Either they have found a way to hire senior offensive security talent at a rate nobody else in the industry can match, or the human involvement is an hour or two of supervising a scanner and pasting its output into a report template. We have never seen the first case. The economics don't leave room for it.

To be fair to the low end of the market: many of these vendors are not exactly lying. The fine print often says "automated testing with manual validation," which is accurate. The problem is what the buyer believes they bought. The invoice says penetration test, the report cover says penetration test, and the buyer proceeds as if a human spent a week trying to break their product. Nobody did.

What a cheap test skips

The gap between a scan and a test is not vague thoroughness. It is four specific things, and each maps to a way the deliverable fails you later.

Manual business logic testing. A scanner checks your application against a database of known vulnerability patterns. It cannot understand what your application is supposed to do, so it cannot notice when the application permits something it shouldn't. Can a free-tier user call the paid-tier export API directly? Can an approval step be bypassed by replaying the request with a different object ID? In most SaaS products we test, the highest-impact findings are exactly this kind of flaw, and they are invisible to automation at any price point. We wrote about this gap at length in Penetration Testing: Beyond Checkbox Compliance.

Chained exploitation. Scanners score findings in isolation, which is how a report ends up with forty mediums and no story. A human tester chains a verbose error message, a permissive CORS policy, and a session handling quirk into account takeover, then documents the chain. That changes your remediation priorities completely. Three "acceptable risk" findings that combine into full compromise are not acceptable risk.

Evidence quality. A scan report is a CVE list sorted by CVSS score with boilerplate remediation ("upgrade to version X"). A pentest report contains reproduction steps, request and response captures, screenshots of actual impact, and remediation guidance written against your stack. Your engineers can act on one of these without a follow-up meeting. Your auditor can rely on one of these without follow-up questions. Same word on the cover, very different document.

Retest. Credible engagements include a retest: you fix the findings, the tester verifies the fixes, and the final report says so. That closed-loop report is what you hand to auditors and customers. Cheap engagements skip retesting entirely, which means the only artifact you own permanently says "vulnerable," and proving otherwise costs extra or never happens.

How auditors and enterprise customers read a scan-grade report

Two audiences will actually study this document, and both have seen hundreds of them.

Your SOC 2 auditor first. Strictly speaking, SOC 2 does not mandate a penetration test; it expects evidence of monitoring and proactive security evaluation under CC7.1. An experienced auditor recognizes a re-skinned scanner export in about thirty seconds (the section ordering, the generic remediation text, the absence of any tester narrative all give it away). Most will still accept it, but as vulnerability scanning evidence, not as penetration testing. If your system description or your customer-facing security page claims annual penetration testing, that mismatch becomes an uncomfortable conversation, and in a bad case an exception in the report.

Enterprise customers are harsher, because they have money on the line rather than an opinion. As of August 2026, security questionnaires routinely ask whether testing was manual, what methodology was followed (PTES, OWASP WSTG), who performed it, and increasingly they ask for the full report rather than a summary letter. A procurement security team that reads a scan-grade report will usually respond by requiring a real test as a condition of signing. Now you are buying the proper pentest anyway, mid-deal, on the customer's timeline instead of your own, with your largest contract stalled behind it.

Add it up and the cheap test's real cost model appears: you don't save $5,000. You defer the spend, lose the weeks the first vendor took, and attach the delay to your most important deal.

When a cheap scan is exactly the right buy

Honesty cuts both ways here, because sometimes the $1,000 product is the correct purchase, as long as you call it what it is.

• Pre-pentest hygiene. Run a scan a few weeks before your real test and fix everything it finds. Paying manual-testing rates to have a human rediscover missing patches and expired TLS certificates is a waste of the tester's hours and your budget.
• Cadence between annual tests. Monthly or continuous scanning between annual manual tests is genuinely good practice, and it maps cleanly to the vulnerability management expectations in SOC 2 and ISO 27001. This is the legitimate home of the low-cost automated product.
• Early stage, no external pressure. If you are pre-revenue with no compliance deadline and no enterprise prospects asking questions, a scan plus disciplined fixing beats doing nothing while you wait to afford the real thing. Just never represent it to a customer as a penetration test.

If a vendor sells you a scan at scan prices and labels it accurately, that is a fair transaction and we have no quarrel with it. And since we sell penetration testing ourselves, you should discount our view accordingly; the reason to believe the argument is the arithmetic, not our incentives.

The floor is structural, not greed

The roughly $4,000 floor exists because manual hours are the product. Automation gets cheaper every year; skilled human attention does not, and the findings that end up mattering (logic flaws, chained exploitation, anything requiring understanding of your business) only come from the human hours. Any vendor advertising dramatically below the floor is reselling automation, whatever the branding says. The market keeps producing these offers because the words "penetration test" on a cover page are free.

The defense is four questions before you sign:

1. How many manual testing hours are scoped?

2. Who is performing the test, and what are their certifications?

3. Can I see a sanitized sample report?

4. Is a retest included?

A firm selling real testing answers all four without hesitation, because those answers are the product. A firm selling a scan will get vague on the first one.

Frequently asked questions

What should a minimum credible pentest cost?

As of August 2026, treat roughly $4,000 as the absolute floor for a narrowly scoped engagement, such as an external network test or a small single application, a figure consistent with DeepStrike and pentestingcost.com. Most credible web application tests land between $5,000 and $30,000 depending on application size, roles, and API surface, with startup-sized applications usually at the lower end of that band. Below the floor, the manual hours simply cannot exist at defensible labor rates, so you are buying automation regardless of what the proposal says.

How do I tell a scan report from a pentest report?

Open it and look for reproduction steps, request and response evidence, and any finding a scanner could not have produced, such as an authorization bypass or a chained exploit with a narrative of how the tester moved from one weakness to the next. Scan reports betray themselves with CVSS-sorted CVE lists, identical boilerplate remediation on every finding, and no named methodology or tester. If every finding could have been generated without credentials or business context, it was.

Does SOC 2 require a penetration test at all?

No, not by name; SOC 2 expects evidence of proactive security evaluation under the Common Criteria, and many companies satisfy early audits with vulnerability scanning alone. In practice, most growth-stage companies add an annual manual test because their enterprise customers demand one during security review, which makes the audit question moot. If you claim penetration testing anywhere in your system description or marketing, the evidence needs to match the claim.

Can I just run the scan myself instead of paying $1,000?

Mostly, yes. Tools like Nessus, OpenVAS, and hosted scanners produce essentially the deliverable the bottom of the market resells, and running them in-house on a monthly cadence is cheaper and more useful than an annual third-party scan. Pay outside firms for the things you cannot do internally: manual testing, independent evidence, and a report that carries weight with auditors and customers.