The Penetration Testing Buyer's Guide: Scope Right, Spend Smart

You’ve decided you need a penetration test. Good call. But before you sign a proposal, there’s a lot that can go wrong: wrong scope, wrong methodology, wrong expectations. The result is a report that collects dust and a budget that got wasted.

This guide is written for the people buying pentests, not the people running them. It covers what a pentest actually is, when to do one, what to expect, and how to avoid the most common and expensive mistakes.

What a Pentest Actually Is (and What It Isn’t)

A penetration test is the manual process of finding vulnerabilities and misconfigurations in IT systems, carried out by an independent human tester. The output is a report that documents every finding, explains why it’s a problem, and tells you how to fix it.

Two things are non-negotiable:

• It must be done by a human. If nobody is actively thinking about how to chain vulnerabilities together, you’re not getting a pentest. You’re getting a vulnerability scan with a fancier invoice.
• The tester must be independent. Someone who helped build the system cannot objectively test it. They already know where they looked and what they skipped.

There’s a newer trend of vendors selling “AI penetration tests.” An automated tool running pre-defined checks is a vulnerability scanner. A skilled tester using AI tools to assist their work is a pentest. The difference matters enormously.

A technical audit is a separate but related concept. Where a pentest simulates an attacker, an audit reviews configuration against a baseline: how many admin accounts exist, is patch management documented, are logs being collected? For standard products and platforms, an audit often delivers more value per euro than a pentest.

There Is Never a Perfect Time. Stop Waiting.

The most common reason organizations delay their first pentest: “We’re in the middle of implementing X. Once that’s done, it’ll make more sense.”

After X, there will be Y and Z. IT systems are not static objects that reach a finished state. They grow, change, and accumulate complexity, and complexity is where vulnerabilities live.

Attackers don’t wait for your implementation roadmap to complete. Every month you delay is a month during which the weaknesses in your current system are exploitable.

The right answer is regular testing, not a single test timed to a milestone. The goal isn’t to certify a snapshot of your infrastructure. It’s to continuously reduce the attack surface as the system evolves.

Blackbox, Greybox, Whitebox: Which One Are You Actually Buying?

Blackbox testing gives the tester no credentials and no knowledge of the internal systems. The tester works like an unauthenticated external attacker. This is the natural starting point for an external IT infrastructure penetration test.

The problem: an external attacker with no credentials rarely finds anything that a vulnerability scanner wouldn’t also find. If your external systems are reasonably patched and configured, a blackbox test often comes back with low-to-medium findings, not because your systems are secure, but because the most dangerous vulnerabilities only reveal themselves once an attacker is already inside.

Greybox testing (where the tester receives valid user credentials or partial knowledge) is almost always a better use of budget. It simulates the realistic scenario: a phishing attack succeeded, or a disgruntled employee has access. This is where the interesting findings live, and it’s the default approach for an internal IT infrastructure penetration test.

Whitebox testing gives the tester full access to documentation, source code, and configuration. It’s the most thorough option and the right choice for critical systems or software development pipelines.

My honest opinion: external blackbox tests, done repeatedly year after year without changing the methodology, are often the most expensive way to learn the least. Before you renew that contract, ask yourself what you actually learned last time.

Scope and Pricing: Why This Isn’t a Sales Job

Pentests are not cheap. That’s fine: when the quality and scope are right, they’re worth every cent.

The issue is that scope and pricing decisions are often made by salespeople who don’t do the testing. A salesperson can quote you hours and a day rate. They cannot tell you whether your environment needs 20 hours or 80 hours, whether an external test or an internal assessment will find more value, or which systems carry the most risk.

That decision requires someone who has done this before, ideally hundreds of times. An experienced pentester asking the right questions before writing a proposal is a sign of a serious provider. A fast turnaround on a standardized quote without a scoping conversation is a red flag.

The right scoping conversation starts with your motivation:

• Are you doing this because compliance requires it?
• Did you recently migrate something critical to the cloud?
• Are you worried about insider threats?
• Is this your first test, or a follow-up to remediation?

The answer to these questions should directly shape what gets tested, how, and for how long.

Managing Expectations: What a “Clean” Report Actually Means

There is a common fear among people commissioning pentests: what if the tester finds nothing?

In my experience, there has never been a pentest that found zero vulnerabilities. But there’s also a difference between a test that uncovers a critical chain of vulnerabilities leading to full domain compromise and one that returns five medium-severity findings.

Both are valuable. Here’s why:

External perimeter tests often don’t find critical vulnerabilities. And that’s actually the goal. Your external attack surface should be hardened. Finding that it is gives you confidence and data. If you’re expecting a tester to compromise your servers from five IP addresses with no credentials, you’ve either watched too many hacking films or your infrastructure has serious problems.

Internal assessments are a different story. In my experience, critical vulnerabilities are common once you’re inside the network. Misconfigurations in Active Directory, excessive privilege delegation, outdated internal services: these show up regularly.

Even low and medium findings deserve attention. Most real-world attacks don’t use a single critical vulnerability. They chain several smaller weaknesses together. A medium finding that seems harmless in isolation might be the link that makes a chain possible. Fixing it removes a stepping stone.

The goal of a pentest is not to embarrass your team. It’s to find what they couldn’t find themselves, not because they’re incompetent, but because anyone building a system doesn’t have the headspace to test every assumption they’ve made along the way.

Starting Your First Pentest: Smaller Is Smarter

If this is your first pentest, do not let a provider sell you a massive engagement.

Here’s what typically happens on a first assessment: it doesn’t take long to find critical vulnerabilities. The internal IT team then spends months remediating them. A huge, weeks-long test during that phase produces a report that’s impossible to act on: you’re overwhelmed before you’ve fixed the basics.

A better approach:

1. Start focused. Test the most exposed or highest-value systems first. A scoped initial assessment gives you a clear picture of where you stand without overwhelming your team.
2. Fix what you find. Give your team time to remediate before testing again.
3. Go deeper next time. Once the obvious weaknesses are gone, longer tests are worth more because the tester has to work harder to find anything.

Security is a process, not a project. A good pentest provider sizes their engagements to match where you actually are in that process, not to maximize their invoice.

Questions to Ask Before You Sign

Use these to evaluate a provider or scope a proposal:

• Who will actually be running the test, and what is their background?
• Does the scoping call involve a tester, or only a sales contact?
• Are you proposing blackbox testing, and if so, why is that the right choice for our environment?
• What deliverables are included, and can I see a sample report? (VidraSec publishes example reports so you know exactly what you’re getting.)
• What is your process for handling critical findings during the engagement?
• Do you recommend follow-up testing after remediation, and how is that structured?

A provider who pushes back thoughtfully on these questions, rather than just answering them, is usually the right choice.

Summary

The market has plenty of providers who will happily sell you a compliance checkbox. The ones worth working with are the ones who tell you when a different approach would serve you better.

Questions about scoping your next pentest? Get in touch.

Related Services

• Active Directory Audit
• Internal IT Infrastructure Penetration Test
• Cloud Infrastructure Audit
• Entra ID Audit
• External IT Infrastructure Penetration Test
• Web Application Penetration Test