Penetration testing is one of the hardest security services to buy well. The proposals look nearly identical, the market runs from relabelled vulnerability scans to genuinely rigorous engagements, and you usually discover which one you bought only after the report lands. These ten questions separate the two. They are worth asking of any provider — including us — and a good one will welcome every single question.
1. Will findings be demonstrated or inferred?
This is the largest quality gap in the market. Many products sold as pentests are vulnerability scans with a human summary: findings inferred from version banners and plugin output, a meaningful share of which are not real. Every false positive you investigate is engineering time spent on nothing.
A good answer: every reported finding comes with evidence — the request and response, the credential chain, the recorded steps showing the route was actually walked. Ask to see a sample finding with its evidence attached. A provider who demonstrates rather than infers will show you one without hesitating; a provider who points at severity scores instead is selling you a scan.
2. How is scope agreed, and what is off-limits?
An ambiguous scope produces one of two bad outcomes: a test that quietly skips your riskiest systems, or an incident because something was touched that should not have been. Both trace back to the same missing document.
A good answer: a written scope naming systems and ranges, explicit exclusions, agreed rules of engagement for permitted techniques, and a defined process for extending scope mid-engagement when testing uncovers something adjacent. Be wary of "we test everything" — and equally wary of a scope trimmed until the test cannot fail.
3. How are live systems protected during testing?
Production is where the truth is; a test confined to a staging replica proves things about the replica. But testing live systems demands discipline, and "we're careful" is not a safety model.
A good answer is specific and technical: non-destructive verification methods designed to prove a route exists without disturbing it, rate limits, no bulk data extraction beyond minimal proof, defined stop conditions, and monitoring during testing windows. If the provider cannot describe their safeguards in a paragraph, assume the safeguard is hope.
4. Who actually does the testing?
The proposal is written by senior people. The work is sometimes delivered by whoever is available, or subcontracted entirely. For automated platforms, the equivalent question is what drives the engine and who reviews its output.
A good answer names the people or the roles doing the work, states plainly whether anything is subcontracted, and tells you who you can call when a finding needs explaining. You are buying judgement as much as activity, and you are entitled to know whose judgement it is.
5. What does the report look like, and who is it written for?
The report is the product. If it is a scanner export behind a cover page, you paid for formatting. A report only executives can read will not help engineers fix anything; a report only engineers can read will not move budget.
A good answer: a redacted sample report before you sign. Look for reproduction steps an engineer can follow, impact stated in plain language, prioritisation that reflects real attack paths rather than raw severity ordering, and a short executive section that needs no translator.
6. How are fixes verified?
A pentest that ends when the PDF arrives leaves the most important question open: did the fixes work? A closed ticket is a claim. A failed re-attack is proof. Patches applied to one node but not its siblings, credentials rotated in the vault but still cached in a script — the gap between claim and proof is where organisations get breached after "fixing" the problem.
A good answer: re-testing is included, not a paid extra buried in the statement of work, and the original route is attempted again with the result recorded. Ask what fraction of fixed findings fail re-test. An honest provider has a number, and it is not zero.
7. How current is the testing between engagements?
An annual pentest describes one week of one year. Your environment changes every week after that — deployments, new accounts, rule changes, staff turnover. The report starts ageing the day it lands, and an attacker probing you in month seven is not working from your last assessment.
A good answer is honest about the shelf life of point-in-time results and clear about what happens between them. Options run from scheduled re-engagements triggered by major releases and infrastructure changes to continuous assessment. We think continuous testing is the right default — but even a point-in-time provider should have a considered answer, and "see you next year" is not one.
8. How is evidence handled and stored?
A pentest produces some of the most sensitive artifacts your organisation will ever hand to a third party: working credentials, screenshots of your data, a map of your weaknesses. Handled loosely, that material is a breach waiting for a courier.
A good answer covers where evidence is stored, how it is encrypted, who can access it, how long it is retained, and how it is destroyed — plus minimisation at the point of collection, so proof never requires wholesale copies of your data. Ask how findings are transmitted to you. If the answer is email, keep shopping.
9. What happens if something breaks?
Even disciplined testing carries residual risk. What distinguishes providers is not the claim that nothing will ever break — it is the plan for when something does.
A good answer: a defined incident procedure with an immediate halt condition, a named contact reachable throughout testing windows, notification timelines, and help with recovery. Read the contract too — liability and insurance terms should be legible, not buried in an annex you find after the fact.
10. How does pricing map to scope?
Pentest pricing is opaque, and a day-rate quote tells you the cost without telling you what you get. The cheapest proposal usually buys the shallowest possible reading of the scope, which is how a two-week engagement becomes three days of scanning and seven days of report assembly.
A good answer ties price to defined scope — assets, environments, depth — and states what is included: re-testing, support calls, access to evidence, questions after delivery. Compare proposals on what is included at the same scope, never on the bottom line alone. A quote that cannot explain itself will produce a test that cannot either.
What the ten questions have in common
Every question on this list reduces to the same demand: proof. Proof that findings are real, proof that live systems are protected, proof that fixes worked, proof that your evidence is handled with care, proof that the price buys what the proposal describes. Providers who work from evidence answer these questions easily, because the answers are how they already operate. Providers who work from inference tend to answer with adjectives.
Whichever way you buy — point-in-time or continuous, human-led or engine-driven — ask all ten, and get the answers in writing. The hour it takes is the cheapest security control you will purchase this year.