The First Pen Test: Buying One Without a Security Team

The request arrived the way it usually does: a customer's security questionnaire asked for your latest penetration test, or the cyber insurance renewal form did, and the honest answer is that there has never been one. Now someone has to buy a service the company has never bought, evaluate a vendor whose work it cannot judge, and act on findings it may not understand.

A first penetration test is not hard to buy well, but it is easy to buy badly. Bought badly, it is an expensive automated scan with a logo on the cover. Bought well, it is a week of a skilled person genuinely trying to get in, followed by a report your team can work from.

The difference is in the scoping conversation, and you do not need a security team to run it. You need the questions below.

Key takeaways

• A pen test is a person trying to get in; a scan is a tool listing known holes. Know which you are buying.

• Scope by what matters: the systems that hold customer data or run the business.

• Ask who does the work, how many days, and what a sample report looks like.

• Plan the retest conversation before the test, not after the findings arrive.

• Budget for fixing, not just testing: the report is the beginning of the spend.

Step 1: Decide what the test is for

The purpose shapes everything. A test bought because a customer asked is mostly evidence: it needs to be credible to an outsider. A test bought to find your own weaknesses is mostly diagnosis: it needs to be honest above all. Most first tests are both, and saying so changes what you ask for.

Write down the two or three systems whose compromise would genuinely hurt: the customer database, the quoting system, the file shares. Those are the scope. A tighter scope tested deeply beats the whole network tested thinly, and it costs less.

The discipline mirrors any good assessment; the structure in a solid program assessment checklist applies at this smaller scale.

Step 2: Ask the questions that separate testers from scanners

Three questions sort the market quickly. Who does the work, and what are their names and backgrounds? How many person-days are in the price, and how much of it is hands-on versus automated? And may we see a sanitized sample report?

The sample report is the great revealer. A real tester's report reads like a story: what they tried, what worked, how far they got, what it proves. A scanner's report reads like a spreadsheet export, because that is what it is.

This fictional example shows two quotes for the same job. It is an illustration, not a prescription.

	Vendor A	Vendor B
Price	$9,500	$28,000
Effort	3 days, 'automated with manual validation'	10 days, named consultants
Sample report	Tool output, 80 pages of CVEs	Narrative attack paths, 25 pages
Deliverable meeting	Extra	Included, with retest

Vendor B costs more and finds more. Vendor A is a scan wearing a suit.

Step 3: Set the rules of engagement in plain language

Before anyone touches your systems, agree on the practical boundaries: which systems are in, which are out, what hours testing happens, who gets called if something breaks, and what the testers may not do, such as disrupting production or contacting your staff.

None of this is legal work; it is a one-page email both sides confirm. The point is that a surprise outage during the test is a process failure, not a finding, and it is entirely avoidable.

Tell your IT provider the test is happening. A tester mistaken for a real attacker burns everyone's weekend, and a provider who knows can watch the test work, which is its own education.

Step 4: Treat the report as the start of the work

When the report arrives, ask for the walkthrough call and bring the people who will do the fixing. For every finding, the question is the same: what does fixing this look like, who owns it, and when?

The pattern that wastes the money is well documented: findings that get acknowledged, filed, and rediscovered by next year's test. The follow-through discipline in closing the loop on pen test findings is what makes the second test cheaper than the first.

Share the existence of the test upward. A board that hears 'we ran our first real test and fixed what it found' is hearing a maturity sentence, not a technical one, and the lens a director brings to reading the report shows how little translation it actually needs.

The related discussion of read a penetration test report is worth your time alongside this one. The related discussion of closing the loop on pen test findings is worth your time alongside this one.

Frequently asked questions

How much should a first pen test cost?

For a small company with a tight scope, real manual testing typically runs into the tens of thousands of dollars. Anything dramatically cheaper is usually an automated scan. Ask for person-days to make quotes comparable.

Is a vulnerability scan good enough instead?

For a customer questionnaire, sometimes - read what was actually asked for. As a security measure, a scan is a fine start and a poor finish: it lists known issues but never proves what an attacker could chain together.

How often should we repeat it?

Annually is the common rhythm, plus after major changes such as a new customer-facing system. If findings keep recurring between tests, the gap is in the fixing process, not the testing cadence.

A Defensible Next Step

If a customer or insurer has asked for a test you have never run, start with the scope sentence: the two or three systems whose loss would hurt most. That sentence makes every quote comparable and every report useful. Book a Decision-Clarity Call if you want a second pair of eyes on the quotes.