Penetration testing vs vulnerability scanning: what auditors expect

A vulnerability scan asks "what known weaknesses are present?" A penetration test asks "what could an attacker actually achieve?" Both are useful, neither replaces the other, and telling an auditor your quarterly scan is your penetration test is a reliable way to collect a finding.

Vulnerability scanning

• Automated, comparing systems against a database of known vulnerabilities and misconfigurations.
• Broad and shallow - covers everything in scope, but finds only what its signatures know.
• Frequent - weekly, monthly or continuous, and cheap enough to run often.
• Produces volume. Hundreds of findings with severity ratings, requiring triage against your actual exposure.
• False positives are normal, which is why unvalidated scan output is not a remediation plan.

Penetration testing

• Human-led, using tools but driven by expertise and creativity.
• Narrow and deep - chains weaknesses together to demonstrate real impact.
• Periodic - typically annual, or after significant change.
• Finds what scanners cannot: business logic flaws, broken authorisation, privilege escalation paths, and the combination of three "medium" issues that together yield domain admin.
• Produces a narrative - attack path, impact, evidence, and recommendations.

The most valuable penetration test finding is rarely a single critical vulnerability. It is the chain: this exposed service, plus that weak credential policy, plus this flat network, equals access to customer data.

What frameworks require

• PCI DSS is the most prescriptive - internal and external scanning at defined frequencies and after significant change, external scans by an Approved Scanning Vendor, plus penetration testing including segmentation testing where segmentation is claimed.
• ISO 27001 requires technical vulnerability management and evaluation of effectiveness; the specific testing approach follows from your risk assessment.
• SOC 2 has no fixed mandate, but auditors expect testing consistent with what your own policy commits to.
• NCA ECC and SAMA CSF expect vulnerability management with evidence of remediation, and penetration testing for critical systems.

Note the recurring pattern: you are usually tested against your own stated cadence. Promising quarterly testing you do not perform is worse than committing to annual testing you complete.

Scoping a test that is worth the money

1. Define objectives, not just targets. "Can an unauthenticated user reach customer data?" produces better work than "test these ten IPs".
2. Include authenticated testing. Unauthenticated-only testing misses the majority of application flaws.
3. Test the environment that matters - production or a faithful mirror. A stale staging environment yields findings about staging.
4. Include the business logic, not just the infrastructure.
5. Agree rules of engagement - timing, escalation contacts, and what happens if the tester achieves critical access.
6. Require a retest of remediated findings, and budget for it up front.

Handling findings properly

• Triage against real exposure - a critical rating on an isolated internal system may matter less than a medium on an internet-facing one.
• Set and meet remediation SLAs by severity, and evidence closure.
• Fix the class, not just the instance. One injection flaw usually implies a pattern in the codebase.
• Retest and record - closure without verification is the finding auditors raise next cycle.
• Feed themes into your risk register and your secure development training.

Key takeaways

• Scanning is broad and automated; penetration testing is deep and human-led.
• You are tested against your own stated cadence - commit carefully.
• Scope by objective, include authenticated testing, and budget for retests.
• Fix the class of flaw, not just the reported instance.