What to Expect from a Penetration Test — and How to Scope One Correctly
A penetration test is only as useful as the scope it's given. We see this constantly: clients who commission a pen test expecting comprehensive assurance, and receive a report covering three web pages and a VPN endpoint — because that's all they defined.
Scoping is where pen tests succeed or fail before a single packet is sent.
What a Pen Test Actually Does
A penetration test is a structured, authorised attempt to find and exploit vulnerabilities in a system, network, or application before a real attacker does. A good tester thinks like an adversary: they don't just run a vulnerability scanner and export the results — they chain findings together, look for privilege escalation paths, and test whether theoretical vulnerabilities are actually exploitable.
The output is a report of findings ranked by severity, with evidence, impact assessment, and remediation guidance. Done well, it tells you not just what's vulnerable, but what an attacker could actually do with it.
Types of Pen Test
Network infrastructure — internal or external. External tests what's exposed to the internet. Internal simulates what an attacker with network access (an insider, or someone who's breached the perimeter) can reach and do.
Web application — targets a specific application: authentication, authorisation, input handling, session management, business logic. The OWASP Top 10 is a reasonable framework for what should be covered.
Cloud configuration review — assesses your AWS, Azure, or GCP environment for misconfiguration. Not a traditional pen test but increasingly important as infrastructure moves off-premises.
Social engineering — phishing simulations, pretexting calls, physical access testing. Often the most revealing, because it bypasses technical controls entirely.
Red team exercise — a full-scope, adversary simulation engagement. Not the same as a pen test; red team is objective-based (can they reach the crown jewels?) rather than vulnerability-cataloguing.
Common Scoping Mistakes
Scoping too narrow
The most common mistake. Clients exclude cloud infrastructure because "that's managed by the provider." They exclude legacy systems because "nobody touches those." They define scope based on what they think is important rather than what an attacker would target.
Attackers don't respect administrative boundaries. If a forgotten web server shares credentials with your core systems, it's in scope whether you included it or not.
Fix: define scope based on what you want to protect, then work backwards to what could reach it.
Scoping too broad with no time budget
The opposite problem. "Test everything" sounds thorough, but with a fixed number of test days, testers either skim the surface of everything or go deep on one area and miss the rest.
Fix: agree on priorities. What are the crown jewels? What's the most likely attack path? Start there.
Not defining success criteria
A pen test with no success criteria is just a list of findings. What were you trying to answer? Can an attacker reach customer data? Can a compromised workstation move laterally to the domain controller? Define the question before you commission the test.
Skipping the debrief
The written report is not the deliverable. The debrief — where a tester walks your team through findings, answers questions, and explains attack chains — is where the value is. Insist on it.
What to Prepare Before Testing Starts
- Rules of engagement document — signed by both parties, covering scope, timing, escalation contacts, and what happens if a tester finds something critical mid-test
- Out-of-scope list — third-party systems, production databases you can't afford to take down, anything with a zero-tolerance policy
- Emergency contacts — someone who can be reached at any time during the test window if something unexpected happens
- Test accounts — for application tests, pre-created accounts at each privilege level speed up testing and reduce time spent on authentication
Interpreting the Report
Severity ratings (Critical, High, Medium, Low, Informational) are a starting point, not a remediation order. A Medium finding that's trivially exploitable and directly exposes customer data may need addressing before a Critical finding that requires a complex exploit chain and physical access.
Ask your tester to walk you through the risk in your context. The best pen test reports are written for the business owner, not just the technical team.