Vulnerability Scans vs Penetration Tests – What Each Finds and When Each Is Required

Updated: 1 October 2026

What is the difference between a vulnerability scan and a penetration test? A vulnerability scan is an automated process that identifies known weaknesses in systems – open ports, outdated software versions with published CVEs, misconfigured services. A scan says: “This Apache 2.4.51 server has CVE-2021-41773 with CVSS 9.8.”

A penetration test is a manual, expert-led attack on systems that verifies whether vulnerabilities are actually exploitable and what the real-world impact would be: “Through CVE-2021-41773 we gained server access, then pivoted to the cardholder database in 20 minutes – here is the documented proof.” PCI DSS v4.0.1 requires both: quarterly scans (Requirement 11.3) and an annual penetration test (11.4.2). ISO 27001 Annex A Control 8.8 requires management of technical vulnerabilities. NIS2 Article 21 requires security testing as a proportionate risk management measure.

Vulnerability scans vs penetration testing – at a glance:

1. Vulnerability scan: automated, lower cost, high frequency (quarterly or continuous), identifies KNOWN vulnerabilities from CVE databases – does not verify whether a vulnerability is actually exploitable in your specific environment
2. Penetration test: manual, higher cost, lower frequency (annually or after significant changes), verifies whether vulnerabilities are exploitable and what the impact of a successful attack would be – delivers intelligence that no scan can provide
3. PCI DSS 11.3.1: internal vulnerability scans quarterly; from 31 March 2025, scans must be authenticated (11.3.1.2) – an unauthenticated scan does not satisfy the requirement and will result in a QSA finding
4. PCI DSS 11.3.2: external scans conducted by an ASV (Approved Scanning Vendor) from the PCI SSC list, quarterly – an external scan from an arbitrary tool or provider does not meet this requirement
5. PCI DSS 11.4.1 (mandatory from 31 March 2025): the penetration testing methodology must be documented BEFORE the test – a report without a pre-defined documented methodology is a QSA finding
6. Patronusec, as an accredited QSA with an in-house penetration testing team (OSCP, CREST), delivers authenticated internal scans, ASV external scans, and penetration tests with methodology meeting PCI DSS 11.4.1 – all reports written with the QSA’s perspective in mind

---

---

What does a vulnerability scan find – and what will it never detect?

A scan detects:

• Known CVEs in software based on version fingerprinting and signatures
• Open ports and services that should not be externally reachable
• Outdated software versions with deprecated protocol support (TLS 1.0, TLS 1.1, SSL)
• Default or weak passwords for standard services (authenticated scans only)
• Automatically detectable misconfigurations such as anonymous FTP access

A scan will never detect:

• Business logic flaws – errors in application logic specific to your code base
• Vulnerability chaining – for example, a low-severity CVE combined with a misconfiguration and a default credential resulting in full system compromise
• Vulnerabilities in custom code with no CVE signature (SQL injection, XSS in your application)
• Social engineering and phishing as initial access vectors
• Lateral movement pathways – how an attacker would move between systems after initial access

Authenticated versus unauthenticated scans – the critical distinction:

What is detected	Unauthenticated scan	Authenticated scan
Open ports and externally visible services	✅	✅
Software versions visible from the network	✅	✅
Local software versions not visible from the network	❌	✅
Operating system patch status	❌	✅
Local account configuration and password policies	❌	✅
Vulnerabilities in internal services	❌	✅

The authenticated scan requirement (PCI DSS 11.3.1.2 from 31 March 2025) is not bureaucratic box-ticking – an authenticated scan typically identifies two to three times as many vulnerabilities as an unauthenticated scan on the same host. Running unauthenticated scans and calling them “internal scans” is a PCI DSS finding.

Patronusec Insight: Organisations who come to us after a failed PCI DSS assessment frequently share the same scenario: internal scans were being run without authentication. The results showed 40 to 50 low-severity findings and zero critical ones. The QSA reviewed the scanner configuration, identified the absence of credentials, and issued a finding. From 31 March 2025, an unauthenticated internal scan is a nonconformity with Requirement 11.3.1.2. In our vulnerability scanning service, we configure credentials for every host in scope and provide the scanner configuration as documentary evidence for the QSA.

