Buying a penetration test: how to scope it so the report is worth reading

Quotes for the same nominal engagement routinely differ by five times, and the cheap one is often an automated scan with a cover page. Since most buyers cannot evaluate testing quality directly, the practical defence is scoping precisely enough that providers are quoting for the same work.

Decide what you are actually testing

"Test our security" is not a scope. Common engagement types, which are genuinely different work:

• External infrastructure - internet-facing systems. Usually the baseline, and the cheapest.
• Web or mobile application - business logic, authentication, authorisation, injection. Priced by application complexity, not server count.
• API testing - increasingly the real attack surface, and frequently omitted because the web front end was tested instead.
• Internal network - assumes a foothold, tests lateral movement and privilege escalation. This is where segmentation claims get verified.
• Cloud configuration review - identity, permissions, exposure. Different skill set from network testing.
• Social engineering - phishing and pretexting, with specific legal and HR considerations.
• Red team - objective-based, adversary-simulating, tests your detection and response as much as your controls. Only worth buying once your defences are mature enough for the answer to be informative.

If you have never tested, start with external infrastructure and your main application. A red team against an untested estate produces an expensive report saying what a much cheaper test would have found.

Knowledge level, and the credentialed testing point

Black box gives testers no information; grey box gives partial access and credentials; white box gives full documentation and source. Providers sometimes market black box as more realistic, but for a fixed budget it is usually the worst value: testers spend days on reconnaissance that a real attacker would spend months on, then run out of time before reaching the interesting parts.

For application testing, insist on credentialed testing with accounts at every privilege level. Most serious application findings - broken access control, privilege escalation between roles, tenant isolation failures - are only reachable by an authenticated user. An unauthenticated test of a login-gated application tests the login page.

What to put in the request

• Precise scope - IP ranges, domains, application URLs, API endpoints, user roles, and anything explicitly excluded.
• Effort in tester-days, not just a price. This is the single most useful comparison metric, and it exposes the automated-scan quotes immediately.
• Tester qualifications and CVs - who is actually doing the work, not the firm's credentials.
• Methodology referenced to a recognised standard (OWASP ASVS or Testing Guide for applications).
• A sample report, redacted. This tells you more than any sales conversation.
• Retest included, and how long you have to use it.
• Whether findings are manually verified - a report full of unvalidated scanner output is not a penetration test.

Rules of engagement

Agree before work starts: testing window, escalation contacts on both sides, what happens if a critical vulnerability is found mid-test (it should be reported immediately, not held for the report), whether denial-of-service is in or out of scope, data handling and destruction, and whether your provider needs authorisation. Cloud and SaaS platforms have their own testing policies - test what you do not own without checking, and the problem is yours.

Get written authorisation from someone with authority to grant it. This protects the testers legally and you organisationally.

Reading the report

• Judge findings on reachability and impact, not just the severity rating. A critical on an isolated internal system may matter less than a medium on your login flow.
• Expect an executive summary that says something. "Several issues were identified" is filler; a good summary characterises your security posture and the themes behind the findings.
• Look for root-cause themes. Twelve instances of missing authorisation checks is one design problem, not twelve bugs - and fixing it that way prevents recurrence.
• Check what was not tested and why. An honest limitations section is a quality signal.

Then fix things, retest, and keep both the report and the remediation evidence. Auditors ask for the test and proof that findings were addressed - a report with open criticals from eighteen months ago is worse than no report at all.

Frequency

Annually is the common compliance baseline, plus after significant change. But an annual test on a system that deploys weekly gives you fifty-one weeks of unverified change - which is why continuous scanning and secure development practice sit alongside testing rather than being replaced by it.

Key takeaways

• Compare tester-days, not headline price - it exposes automated-scan quotes.
• Insist on credentialed testing for applications, at every privilege level.
• Agree rules of engagement in writing, and check your cloud provider's testing policy.
• Keep the report and the remediation evidence - auditors ask for both.