"What does a pen test cost?"

The honest answer is: it depends on what you're actually buying. Which sounds like a dodge. It isn't. It's the most important thing to understand about buying security assessments, because the buyers who understand it get better tests for less money, and the ones who don't end up comparing numbers that mean nothing.

Here's where most pricing conversations go sideways. "Pen test" gets used as if it's a standard product, like buying a laptop. It isn't. It's a label that covers wildly different engagements.

A vulnerability scan is automated and cheap. A penetration test is human-driven and time-boxed. A red team engagement simulates a full adversary campaign. Purple teaming pairs testers with your defenders to validate detection, not just find holes. TTX and TTP replay exercises test whether your people and processes hold up under pressure, then prove the fixes worked.

These are different amounts of labor, different skill sets, and different outcomes. When your RFP just says "pen test," every vendor prices a different thing, and you end up choosing between a cheap automated scan and a deep human-led engagement as if they're the same purchase. They're not.

So the real question isn't "what does it cost?" It's "what drives the cost?" Six things, in practice.

What actually drives the price

1. Environment complexity. This is the biggest lever. How many applications, APIs, hosts, and cloud accounts are in scope? How much code? How many user roles? A single marketing site and a sprawling SaaS platform with ten microservices, three mobile apps, and a pile of third-party integrations are not the same test. More attack surface means more time, full stop.

2. Test depth. Is it authenticated or unauthenticated? White box, grey box, or black box? Does the tester stop at the first finding, or chain vulnerabilities to show real impact? Depth is labor. A shallow "did anyone leave the door open" pass takes days. A deep "show me the blast radius" engagement takes weeks. Both are legitimate. They just answer different questions and cost accordingly.

3. Operator time. Who's doing the work matters. Senior operators who've seen hundreds of environments find things junior testers miss, and they cost more. Continuous validation (purple teaming, ongoing TTP replay) means more hours spread across the year instead of a one-time burst. If a quote seems suspiciously cheap, ask who's staffing it.

4. On-site versus remote. Travel, shipping gear, and having people physically present costs money. For most application and network testing, remote delivery is completely credible. The attacker you're worried about is remote too. But some things genuinely need boots on site: physical social engineering, OT and ICS environments with air gaps, anything where the hardware itself is the target. If a vendor insists everything must be on-site, ask why. If you insist everything must be remote, be honest about what that rules out.

5. Reporting expectations. This one gets underestimated. A raw findings dump is fast to produce and nearly useless to everyone except your engineers. A report with evidence, severity in business terms, remediation guidance, and an executive narrative your board can actually read takes real time to write. Prospects ask us for report samples before signing for exactly this reason: the report is the product you're buying. Price it like one.

6. Remediation validation. The test finds the problems. Then what? Retesting the fixes (confirming the remediation actually worked) is either included in the engagement or it's a second purchase. Decide up front. A finding without a validated fix is just a liability you now know about.

What a good SOW looks like

If you take nothing else from this post, take this: a credible statement of work answers these questions before anyone signs.

• Scope boundaries. Exactly what's in and out, in writing. IP ranges, applications, APIs, user roles, physical locations.
• Methodology. What kind of test is this, and what rules govern it? What's explicitly excluded (denial of service, social engineering, production data)?
• Deliverables. Report format, evidence standards, debrief or readout, and who gets what.
• Timeline. Start and end dates, testing windows, and when the report lands.
• Roles. Who's the point of contact on each side, and who has authority to expand scope mid-test if something interesting turns up.
• Retest terms. Is validation included? For how long after delivery?

If a vendor's SOW doesn't answer most of these, the price attached to it doesn't mean much either.

How to run an RFP that gets you real answers

Now an important piece: how to actually buy one of these things without getting burned.

Describe the outcome, not the label. "We need a pen test" tells vendors nothing. "We need to answer whether an attacker can reach customer data from the internet, and we need evidence our board will accept" tells them everything. Lead with the risk question and your constraints (budget, timeline, compliance drivers), and let vendors propose the scope that fits.

Ask every vendor the same scoping questions. How many applications and hosts? What authentication is provided? What's in scope for social engineering? Is retesting included? Identical questions force comparable answers. Without them, you're comparing a quote for a scan against a quote for a campaign.

Require evidence, not adjectives. Ask for a redacted sample report. Ask who will actually do the work: not the firm's credentials, the operator's. Ask what the methodology looks like in practice, not just its name. "We do OWASP-aligned testing" is a sentence, not a methodology.

Compare approaches, then prices. The cheapest test that doesn't answer your question is the most expensive purchase you'll make this year. You paid for the illusion of assurance. Price matters, but it's the last filter, not the first.

Watch for red flags. Flat pricing with no scoping call means they haven't thought about your environment. No questions about your stack means they're selling hours, not outcomes. "We'll test everything" means they haven't read your RFP.

Bring us one risk question

You don't need to arrive with a perfect scope. That's our job. Bring one risk question and your constraints (budget, timeline, what the board or your auditor actually needs), and we'll translate it into an assessment scope that's credible, defensible, and priced for what it is.

Further reading

• Pentesting 101 methodology: https://www.lares.com/blog/pentesting-101-penetration-testing-methodology/
• TTX/TTP webinar writeup: https://www.lares.com/blog/ttxttp-webinar/
• Top 5 security threats CISOs face in 2026: https://www.lares.com/blog/top-5-security-threats-cisos-2026/