Most failed pentests fail before the tester writes a single line. They fail at the brief. This guide helps you commission a test that delivers what you actually need — and not pay for it twice.

Why the brief matters more than the price

A penetration test is one of the few services where the buyer often cannot judge the quality of the output. When you have your car repaired, you know if it runs. When you commission a pentest, you get a document with findings — but you have no idea whether the tester actually covered what they were supposed to, or just clicked through an automated scanner in an afternoon.

The difference between a good and a bad test does not show up on the invoice. It shows up the day someone breaches you through something the tester "didn't test because it wasn't in scope". And it wasn't in scope because you didn't put it there.

A good brief is therefore your only real lever on quality. Let's go through how to prepare one.

Step 1: Be clear about why you are testing

It sounds trivial, yet it is the most common mistake. Companies commission pentests for several very different reasons, and each leads to a different type of test:

Meeting a regulation or audit (NIS2, ISO 27001, DORA, customer requirement). Here the output must contain what the auditor or regulator wants to see — not necessarily maximum technical depth, but evidence and the right format.
Genuine security verification before launching a new system or after a major change. Here depth and realism matter.
Incident response or suspicion that something is already wrong.
Pressure from leadership or a customer who wants "paper" proving you are tested.

If you're testing for audit reasons but order the cheapest automated scan, you'll get the paper, but you won't have verified actual security. Conversely, if you only need to prove compliance, there is no point paying for a month-long red team.

Write a single sentence: "We are running this test because ___, and we'll know it succeeded when ___." That sentence should be the first line of your brief.

Step 2: Understand the basic test types

Three terms get used interchangeably even though they mean fundamentally different amounts of work and very different prices:

Vulnerability scan is mostly automated. A tool sweeps the system and lists known vulnerabilities. It's fast and cheap, but does not verify exploitability and finds no logic flaws. Useful as routine hygiene, not as a substitute for a test.

Penetration test combines tools with manual work by a tester who actively tries to exploit and chain vulnerabilities to go deeper. It catches application-logic flaws no scanner will. This is what most organisations actually need.

Red team / threat-led testing is a broad simulation of a real attacker across technology, people and physical security, often running for weeks or months. The goal is not to find every vulnerability but to verify whether someone can really break you — and whether you would even notice. Expensive, and only makes sense for mature organisations.

If you write "we want a pentest" in your RFP but actually mean a scan — or the other way round — you'll get non-comparable bids and wonder why prices differ by 5×.

Step 3: Choose the knowledge level (black / grey / white box)

How much information you give the tester fundamentally changes the result and the price:

Black box — the tester knows nothing and simulates an external attacker. Realistic, but the tester spends a lot of time on reconnaissance and may miss things they simply can't reach.
Grey box — the tester gets a basic foothold, e.g. a regular user account. The best ratio of realism to efficiency, hence the most common choice.
White box — the tester gets everything: source code, documentation, access. Finds the most because no time is wasted guessing. Ideal for a thorough review of a critical system.

Rule of thumb: the more critical the system, the more information you should give the tester. The "let's test it blind to be fair" instinct sounds noble but usually just wastes budget.

Step 4: Define scope precisely

This is the heart of the brief. The tester must know exactly what is allowed and what isn't. Prepare:

Specific targets — domains, application URLs, IP ranges, API endpoints, mobile apps. Not "our systems", but a named list.
Explicit out-of-scope items — third-party systems, production databases, anything that must not go down.
Environment — production or a staging copy? Staging is safer but must faithfully match production, otherwise the results are worthless.
Time window — when testing is allowed so any outage doesn't hurt.
Allowed techniques — may the tester attempt social engineering? DoS? Physical intrusion? Anything you don't mention, they shouldn't do.

The more specific the scope, the more comparable the bids you'll get and the less room there is for later disputes of "we didn't test that".

Step 5: Prepare access in advance

A large share of failed projects collapse because the buyer isn't ready. The tester shows up, waits for access and bills for downtime. Before the test starts, have ready:

Test accounts with different privilege levels
Access to the staging environment and IP whitelisting for the tester
API and architecture documentation
A point of contact reachable for the whole duration of the test
Internal sign-off — IT, legal, and where applicable the cloud or hosting provider

Tip: cloud providers (AWS, Azure) often require prior notification of a penetration test. Handle this well ahead of time.

Step 6: Demand a concrete report format

The report is the only thing that will remain after the test. Decide upfront what it must contain:

An executive summary understandable to leadership — no jargon.
A technical section covering every vulnerability with its CVSS score, proof of exploitability and a concrete remediation recommendation.
Prioritisation of findings by real risk, not just by raw scanner score.
Retest — verifying that fixed findings are actually fixed. Often billed separately, so ask up front.

Ask the vendor for a sample (anonymised) report before signing. The quality of the report is visible at a glance and is the single best filter for vendors.

Step 7: Have realistic price expectations

Price tracks scope and depth, not a flat rate. Smaller tests start in the low five figures (EUR); large or red-team engagements go significantly higher. If you receive three bids and one is a third of the others, that is not good news — it almost certainly proposes a different (shallower) scope of work. Always compare what is actually included: man-days, depth, manual vs. automated work, and whether retest is bundled.

Summary: checklist before sending the RFP

Before sending the RFP, check that:

I know why we're testing and how we'll measure success
I know whether I want a scan, a pentest or a red team
I have chosen the knowledge level (black / grey / white box)
I have a named target list and explicit out-of-scope items
I've resolved environment, time window and allowed techniques
I have access ready (accounts, network access, documentation, contact)
I have defined the required report and retest format
I have internal and external sign-offs

A well-prepared brief is the difference between a test that genuinely raises your security posture and a test you pay for and file in a drawer.

Preparing a complete pentest brief by hand takes hours and it's easy to forget something. TrustScope walks you through the whole process step by step and at the end produces a structured brief ready to send to vendors — including the access checklist you need to prepare.

Before you order a pentest: a complete buyer's guide