PCI DSSBy Mehar un Nisa · 18 Jul 2026 · 5 min read

Is a Vulnerability Scan a Penetration Test? What PCI DSS, SOC 2 and ISO 27001 Actually Require

Companies routinely hand auditors a vulnerability scan and call it a penetration test. They are not the same — and PCI DSS, SOC 2 and ISO 27001 each treat them differently. An auditor's guide to the difference, with the five questions that reveal what you actually bought.

Reviewed by Dr Rizwan Ahmad: PCI QSA · MSECB Auditor of the Year 2024 (Asia-Pacific)

There is a moment that repeats itself in our audits, year after year. We ask for the penetration test report. The client, quite confident, sends over a PDF. It turns out to be a scanner export: four hundred pages, unauthenticated, generated the previous Tuesday, and by the look of it never read by a human being. Nobody is being dishonest here. Somewhere along the way, someone genuinely believed the scan was the pentest. We see this in PCI DSS assessments, in SOC 2 examinations, in ISO 27001 audits, in New Zealand and in Australia, in ten-person startups and in listed companies.

The two are cousins, not twins. No standard we assess against treats them as interchangeable, and the gap between them has failed more than one assessment that was otherwise in good shape.

The difference in one analogy

A vulnerability scan walks around your building checking every door and window against a catalogue of known weaknesses. This lock model has a recall notice on it; that window latch doesn’t quite close. Software does the walking, which is why you can afford to do it every week.

A penetration test hires a skilled burglar, with your written permission, to actually try to get in. They pick the lock. They notice the unlatched window is next to the unattended keycard, and that the two together are worth more than either alone. Then they hand you a photograph of themselves standing in your server room. No scanner has ever talked its way past a reception desk. People do it all the time.

NIST SP 800-115, the U.S. standards body’s technical guide to security testing, draws exactly this line: scanning identifies potential vulnerabilities, while penetration testing moves into exploitation: verifying that the weakness is real, chaining flaws together, and demonstrating actual business impact. The PCI Security Standards Council’s Penetration Testing Guidance spends an entire section separating the two. The Council would not have needed to write that section if the industry didn’t keep blurring it.

Side by side

	Vulnerability scan	Penetration test
Performed by	Automated tool	Skilled human tester (using tools)
Method	Matches systems against known-vulnerability signatures	Actively exploits weaknesses, chains them, pivots
Answers	“What known weaknesses exist?”	“What can an attacker actually do to us?”
Depth	Broad and shallow	Narrow and deep
Typical frequency	Quarterly or continuous	Annual + after significant changes
Output	Ranked findings list	Attack-path narrative with proof of exploitation
False positives	Common; unverified	Eliminated; every finding demonstrated

What each standard actually requires

PCI DSS v4.x requires both, explicitly and separately. Requirement 11.3 mandates vulnerability scanning: internal scans at least quarterly (authenticated scanning now required under 11.3.1.2) and external scans quarterly by an Approved Scanning Vendor. Requirement 11.4 separately mandates penetration testing: internal and external tests at least annually and after significant changes, plus segmentation testing to prove your network boundaries hold. Handing a QSA a scan report to satisfy 11.4 doesn’t work. The standard’s own supporting documents define penetration testing as a distinct, methodology-driven exercise. And under v4.x, exploitable findings must be corrected and retested. A report alone no longer closes the loop.

SOC 2 names neither, but expects evidence of both disciplines. The AICPA Trust Services Criteria require you to identify and manage vulnerabilities (CC7.1) and to evaluate whether your controls actually work (CC4.1). In practice, scanning demonstrates the first; an independent penetration test has become the prevailing evidence for the second. A SOC 2 examiner who sees only scanner output will ask what validated your controls against a determined adversary.

ISO/IEC 27001:2022 is principle-based, with the same logic. The standard’s Annex A control 8.8 requires management of technical vulnerabilities, and scanning naturally serves this. But an ISMS must also evaluate the effectiveness of its controls, and certification auditors look for testing proportionate to your risk. For most organisations with meaningful attack surface, that means periodic penetration testing as assurance evidence, not just a scanner subscription.

Why the confusion persists

Partly, the confusion is sold. A number of products market “automated penetration testing” that is, if you hold it against NIST’s definition, enhanced scanning with better fonts. The word “authenticated” does damage too: an authenticated scan logs in and checks patch levels, which sounds intrusive, but it still never exploits anything. And then there is the thickness problem. A 400-page scan export simply looks more rigorous than a 30-page pentest report. It isn’t. The thin report contains attack paths somebody proved. The thick one contains possibilities nobody checked.

Five questions that reveal what you actually bought

Did a named human attempt to exploit findings, or did software only enumerate them?
Is there a methodology cited, such as the PCI SSC guidance, NIST SP 800-115 or the OWASP Web Security Testing Guide?
Does the report show proof: screenshots, extracted (sanitised) data, chained attack narratives?
Who did the work: a qualified tester whose credentials appear in the report?
Was there a retest after you fixed the findings?

If the answers are no, no, no, “the tool”, and no, then what you have is a vulnerability scan. It’s genuinely valuable. It’s just not a penetration test, and your assessor is required to know the difference.

The auditor’s bottom line

You need both, and they don’t substitute for each other. Scanning is the radar you leave running; the pentest is the stress test you schedule. When a business budgets for one and relabels it as the other, the risk doesn’t shrink. The discovery of the gap just gets deferred, either to your assessor, which is uncomfortable, or to your attacker, which is considerably worse.

Cianaa’s independent assessors review scanning programmes and penetration test reports across PCI DSS, SOC 2 and ISO 27001 engagements, and our PCI-aligned penetration testing is delivered against the methodologies above, with retest included.

References

Written by

Mehar un Nisa

Mehar un Nisa is Cianaa's Head of Middle East and an ISO/IEC 27001 Lead Auditor, delivering PCI, ISO and assurance engagements with banks, fintechs and government entities across the GCC.

Meet the team →

PCI DSS assurance