Two organisations can both say "we get an annual pentest" and be describing completely different levels of assurance. The difference is almost never the tester's skill. It is the scope, agreed weeks earlier in a document most buyers treat as paperwork.
A real attacker does not respect your scope. They go where the value is and in through whatever is weakest. A useful penetration test approximates that behaviour as closely as your risk appetite and budget allow, and the scoping conversation is where that approximation is set.
The default scope is a list of systems: this web application, that IP range. The better starting question is what an attacker would want from you. Customer records, payment flows, intellectual property, the ability to move money, the ability to disrupt operations. Then work backwards: which systems touch those assets, and which paths lead to them?
Worked this way, the scope usually changes shape. The marketing site drops out; the forgotten API that fronts the customer database drops in. The corporate network matters less than the identity provider that gates everything. This is also how the test stays affordable: money is spent where compromise would actually hurt.
Scoping conversations have a predictable pattern: the systems everyone is confident about go in, and the awkward ones get excluded. The legacy application nobody wants to touch, the third-party integration, the subsidiary's environment, the thing that might fall over if tested. Every one of those exclusions is a note that says an attacker would start here.
There are legitimate exclusions, fragile production systems chief among them, and there are good ways to handle them: test a staging replica, agree careful timing windows, or explicitly accept the untested risk in writing so it is a decision rather than an oversight. What should not happen is the quiet narrowing that leaves the test covering only the defensible ground.
An external test answers one question: can someone get in from the internet? Increasingly, the more valuable question is the second one: what happens once someone is in, because phishing, stolen credentials and supply chain compromises mean the perimeter fails somewhere eventually. An assumed-breach scope, starting the tester with a standard user's access, tests the controls that determine whether an incident is contained or catastrophic: segmentation, privilege escalation paths, detection and response.
If the budget covers one test a year, alternating between the two framings across years covers more ground than repeating the same external test until it stops finding things.
Ask to see a sample report before engaging anyone. It should read as two documents in one: risk in business terms for the people who own the budget, and reproduction steps with remediation guidance for the engineers who fix the findings. If it reads like a scanner export with a logo, that is what you would be buying.
Then insist on retesting. A finding that is reported but never verified as fixed is a liability with a paper trail. We include retesting in every engagement rather than selling it separately, because a test that ends at the report has done half the job.
Our cyber security practice scopes penetration tests against what organisations actually hold. The scoping conversation itself costs nothing and usually changes the test.
Ben Jones leads penetration testing, red team and incident response at Coder Trove.