Most organisations don't buy a penetration test because they want one. They buy it because a NESA assessment, an ADHICS requirement, a PCI DSS obligation, or an enterprise customer's security questionnaire told them to. That's fine — regulation is a perfectly good reason to test — but it creates a trap. When the test is a box to tick, the cheapest quote wins, and the cheapest quote in this market is very often an automated scan wearing a penetration test's clothes. You pay for assurance and receive paperwork.
Having sold, delivered, and reviewed a great many of these engagements over the years, here's how to buy one that actually tells you something.
VAPT, pentest, scan — the words matter less than the work
The terminology in this market is used loosely, sometimes deliberately, so let's be precise about the underlying activities.
A vulnerability assessment is largely automated. It enumerates known weaknesses across a broad surface — fast, wide, shallow. It's genuinely useful for coverage, and it's cheap because a machine does most of it.
A penetration test is a different animal. A skilled human takes those weaknesses and tries to exploit them, chains them together into an actual attack path, and demonstrates real business impact — "here's how someone gets from your login page to your customer database," not "here's a list of CVEs."
VAPT, the term you'll see everywhere here, just means combining the two: breadth from the assessment, depth from the manual testing. The label is fine. What matters is whether the depth is actually there, because that's the expensive, valuable part — and it's exactly the part a low bid quietly omits.
The tell is simple. If the "penetration test" could have been produced by a tool running overnight, it was.
What a real scope covers
Depending on what you're protecting, a thorough programme spans several fronts, and a good provider will scope to your risk rather than sell you a fixed package.
External and internal network testing — the internet-facing surface and what an attacker could do once inside. Web application and API testing, and pay attention to the API part specifically, because it's where the serious authorisation flaws increasingly hide and where cheap tests skimp. Mobile application testing if you ship apps. Active Directory and cloud-identity attack simulation, because in modern estates the path to your data usually runs through identity, not exploits. And, where you've authorised it, social engineering and phishing, because your people are part of the attack surface whether you test them or not.
Not every engagement needs all of it. But the scoping conversation should be about your environment and your risk, and if a provider quotes you a flat price without asking hard questions about your estate first, that's a signal about the depth to expect.
How cost and scope really relate
Buyers want a price list. Serious testing doesn't have one, because cost tracks effort, and effort tracks scope and depth. The honest drivers are the number of live hosts, applications, and APIs in scope; whether you want a standard assessment or full red-team-style testing; whether retesting is included to confirm fixes; and any compliance-specific reporting you need for NESA, ADHICS, PCI, and the like.
Here's the counterintuitive part worth internalising: a suspiciously cheap quote is usually the expensive option. It almost always means minimal manual effort — a scan and a report — which means the exploitable business-logic flaw, the chained attack path, the thing that actually gets you breached, goes unfound. You'll pass your audit and remain vulnerable, and discover the difference the hard way. Paying a fair rate for genuine manual testing is cheaper than a breach by several orders of magnitude.
The questions that separate real from theatre
When you're evaluating providers, a handful of questions do most of the work.
Ask who, specifically, will test — and what they're certified in. You want named, credentialed people (CREST, OSCP), not "our team." Ask for a redacted sample report and read it: does it show exploited attack paths and failed controls, or just a severity-sorted list? Ask whether manual testing is included or whether it's essentially a scan with commentary. Ask whether retesting is part of the engagement, because a finding isn't closed until someone's confirmed the fix actually worked — and we've watched too many "remediated" issues quietly reappear to take that on faith. And ask how they'll report it for your specific compliance need, so the output actually satisfies the regulation that sent you here.
Compliance is the by-product, not the point
The mindset shift that turns a wasted test into a valuable one is this: don't buy a test to pass an audit. Buy a test to find out how you'd really be attacked, fix what matters, and confirm it's fixed. Do that well and compliance falls out the other end for free, because you'll have done more than the framework asked. Buy the cheapest thing that satisfies the auditor and you get a certificate and a false sense of safety — the worst combination in security, because it stops you looking.
What you should actually receive at the end
A test's value shows up in the deliverables, so know what good looks like before you sign. You should get an executive summary a non-technical board member can follow — the material risks in plain language, not a wall of CVSS scores. You should get a technical report that walks through the exploitable attack paths step by step, with enough detail that your engineers can reproduce and understand each one, not just a bullet that says "SQL injection, high." You should get clear, prioritised remediation guidance that tells you what to fix first and why. And you should get retest evidence confirming that the fixes you made actually closed the holes. If a proposal doesn't include retesting, that's a red flag — a finding isn't resolved until someone's proven the remediation worked, and we've lost count of the "fixed" issues that turned out to be still wide open on retest.
The scoping mistakes that waste money
Two mistakes come up again and again. The first is scoping to the budget instead of the risk — deciding you'll spend a fixed amount and cramming the test into it, which usually means the important systems get a shallow look. Better to scope to what actually matters and stage it over time if the budget won't stretch. The second is treating the test as a one-off event divorced from everything around it: no context shared with the testers, no plan for what happens to the findings, no follow-through. A test handed over cold and filed away changes nothing. The engagements that reduce real risk are the ones where the findings feed a remediation plan and the loop gets closed.
If you're scoping a penetration test — for compliance, for a customer, or because you actually want to know where you stand — we're happy to help you scope it honestly, including telling you when you need less than you were about to buy.