---

Not sure whether your internal scans are authenticated and whether they satisfy PCI DSS 11.3.1.2?

Patronusec conducts a scan programme review – within 5 working days we assess whether your current scanning configuration generates evidence acceptable for a QSA assessment.

Book a scan programme review

---

How do you build a minimum-compliant vulnerability scanning programme for PCI DSS v4.0.1?

A PCI DSS scanning programme requires four elements:

1. External ASV scan (Requirement 11.3.2):

• Who: an Approved Scanning Vendor from the PCI SSC list (pcisecuritystandards.org)
• When: at minimum quarterly, and after any change to external-facing infrastructure in the CDE
• What: all external IP addresses in and connected to the CDE
• Acceptable result: “Passing” – zero Critical or High findings after remediation

2. Authenticated internal scan (Requirements 11.3.1 and 11.3.1.2 from 31 March 2025):

• Who: qualified internal personnel or an external partner (does not need to be an ASV)
• When: at minimum quarterly, and after any significant change to CDE infrastructure
• Authentication: the scanner must authenticate to each scanned host
• Evidence for QSA: scanner configuration with credentials, plus scan results

3. Annual penetration test (Requirements 11.4.2 and 11.4.1 from 31 March 2025):

• Methodology: must be documented BEFORE the test – not merely described in the final report
• Scope: both network layer and application layer, covering the CDE and segmentation testing
• Tester: organisational independence and documented competence required
• Report: must include the documented methodology, evidence of manual testing, and exploitation proof

4. Segmentation testing (Requirement 11.4.4):

• At minimum annually, and after any change to CDE segmentation
• Technical verification that traffic between CDE and non-CDE segments is actually blocked – not merely documented as blocked

When does TLPT (Threat-Led Penetration Testing) apply under DORA?

DORA Article 26 requires Threat-Led Penetration Testing (TLPT) for significant financial institutions at least once every 3 years. TLPT is fundamentally different from a standard penetration test:

Aspect	Standard penetration test	TLPT
Scope	Defined in advance	Based on threat intelligence specific to the institution
Approach	Vulnerability list	Simulation of an advanced persistent threat actor
Environment	May use test or staging systems	Production systems
Coordination	With internal IT teams	With sector regulator (EBA/ESMA/EIOPA)
Duration	1 to 4 weeks	3 to 6 months (preparation plus execution)

TLPT is delivered by accredited red team providers following the TIBER-EU framework or national equivalents. It is the most demanding and resource-intensive security test prescribed by EU regulation.

Patronusec Insight: Penetration test reports are among the most frequently rejected documents in PCI DSS assessments due to methodology deficiencies. Requirement 11.4.1 (mandatory from 31 March 2025) requires a documented methodology – what was tested, how it was tested, and which tools and techniques were used – not merely a list of findings. A tool-generated report with no description of manual testing, no exploitation evidence, and no mapping to a recognised methodology (PTES, OWASP Testing Guide) will be rejected by a rigorous QSA. Our penetration testing team, holding OSCP and CREST certifications, prepares reports specifically for QSA review – because we are both penetration testers and QSAs, and we know exactly what evidence an assessor requires.

FAQ – Vulnerability scanning vs penetration testing

---

Vulnerability scanning and penetration testing – free consultation

Patronusec, as an accredited QSA with an in-house penetration testing team (OSCP, CREST), delivers a complete security testing programme satisfying PCI DSS v4.0.1, DORA, and ISO 27001.

In a free 30-minute consultation we will help you:

• Assess whether your current scans are authenticated and satisfy PCI DSS 11.3.1.2
• Plan a full testing programme (scans, penetration test, segmentation testing) for the certification year
• Define a penetration testing methodology meeting Requirement 11.4.1 for your environment
• Quote for a combined ASV scans, internal scans, and penetration test package at preferential pricing

Free consultation | Penetration testing | Vulnerability scans | PCI DSS certification | vCISO