The penetration test has become the security industry's most expensive placebo. It is sold as the gold standard of 'taking security seriously,' a mandatory ritual for board decks and enterprise security questionnaires. But there is a massive disconnect between the marketing story of agencies who sell them, and the actual security value for businesses.
The business question behind a pentest is legitimate: 'Where are we attackable?' But the industry's standard answer - a time-boxed engagement delivering a static PDF - is blatantly flawed in my opinion. Let's discuss why.
What's wrong with traditional pentests?
- The theatre: the story sold vs. the reality behind it
Agencies love to sell pentests as a highly professional, almost industrialised process. You get slides about methodology, coloured boxes for "black-box", "white-box", "grey-box", and a glossy report at the end. The message is: this is the mature, responsible thing to do; any serious company does this once a year or even once a quarter.
In reality, many of these engagements boil down to a small team that has a fixed number of days to "play around" with your systems and find something interesting enough to justify the invoice. Sometimes those people are very strong technically, sometimes they're not – and as a customer, you can barely tell the difference. That's not inherently bad; that's how hacking often works. The problem is the packaging: it's sold as a precise measurement of your security posture, when in fact it's just a time-boxed experiment whose depth and quality you as customer cannot meaningfully verify.
- Business empathy: technically interesting ≠ business-relevant
Most pentest shops are nerd outfits – and that's fine. You actually want people who enjoy living in Burp, nmap and exploit chains. The problem is that this naturally comes with a fairly limited understanding of how most businesses really operate and prioritise. Every agency claims they "understand your business", they run their discovery workshops, ask you "what's important", walk through the app with you – but at the end of the day they remain a satellite. They are rarely true operators inside a company and they watch the game mostly from the sidelines.
That shows up in three places. First, in how they think about application logic: they are drawn to technically interesting paths, not necessarily the ones tied to revenue, abuse cases or regulatory risk. Second, in how they spend their time within a scope: more often than not they will happily puzzle over some deep technical edge case instead of focusing on the flows the business really lives or dies on. Third, in how they rate what they find. Instead of making a hard call on real-world impact, they hide behind scoring frameworks like CVSS and apply a formula. The output often doesn't match how the company actually sees risk, so internal teams anyway end up re-prioritising everything again afterwards.
- Limited coverage: you're buying the skills of a few people, at best…
A classic pentest gives you the perspective of maybe two or three people for a couple of weeks. They do their best within the scope and time you paid for. But your stack is built from dozens of technologies, frameworks and services. Expecting a tiny team to have deep expertise in all of them is unrealistic. On top of that, the economics are brutal. For budget reasons, most pentests only ever touch a small fraction of your actual attack surface – five to ten percent is a realistic order of magnitude in many setups. Anything more would very quickly become uneconomical.
That means you're not buying "all relevant attack paths", you're buying "whatever this specific team happens to be good at and has time for". Important classes of issues will simply be missed – not because the testers are bad, but because the model itself is limited.
- No real benchmark: you can't tell good from mediocre testing quality
One of the most fundamental problems: as a buyer, you have almost no way to benchmark pentest quality. You get a PDF, maybe a short debrief call, and you're supposed to trust that the testers went deep, followed leads, tried creative things and didn't just run a few tools on autopilot.
If two different firms test the same system, the overlap in findings can be surprisingly small. That alone should make everyone nervous. You're making budget decisions on something you can't meaningfully compare, measure or audit – and the industry likes it that way.
- Broken follow-through: PDFs don't fix themselves
Even when the technical work is decent, the real-world impact of a pentest in many organisations is surprisingly low. Reports land as static PDFs (typically), someone in security manually slices them into tickets, and then reality hits: product deadlines, limited engineering bandwidth, unclear ownership. The hard, architectural issues with messy trade-offs are quietly parked, teams focus on a few obvious "P0s", and the rest just ages. It's not unusual to see a "new" pentest twelve months later rediscover a big part of the previous report for exactly that reason.
Strictly speaking, this follow-through problem is not unique to pentests; the same can happen with findings no matter what origin. But the classic pentest setup makes it worse: one-off, point-in-time, fully external, delivered in a format that doesn't plug into your normal way of working, with recommendations written by people who don't have to live with your architecture and constraints. If you already struggle to turn security input into real change, a big pentest report is simply a very expensive way of generating more backlog you won't execute.
- Misplaced priorities: fundamentals are ignored while pentests are celebrated
Zoom out from the one app or API that just got tested and look at your company as a whole. In most businesses, the biggest gaps are somewhere else: identity and access management, secrets management and rotation, asset visibility, incident readiness, vendor risk, etc. These are cross-cutting topics that shape your overall risk surface. And by design, most pentests won't ever touch on them. They are scoped to a specific service or application – often something new that was just built. The only realistic way to address those fundamentals is through a structured security program led by an experienced CISO.
Despite all that, pentests are treated as proof of seriousness. They show up in board decks and sales calls and are talked about as if they were a silver bullet. All the other topics – which would often be more important to invest in – don't get the same recognition, simply because auditors and customers don't ask for them as much. Pentests are overvalued not because they are so strong, but because the market around them is under-educated.
Alternatives to pentests
Before diving into alternative approaches, let's remind ourselves of the underlying objective. At the core, the goal of a pentest is actually very simple: you want to find concrete weaknesses in your products, services or infrastructure – places where you can realistically be hacked – so you can patch them. And you want to do that in a way that is at least somewhat cost-efficient. You put money in and you expect a list of vulnerabilities out, ideally in a form that engineering can work through and that reduces real-world risk.
If you look at it through that lens – "find exploitable issues, turn them into fixes, do it efficiently" – then pentests are really just one possible tool. They're not the only way to get there, and for many modern tech companies they're by far not even the best way. The options below follow the same goal, but with different mechanics a much better return on what you invest.
- Inside-out assessments: stop playing "black-box", just cut to the chase
A far more efficient way to understand your risk is to put experienced security people and the people who built your systems into the same room and look at everything from the inside out. You talk through architecture, logical components, deployment models, authentication & authorization, secrets handling, monitoring, data flows and storage, encryption and key management, etc.
There is no artificial separation into "black-box" and "white-box". You simply ask: "What is the most efficient conversation we can have that surfaces the real weaknesses in how we build and operate?" The people who created the system always know more about its edge cases than someone who arrives with a laptop for a week. Inside-out assessments embrace this fact and use it to create a much clearer, more systemic picture of your security posture.
- LLM-assisted analysis: use the tools you already have
We're at a point in late 2025 where you can extract a lot of value from tools like ChatGPT with very little setup. If you run an inside-out assessment as suggested above, record and transcribe the session, and combine that with access to your codebase, an LLM can basically do a security assessment in no time.
By cross-referencing the transcripts with your repo, you can ask the LLM to spot the gap between what people think the system does and what the code actually says. You can then have it analyze that delta to find concrete vulnerabilities in implementation, architecture, and configuration, before outputting structured findings or ready-to-use tickets. This workflow doesn't make creative human hacking obsolete, but it automates the analysis so effectively that the ROI of a standard pentest collapses in comparison.
- Bug bounty / vulnerability reward programs: pay for outcomes, not hours
If you prefer to stick to the "outside-in" perspective - simulating a real external attacker without internal knowledge - you don't have to settle for the inefficiencies of a traditional pentest. With a bug bounty program, you turn the model around in several ways at once. You don't pay for time, you pay for outcome with real business value. You define what matters (impact, severity, scope) and attach rewards to it. If nobody finds anything meaningful, you don't spend anything. No findings, no money – which is the exact opposite of the classic "we burned 20 man-days, here's your PDF" model.
Most importantly, instead of a small, fixed team with finite skill set, you tap into a much larger, diverse crowd. A typical public bug bounty program can easily have 50, 100 or even hundreds of people continuously (not just once or twice a year) looking at your attack surface: specialists in web, cloud, mobile, infrastructure, SaaS misconfigurations and more. Some hunters will only ever pick off low-hanging fruit and get paid accordingly. Others will invest serious time to find deep, complex issues because the payoff is worth it. From a business perspective, that's a much cleaner deal: your budget flows to proven impact, not just to activity. The ROI beats almost any traditional consultancy.
- Internal rewards: make it attractive to report issues from the inside
Your own engineers and operators often have the best intuition for where the bodies are buried. They see awkward legacy decisions, strange edge cases and security shortcuts. What they usually don't have is incentive and air-time. They're busy shipping features, and they've experienced that raising concerns from inside rarely gets the same attention as when an expensive external consultant says the exact same thing.
You can flip that by introducing a simple internal reward scheme: pay meaningful but sane amounts for well-documented vulnerabilities that are turned into tickets and fixed. Make it clear that surfacing risk is seen as a contribution, not as complaining. From a business angle, this is one of the cheapest ways to convert existing, latent knowledge into concrete hardening work.
- Modern security tooling: AI-assisted PTaaS, CNAPP, EASM etc.
Beyond the approaches above, there is a whole ecosystem of commercial tooling focused on exactly the same core problem: finding weaknesses before attackers do. Runtime vulnerability scanners, CNAPP platforms, EASM tools and the first wave of AI-assisted or "agentic" pentesting services (PTaaS) all try to give you an outside-in view on your environment – often combined with a surprisingly deep inside-out understanding of your cloud configs, identities, workloads and code.
This article is not the place to catalogue every category and vendor. The point is simply this: there is a large option space of technologies you can and should invest in over time. Many of them already do a better job at continuous, data-driven discovery than a one-off pentest ever could. The question is not "pentest or nothing?", it's how you combine structured security programs, incentives and modern tooling into something that fits your stage, stack and risk profile.
When a pentest is actually worth it
After all of this criticism, there are situations where a pentest makes sense – but they're rarer than the industry suggests. The bar has to be higher than "a customer asked for it" or "it's on some checklist".
- First, your fundamentals need to be reasonably under control. It only makes sense once you have a structured security program in place and you consciously see pentesting as one instrument among many, not as the security measure. In other words: you've thought about alternatives first and you understand that a pentest is just one slice of the pizza.
- Second, there should be a clear external or internal driver and a conversation about alternatives. In B2B contexts, customers and auditors will often ask for a "recent pentest" simply because they don't know any other way to ask for security validation. If you can explain what else you are doing – say modern tooling, VRP, tabletop exercises etc. – many of them are perfectly happy with that. A pentest becomes interesting when they still insist. In that case, accept it for what it is: a compliance expense, not a security investment. If a classic report makes the audit easier, buy it. Just don't confuse "passing the audit" with "being secure". And try to not waste too much money on it - because it is exactly that, a waste.
- Third, and most importantly for me, the scope and the team need to be extremely focused. The useful pentest is not "please hack everything you can find in three weeks", it's "we have this well-defined, business-critical system, and we want this specific, high-calibre team – whose skills we actually know – to try to break it from the outside". You use them as a sniper, not a shotgun: to squeeze out the last 10–20% of assurance on top of everything else you are already doing.
Even in that best-case scenario, a pentest is complementary. It only really works when it sits on top of the other measures we've talked about and when there is clear ownership and engineering capacity to act on the findings. As a standalone security strategy, it's still a very expensive way to feel slightly better for a short moment.
Wrapping up
If there's one takeaway, it's this: a pentest is a niche instrument for specific moments, not a default answer to "are we secure?". Use it when the scope is narrow, your foundations are solid, and you've already invested in smarter ways of finding and fixing weaknesses.
