The practical answer
- Short answer
- A $25K "pen test" got tossed three weeks before a SaaS exit. Here's how PE tech diligence spots an automated scan in 90 seconds — and what a real test costs.
- Best fit
- Industry: Software & Technology. Function: Security & Compliance
- Operating path
- Compliance & Security → Turnaround & Restructuring → Turnaround & Restructuring Services
- Key metric
- 80% The percentage of mid-market penetration tests that are merely glorified, automated vulnerability scans masking as manual exploitation.
The report that died three weeks before the data room opened
A 90-person SaaS company, roughly $40M in software revenue, sitting on a clean PDF labeled "Penetration Test Report — Critical Findings." Forty pages. A logo on every header. The founder had paid $25,000 for it and crossed the security box off his exit checklist eighteen months earlier. Then the buyer's technical diligence lead opened it, scrolled for about ninety seconds, and asked one question: "Where are the manual exploits?" There weren't any. Every "critical" was a CVE for an outdated TLS cipher and three missing HTTP security headers. It was a raw Nessus scan with branding. The check had bought nothing.
That is the most common, most expensive mistake we see founders make in the run-up to a software exit: confusing a document that looks like a penetration test for one. The reason it's so common is that the gap between the two is invisible to anyone without a security background — and completely obvious to the engineer the private equity buyer brings to the table. An automated scanner can tell you a server is missing a patch. It cannot tell you that an authenticated user on Tenant A can change a single integer in a billing endpoint and pull Tenant B's invoices. That second finding is the entire point of a real test, and a script will never produce it.
The line is not subtle once you know where it sits. As the Cybersecurity and Infrastructure Security Agency (CISA) frames it, scanning enumerates known weaknesses; penetration testing requires a human to chain those weaknesses together, bypass controls, and demonstrate actual business impact. Here's the field test you can run on any past report today, no security expertise required: search it for the phrase "we were able to." A real engagement narrates an attack path — "we were able to escalate from a standard user to admin by replaying a JWT with a modified role claim." A scan describes a state — "TLS 1.0 is enabled." If your report has zero attack narratives and a turnaround time of 48 hours, you bought the scan.
If your vendor turned the report around in 48 hours, you didn't buy a penetration test. You bought a scan wearing an expensive suit — and the buyer's engineers will undress it in the first read.
Why the floor is $15K and the ceiling is $60K — for SaaS specifically
For a multi-tenant web application, a legitimate grey-box manual test starts at a hard floor around $15,000 and climbs to the $40,000–$60,000 range as the attack surface widens. The number is not arbitrary, and it scales with three things specific to SaaS architecture, not with how many pages the report runs.
First, roles times tenants. A flat marketing app has one user type. A SaaS platform has admin, manager, member, and read-only — and each of those exists inside an isolated tenant boundary. The expensive, irreplaceable work is a human sitting with a low-privilege account in one tenant, methodically trying to read, write, or escalate into data they should never touch. There is no scanner for "can a member-level user in Acme Corp see Globex Corp's records." Every role-and-tenant combination is hand-tested, and that combinatorial math is most of your invoice. Second, the API layer. Modern SaaS exposes REST or GraphQL endpoints that often enforce authorization more loosely than the UI does — the front end hides a button, the API still answers the request. Testing those object-level and function-level authorization gaps is slow, manual, and exactly where the deal-breaking findings live. Third, business logic. A skilled tester doesn't just flag a cross-site scripting field; they write the payload that steals a live session token and proves what an attacker walks away with.
Frame the spend against the downside, not against your IT budget. The IBM Cost of a Data Breach Report puts the average breach at $4.88 million. A $35,000 manual engagement against that exposure is not a line item to negotiate down — it is the cheapest risk transfer your board will approve all year. And be honest about what a cheaper option actually buys. Plenty of founders grab a low-tier scan purely to satisfy an auditor and keep their SOC 2 certification timeline moving. That's a defensible reason to scan. It is not the same product as a test, and a sophisticated acquirer paying a software multiple for your IP will not accept the substitution.
What the buyer's engineer does to your report — and how to be ready
When a PE-backed acquirer evaluates your security posture, the partner reads the executive summary and the engineer reads the methodology. The engineer's first move is to compute a ratio: automated findings versus demonstrated manual exploits. A report that is 100% generic CVEs — legacy SSL, missing headers, an out-of-date library — tells them your platform has never actually been attacked by someone competent. That reads as a red flag about your whole engineering culture, not just your testing vendor, and it shifts the risk assumptions on the entire deal.
This matters because the breaches that destroy SaaS companies don't live in unpatched server software. The Verizon Data Breach Investigations Report (DBIR) consistently shows web applications as a leading attack vector, with attackers going straight for authentication bypasses and privilege escalation — precisely the tenant-isolation and API-authorization paths a scanner cannot see and a human is hired to find. If your testing history contains no documented attempt at a cross-tenant data breach, no API manipulation, no lateral movement, the buyer assumes those doors are open and prices the risk into a holdback.
So change how you procure, starting with the next SOW. Three clauses, non-negotiable. One: require a methodology section that names the manual techniques in scope — tenant isolation testing, object-level authorization, business logic abuse — and explicitly bars delivering raw automated scan output as the deliverable. Two: demand a retest clause inside the quoted fee, so your engineers can patch the criticals and earn a clean re-verification before the data room opens; a real firm includes this in the $15k–$60k and doesn't bill it as a second engagement. Three: ask for one anonymized sample finding from a past test before you sign — if they can show you a written exploit chain, they do manual work; if they show you a severity chart, keep shopping. Owning this process is the load-bearing part of your security posture assessment, and it's the difference between walking into diligence with proof and walking in with a PDF that dies in ninety seconds.
