In short
- Define an attacker objective, not just a target list
- Credentialed testing finds what an attacker finds after the first compromise
- Excluding systems because they are fragile excludes exactly what an attacker will target
- Agree the retest before the test, not after the report
Organisations frequently receive a penetration test report, note that the findings are mostly medium and low severity, and conclude their security posture is sound. Sometimes that is true. More often the scope prevented the test from reaching anything that would have produced a serious finding.
1. Scope to an objective, not an asset list
"Test these twelve IP addresses" produces a list of weaknesses on twelve hosts. "Determine whether an attacker starting from the internet can reach customer records" produces an answer to a question the business actually asked.
Objective-driven testing changes what the tester does. Findings get chained: a low-severity information disclosure plus a medium-severity access control flaw may together produce a critical outcome. Reported in isolation, both would have been deprioritised.
2. Decide deliberately about credentials
Fully black-box testing has a certain appeal — it feels like a realistic simulation. In practice it spends a large proportion of the engagement on reconnaissance that a determined attacker would perform over months, and produces less coverage for the same money.
For most organisations the more valuable question is what an attacker can do after obtaining a standard user account, because that is where a real intrusion usually begins. Providing test credentials at one or more privilege levels tests privilege escalation, lateral movement and access control enforcement — which is where the serious findings usually are.
3. Do not exclude the fragile systems
The legacy application nobody wants touched during business hours is, reliably, the one with the most severe findings. Excluding it from scope does not reduce risk; it hides it.
Where a system genuinely cannot tolerate testing, the answer is to test a representative replica, or to test during an agreed window with rollback available — not to place it out of scope and mark the assessment complete.
4. Allow enough time for manual testing
Automated scanning finds known vulnerabilities in known software. It does not find broken access control between two user accounts, business logic that permits an invalid state, or a workflow that can be replayed for financial advantage. Those require a person, and a person requires days.
If a proposal allocates a small number of days across a large estate, the resulting assessment is a scan with a report attached. Fewer targets tested properly is more valuable than everything tested superficially.
5. Agree the retest up front
Remediation is the point of the exercise. Agree at scoping how findings will be retested, within what window, and what evidence of closure will be issued. Left until after the report, retesting becomes a separate commercial conversation and frequently does not happen — leaving findings closed on assertion.
What to ask for in the report
- An executive summary stating residual risk in business terms, not a severity histogram
- Reproduction steps sufficient for your engineers to verify the finding independently
- Business impact per finding, not only a CVSS score
- Attack paths showing how findings combine, where they do
- Remediation advice specific to your environment rather than generic vendor guidance
- A statement of what was in scope and — importantly — what was not
Related practices
