What PCI-DSS v4.0 Actually Requires for Vulnerability Scanning
PCI-DSS v4.0 contains two distinct scanning requirements under Requirement 11.3. Most blog posts get this wrong or collapse them into one. They are not the same thing, and you need both.
Must be performed at least once every three months, and after any significant change to the environment. Does not require an Approved Scanning Vendor (ASV) — must be performed by a qualified internal or external resource. All high-risk and critical vulnerabilities must be resolved and a rescan performed to confirm remediation.
Must be performed at least once every three months, and after significant changes to external-facing systems. Must be performed by a PCI SSC Approved Scanning Vendor. Passing results must show no high-risk vulnerabilities on internet-facing systems.
The key distinction most people miss: passing your external ASV scan does not satisfy your internal scan obligation, and vice versa. You need both, every quarter.
What Counts as "In Scope"?
This is where small businesses most often get caught. Scope is not just the device that processes the card. The cardholder data environment (CDE) includes:
- Systems that store, process, or transmit cardholder data
- Systems that can connect to or affect the security of those systems
- Network segments not properly isolated from the above
If your card terminal shares a network with your office Wi-Fi, your entire office network may be in scope unless you have documented, tested segmentation controls. This surprises almost every small business going through PCI for the first time.
Why Businesses Fail Their ASV Scan
Most ASV scan failures fall into four categories, all of which are preventable with the right preparation:
- Unpatched systems with known CVEs. External-facing servers running outdated software with published vulnerabilities. The ASV scanner will flag these as high-risk and fail the scan automatically. There are no exceptions for legacy systems or "we'll fix it next quarter."
- Misconfigured services. Open ports that should be closed, SSL/TLS running on deprecated versions (TLS 1.0 or 1.1 still fail PCI scans), weak cipher suites, self-signed certificates, or unnecessary services exposed to the internet.
- Scope creep. Systems not included in the scope assessment that are detected by the ASV scanner because they share IP ranges with in-scope systems. Shadow IT, forgotten subdomains, and cloud instances left running from old projects show up here constantly.
- No pre-scan baseline. Companies that have never run any vulnerability scan before their first ASV engagement are flying blind. The ASV does not prepare you — they report what they find. If you have not seen your own exposure first, the results will be a surprise.
The Pre-ASV Readiness Process
A pre-ASV readiness check is an internal exercise that mimics what the ASV will see from the outside, before they run their official scan. Here is what a thorough readiness process covers:
Step 1 Scope Confirmation
Before any scanning begins, define exactly what is in scope. Document every IP address, domain, and system that stores, processes, or transmits cardholder data, or that could affect the security of those systems. Confirm that out-of-scope systems are genuinely isolated and that isolation is documented.
Step 2 External Attack Surface Mapping
Identify every internet-facing asset associated with your organisation — not just the ones you think are relevant. Shadow IT, forgotten subdomains, and cloud instances from old projects are frequent surprises that appear in official ASV scans.
Step 3 External Vulnerability Scan
Run an external vulnerability scan against your in-scope internet-facing systems using PCI SSC-reviewed tooling. This produces a prioritised findings report showing exactly what an ASV will flag, before they do. We offer this complimentary for up to 2 public-facing IPs.
Step 4 Findings Remediation
Prioritised remediation guidance for every finding, categorised by severity. Critical and high-risk items are the ones that will fail your ASV scan — these are addressed first. Medium and low findings are documented for your records.
Step 5 Internal Vulnerability Scan (Req. 11.3.1)
Run the internal scan against your CDE. This satisfies Requirement 11.3.1 and also catches internal vulnerabilities that could affect your external security posture. Using PCI SSC-reviewed scanning tooling carries weight with QSAs when they review your evidence.
Step 6 Rescan to Confirm Remediation
After remediation, a follow-up scan confirms that all critical and high-risk findings have been resolved. At this point, your environment is ready for the official ASV scan.
Step 7 ASV Referral
Once your environment is clean and documented, referral to a PCI SSC-listed ASV for the official external scan and attestation. At this stage, passing the first time is the expectation, not the goal.
What the Internal Scan Covers
Requirement 11.3.1 requires quarterly internal scans. In practice this means:
- Scanning all in-scope systems from inside the network — servers, workstations, network devices, cloud instances within the CDE
- Identifying vulnerabilities by CVE, severity, and affected component
- Producing a findings report documenting what was found and what was remediated
- Rescanning after remediation to confirm resolution of high and critical findings
- Retaining scan results as evidence for your QSA or self-assessment questionnaire
The internal scan is also the right moment to validate segmentation controls. PCI-DSS v4.0 Requirement 11.4.5 now formally requires that segmentation testing be performed annually. If you claim systems are out of scope because they are isolated from the CDE, that isolation must be tested and documented — not assumed.
PCI-DSS Scanning Requirements: Quick Reference
| Requirement | Frequency | ASV Required? | Who Can Perform? |
|---|---|---|---|
| 11.3.1 Internal scan | Quarterly + after major changes | No | Qualified resource |
| 11.3.2 External scan | Quarterly + after major changes | Yes | PCI SSC-listed ASV |
| 11.4.1 Penetration test | Annual + after major changes | No | Qualified, independent tester |
| 11.4.5 Segmentation test | Annual + after major changes | No | Qualified, independent tester |
Ready to Pass Your ASV Scan the First Time?
We offer a complimentary external vulnerability scan of up to 2 public-facing IPs — delivered within 5 business days, with a prioritised findings report. No commitment required.
Claim Your Free ScanUp to 2 IPs. Findings report included. No obligation.
Common Objections
"We're a small company — do we really need all this?" If you accept card payments, you are contractually obligated to your payment processor to maintain PCI compliance, regardless of size. The question is not whether you need it — it is whether you find out about the gaps before or after an incident.
"Can't we just fill out the SAQ ourselves?" A Self-Assessment Questionnaire is a declaration. It does not replace the technical scanning requirements. Requirements 11.3.1 and 11.3.2 apply regardless of which SAQ type you complete.
"Our payment processor handles all of that." Your payment processor handles the transaction security on their side. Your responsibility is the systems and network on your side: the point-of-sale device, the network it sits on, and the systems that connect to it.
"We already have antivirus and a firewall." Antivirus and firewalls are preventive controls. PCI-DSS vulnerability scanning is a detective control — it finds what got through or was misconfigured despite those controls being in place. Both are required. Learn more about our vulnerability scanning services.
Accounting firms and professional services practices that accept card payments face these same PCI-DSS obligations alongside their software-specific security requirements. Our guide to securing QuickBooks Online covers how PCI-DSS and FTC Safeguards requirements overlap for small firms. If your firm uses Microsoft 365, our M365 security guide covers the email and access control layer that sits above your payment environment.