Most organisations buy penetration tests. Far fewer get their money's worth from them. The difference is almost never the skill of the testers - it is what happens before the test is scoped and after the report lands. Here is how to be in the second group.
Know what you are actually buying
"Penetration test" describes a range of very different products, and confusion here is the root of most disappointment.
| What it is | What it answers | When to use it |
|---|---|---|
| Vulnerability scan | What known issues does an automated tool find? | Continuous hygiene; cheap and frequent. |
| Penetration test | Can a skilled attacker exploit and chain issues in this defined scope? | Before a launch, after big changes, annually. |
| Red team | Can we detect and stop a determined adversary pursuing a goal? | Mature programmes testing detection and response. |
If you buy a scan and expected a red team, you will feel short-changed - and if you buy a red team when you have never run a scan, you will pay a premium to be told things a cheaper test would have caught. Match the product to your maturity.
A test bought purely to satisfy an auditor tends to be scoped narrowly and priced to the floor - and it produces a certificate, not security. That is fine if a certificate is genuinely all you need. Just do not mistake it for an honest measure of how you would fare against a real attacker.
Scope deliberately
Scope is the single biggest lever on the value of a test. Too narrow and you get false comfort; too broad and the testers spread thin and miss depth.
- Start from what you are protecting. Which systems, if compromised, would genuinely hurt? Scope towards those, not towards whatever is easiest to point a tool at.
- Be honest about exclusions. Every out-of-scope system is a blind spot you are choosing to keep. That can be a reasonable decision - but make it consciously and write it down.
- Decide the starting position. Should testers start as an anonymous outsider, a logged-in customer, or a compromised employee? Each answers a different, valuable question. "Assume breach" starting points often reveal the most, because real attackers rarely start from zero.
Give testers what they need
There is a persistent myth that withholding information makes a test "more realistic". It mostly makes it slower and shallower. Real attackers have unlimited time; your testers have a fixed number of days. Every hour they spend rediscovering your architecture is an hour not spent finding the flaw that matters.
A well-briefed tester with credentials and a network diagram will out-find a blindfolded one every time - because they spend their days attacking, not mapping.
Provide documentation, test accounts at each privilege level, and a named technical contact who can unblock them quickly. You are buying their attacking time; do not waste it on reconnaissance you could hand over.
Read the report critically
When the report arrives, resist the urge to skim the executive summary and file it. This is where the value is either captured or lost.
- Look past the severity ratings. A "medium" that exposes your customer database matters more than a "high" on a marketing microsite. Ask the testers to rank findings by impact to your business, and push back if the ranking is generic.
- Read the attack narrative, not just the finding list. The story of how they chained three "minor" issues into full compromise teaches you more about your real weaknesses than any single line item.
- Ask what they could not do. The things that stopped them are your controls working - worth knowing so you keep funding them.
Close the loop - or you wasted the money
A finding is not fixed because it is written down. The organisations that improve treat the report as the start of the work, not the end.
- Assign every finding an owner and a due date.
- Fix the root cause, not just the specific instance the testers happened to find. One exposed default credential usually means a process problem, not a single mistake.
- Budget for a retest. A short re-check that confirms the fixes actually worked - and did not introduce new issues - is the cheapest, highest-confidence part of the whole exercise.
A penetration test is a tool for making decisions, not a trophy. Scope it around what you value, arm the testers, read the findings for the story they tell, and measure success by what you fixed - not by the fact that you tested.
If you want a test scoped around your actual risk and a team that cares whether the findings get fixed, that is how our penetration testing practice works.