Two PCI DSS requirements get confused constantly, and the confusion causes real audit delays: Requirement 11.3 governs vulnerability scanning, and Requirement 11.4 governs penetration testing. They are not interchangeable, they are not substitutes for each other, and a QSA reviewing evidence for one will not accept documentation for the other. A quarterly ASV scan report satisfies 11.3. It does not satisfy 11.4, no matter how thorough the scan was.
This guide covers exactly what each requirement demands, what a QSA expects to see as evidence, and the specific failures that most commonly surface during a PCI DSS assessment involving 11.3 and 11.4.
Contents
1. Introduction & Context
PCI DSS 4.0 draws a firm line between two activities that organizations frequently conflate: scanning for known vulnerabilities and adversarially testing whether those vulnerabilities — and others no automated scanner would find — can actually be exploited. Requirement 11.3 covers the first. Requirement 11.4 covers the second. Both are mandatory for organizations in scope, both have their own cadence, and satisfying one does nothing toward satisfying the other in a QSA’s eyes.
This distinction matters most at assessment time, when an organization discovers that the evidence it assembled — often a folder of vulnerability scan reports — doesn’t answer what Requirement 11.4 actually asks for. This guide walks through what each requirement demands in specific, technical terms, what a QSA expects an evidence package to contain, and the failures that most commonly delay a PCI DSS assessment around these two requirements specifically.
2. Business Impact
A finding under Requirement 11.3 or 11.4 doesn’t just delay a report — it can affect PCI DSS certification status entirely, with downstream consequences for card processing eligibility. IBM’s Cost of a Data Breach Report 2026 places the average breach cost at $4.99M USD — the highest figure on record — and a breach reachable through a vulnerability that neither a scan nor a penetration test had actually confirmed is exactly the exposure these two requirements exist to close before an incident, not after.
| Compliance Gap | Business Consequence | Regulatory Exposure | Severity |
| Vulnerability scan submitted as evidence for Requirement 11.4 | QSA rejects the evidence as non-responsive to a penetration testing requirement | PCI DSS Req. 11.4 | HIGH |
| Undocumented or informal testing methodology | Cannot demonstrate the testing meets 11.4.1’s industry-accepted methodology requirement | PCI DSS Req. 11.4.1 | HIGH |
| Segmentation relied upon but never tested | Entire “out of scope” network treated as in-scope by the assessor, dramatically expanding audit scope | PCI DSS Req. 11.4.5 / 11.4.6 | CRITICAL |
| Critical findings identified but not retested after remediation | Assessor cannot confirm the fix actually closed the exploitable path | PCI DSS Req. 11.4.4 | HIGH |
| Internal testing performed by someone who administers the tested systems | Independence requirement not met — testing may need to be redone | PCI DSS Req. 11.4.2 | MEDIUM |
The segmentation row carries the largest downstream cost of the five: an organization that has been treating parts of its network as out of scope, based on segmentation controls that were never actually validated, can see its entire assessment scope expand the moment a QSA determines the segmentation claim isn’t supported by test evidence.
3. What Requirements 11.3 and 11.4 Actually Demand
3.1 Requirement 11.3: Vulnerability Scanning
Requirement 11.3 mandates automated vulnerability scanning on a quarterly cadence, in two distinct forms: internal scans (11.3.1), conducted from inside the network, and external scans (11.3.2), which must be performed by a PCI SSC Approved Scanning Vendor (ASV) — not just any scanning tool. Both must also be repeated after any significant change to infrastructure or applications, not only on the standard quarterly schedule. External ASV scans specifically must reach a documented “passing” result per the ASV Program Guide before the requirement is considered satisfied — an external scan that returns unresolved findings does not meet 11.3.2 until those findings are remediated and rescanned.
3.2 Requirement 11.4: Penetration Testing
Requirement 11.4 is structured around a documented methodology (11.4.1) that must be based on an industry-accepted approach — NIST SP 800-115, OWASP methodologies, and PTES are commonly cited references — and must cover the entire cardholder data environment perimeter and critical systems, both network-layer and application-layer testing, and explicit consideration of threats and vulnerabilities observed over the preceding 12 months. From that methodology, 11.4.2 requires internal penetration testing and 11.4.3 requires external penetration testing, each at least annually and after any significant change. Requirement 11.4.4 closes the loop: exploitable findings must be remediated and the fix specifically retested, not just noted as resolved.
3.3 Segmentation Testing
Segmentation testing only applies to organizations that rely on network segmentation to reduce PCI DSS assessment scope — but for those that do, it is not optional. Requirement 11.4.5 requires merchants to test their segmentation controls at least annually; Requirement 11.4.6 requires service providers to test theirs at least every six months. The testing itself has to demonstrate the segmentation actually works in both directions: that systems outside the defined scope cannot reach the cardholder data environment, and that a compromise inside the CDE couldn’t reach back out to affect out-of-scope systems. A firewall rule set that looks correct on paper is not evidence of this — only a test that actually attempts the traffic is.
3.4 What QSAs Expect: Evidence Checklist
- A documented penetration testing methodology referencing an industry-accepted approach, not an informal or undocumented process
- Separate, dated reports for internal and external penetration testing, each within the required 12-month window
- Evidence the test considered threats and vulnerabilities from the preceding 12 months, not a generic checklist run
- Segmentation test results, if segmentation is used to reduce scope, at the correct cadence for the organization’s role
- Documented remediation and retest evidence for every exploitable finding, not just a findings list
- Confirmation of tester independence, particularly for internal testing performed by staff rather than a third party
3.5 Common Failures
The single most frequent failure is submitting 11.3 scan evidence against an 11.4 penetration testing question — the two requirements test genuinely different things, and no amount of scan thoroughness substitutes for adversarial testing. The second most common is claiming a scope reduction through segmentation with no corresponding segmentation test on file, which a QSA will not accept on documentation alone. The third is testing performed, findings identified, and no evidence that anything critical was retested after remediation — leaving the assessor unable to confirm the fix actually worked.
4. Proactive Detection with the Teisoft Exposure Platform
The Teisoft Exposure Platform supports the Requirement 11.3 side of this pairing directly, with continuous External Asset Discovery and Risk-Based Vulnerability Management maintaining an accurate, current view of the environment’s exposed footprint between formal ASV scan cycles, and Automated Exposure Validation (AEV) confirming which findings are genuinely exploitable before they reach the remediation and retest workflow Requirement 11.4.4 requires evidence of.
4.1 What Continuous Monitoring Adds Between Formal Cycles
- Coverage between quarterly ASV scans: New CVEs disclosed between formal scan cycles are still caught, rather than waiting for the next scheduled 11.3.2 scan.
- An accurate scope statement for 11.4 engagements: Continuous discovery keeps the documented CDE perimeter current, so an annual penetration test starts from a scope that actually reflects the environment.
- A remediation and retest trail: Findings from either scanning or penetration testing are tracked through to confirmed resolution, supporting the documentation Requirement 11.4.4 asks a QSA to review.
| → Run your free External Attack Surface Scan |
| teisoftllc.com/free-vulnerability-scan/ — find out in minutes whether your externally discovered assets have findings your QSA would expect to see documented and remediated. |
5. Step-by-Step: Building a QSA-Ready Evidence Package
The following five-step process assembles evidence that answers what a QSA actually reviews for Requirements 11.3 and 11.4.
Step 1: Separate Your 11.3 and 11.4 Evidence Explicitly
Label evidence folders and reports by which specific requirement they satisfy. A scan report filed under “penetration testing” is exactly the confusion that leads to a rejected evidence submission.
Step 2: Confirm Methodology Documentation Exists and Is Current
Requirement 11.4.1 asks for a documented methodology, not just a report from a firm that presumably has one. Obtain and retain the actual methodology reference, confirming it covers network and application layers and the full CDE perimeter.
Step 3: Schedule Internal, External, and Segmentation Testing on Their Correct Cadences
Internal and external penetration testing: annually and after significant change. Segmentation testing, if applicable: annually for merchants, every six months for service providers. Track these as separate calendar items — they don’t share a single deadline.
Step 4: Document Remediation and Schedule Retests
For every exploitable finding, record the remediation action taken and schedule a retest specifically confirming the fix closed the path. A findings list with no closure evidence is the single most common gap a QSA flags under 11.4.4.
Step 5: Confirm Tester Independence and Retain It in Writing
For any internal testing performed by staff rather than a third party, document that the tester holds no administrative responsibility over the systems tested. This single line of documentation resolves a question a QSA would otherwise have to ask.
Evidence Package: Before / After
| Element | State Before | State After | Improvement |
| Evidence organization | Scan and pentest reports mixed together | Explicitly separated and labeled by requirement | No requirement confusion at review |
| Methodology documentation | Assumed to exist, not on file | Retained and referenced directly | 11.4.1 satisfied with evidence |
| Segmentation validation | Claimed but untested | Tested at the correct cadence, results on file | Scope reduction defensible |
| Remediation trail | Findings list with no closure evidence | Documented remediation and retest per finding | 11.4.4 satisfied with evidence |
6. Frequently Asked Questions (FAQ)
Q: Can our quarterly ASV vulnerability scan satisfy Requirement 11.4’s penetration testing obligation?
No. Requirement 11.3 and Requirement 11.4 are separate obligations that test different things — a vulnerability scan enumerates known weaknesses against a signature database, while a penetration test exploits and chains findings the way an attacker actually would. A QSA reviewing evidence for 11.4 and receiving only ASV scan reports will raise it as a gap, not treat the scan as a substitute.
Q: If we don’t segment our network, does Requirement 11.4.5 still apply to us?
No — segmentation testing only applies if an organization is relying on network segmentation to reduce PCI DSS scope. If the entire environment is treated as in-scope, there’s no segmentation boundary to validate. The moment segmentation is used to exclude systems from scope, though, testing that segmentation becomes mandatory, not optional.
Q: How often does penetration testing actually need to happen under Requirement 11.4?
At least once every 12 months, and additionally after any significant change to infrastructure or applications. Segmentation testing has its own separate cadence — at least annually for merchants, and at least every six months for service providers relying on segmentation.
Q: What specifically makes a penetration testing methodology ‘industry-accepted’ for Requirement 11.4.1?
PCI DSS points to established frameworks such as NIST SP 800-115, OWASP’s testing methodologies, and PTES as acceptable references. What matters to a QSA is that the methodology is documented, covers both network and application layers, addresses the full CDE perimeter and critical systems, and explicitly considers threats and vulnerabilities observed in the prior 12 months — not that it cites one specific named framework.
Q: Do internal penetration tests need to come from an independent third party, the same as external testing?
PCI DSS allows qualified internal staff to conduct testing, provided they have the required skills and are organizationally independent of the systems being tested — someone testing a system they administer doesn’t meet that bar. Many organizations use a third party for both internal and external testing regardless, since it removes any question about independence during a QSA review.
7. Conclusion & Next Steps
- Requirement 11.3 (vulnerability scanning) and Requirement 11.4 (penetration testing) are separate, non-substitutable obligations under PCI DSS 4.0 — the single most common assessment failure around these requirements is submitting evidence for one against a question asking about the other.
- Segmentation testing under 11.4.5 and 11.4.6 only applies to organizations relying on segmentation to reduce scope, but for those organizations it is mandatory at a defined cadence — and untested segmentation claims are the compliance gap most likely to expand an assessment’s entire scope.
- The five-step process in this guide — separating evidence by requirement, confirming methodology documentation, scheduling each testing type on its correct cadence, documenting remediation and retests, and confirming tester independence — builds the specific evidence package a QSA reviews, rather than a generic security testing archive that happens to exist.
| → Primary CTA: External Attack Surface Scan (Free) |
| Run your free External Attack Surface Scan at teisoftllc.com/free-vulnerability-scan/ and find out in minutes whether your externally discovered assets have findings your QSA would expect to see documented and remediated. |
| → Secondary CTA: Compliance Penetration Testing |
| Teisoft’s Compliance Penetration Testing service delivers internal, external, and segmentation testing scoped specifically to Requirement 11.4’s methodology and evidence expectations, with remediation retest built into the engagement. Contact Teisoft |
Related Resources on teisoftllc.com
This guide pairs directly with our broader PCI DSS coverage — see the full PCI DSS compliance audit guide for the complete requirement mapping.
- PCI DSS Compliance Audit Guide for Web Applications
- Penetration Testing for Cyber Insurance: What Underwriters Require
- How to Read CVE Alerts: CVSS, Scope, and Priority
