PCI Compliance for PayPal Merchants: Full SAQ Guide 2026
PCI compliance for PayPal merchants explained: which SAQ you need, when ASV scans apply, and how the 2026 PCI DSS v4.0.1 rules changed eligibility.
PCI vulnerability scanning fails on the first attempt more often because of preparation gaps than actual vulnerabilities. Scope left incomplete, a WAF rate limit that mistakes the scan for an attack, and a hosting provider that was never looped in; these are failures that have nothing to do with your security posture and everything to do with how the scan window was set up.
PCI vulnerability scanning mandates that all external-facing IPs, FQDNs, and CDE-adjacent systems are submitted to your ASV before scanning begins. Temporarily adjust dynamic protection systems, IPS, rate-limited WAFs, and volume-based shun rules that would block scan traffic and trigger an inconclusive result. Coordinate with your hosting provider for externally hosted components. Correct preparation eliminates the most common causes of first-time scan failure under PCI DSS 4.0.1 Requirement 11.3.2.
This guide covers exactly what needs to happen before the scan starts so you pass the first time.
CDE (Cardholder Data Environment): the systems and network segments that store, process, or transmit cardholder data, and the anchor for defining your scan scope.
Scan scope: every external-facing IP, IP range, FQDN, and domain alias tied to the CDE that must be submitted to your ASV before scanning.
Inconclusive scan: a scan result where active protection systems blocked or distorted scan traffic; under ASV Program Guide Section 7.6, an unresolved inconclusive scan is reported as a failed scan.
Scan interference: any dynamic defence (IPS, rate-limited WAF, or volume-based shunning) that blocks scan traffic mid-scan and needs temporary adjustment.
ASV Program Guide: the PCI SSC document governing how Approved Scanning Vendors must run scans, handle interference, and resolve disputes.
PCI vulnerability scanning is external ASV scanning, a PCI SSC-listed vendor probing your Internet-facing infrastructure for known vulnerabilities, required under Requirement 11.3.2 for any merchant or service provider with an Internet-facing CDE.
PCI vulnerability scanning, specifically external ASV scanning, is the process of having an approved PCI SSC-listed scanning vendor probe your Internet-facing infrastructure for known vulnerabilities and misconfigurations. It’s mandated under PCI DSS 4.0.1 Requirement 11.3.2 for any merchant or service provider with an Internet-facing cardholder data environment (CDE).
The short version: if external-facing systems touch or provide a path to your CDE, they must be scanned, at minimum every 90 days, and a passing certificate issued by a PCI SSC-listed ASV is what your acquirer accepts as evidence.
Preparing that infrastructure correctly isn’t optional. An unprepared environment is the single most common reason scans return inconclusive or fail on the first run.
In your first 12 months of assessment, you don’t need four passing scans on record; one passing scan plus documented scanning policies and corrected vulnerabilities is enough. From year two, four passing scans are a hard requirement.
PCI SSC-listed, starts at $80/year for a single IP, unlimited rescans, pass certificate within 24 hours. No enterprise complexity. No surprise costs.
You, not the ASV, are responsible for defining scope; submit every external-facing IP, FQDN, hidden directory, domain alias, and virtual host tied to the CDE before the scan starts.
The scanning customer, that’s you is responsible for defining scope. The ASV scans what you tell them to scan. If a compromised IP isn’t in scope and an attacker gets in through it, liability sits with you, not the ASV.
Per the ASV Program Guide, your scope submission must include:
The most common scoping mistake: submitting only the primary domain and forgetting subdomains, staging environments left publicly accessible, or mail server IPs that don’t immediately appear in a standard DNS lookup. The ASV will perform forward/reverse DNS lookups on common hostnames; www, mail, ftp; and flag any components they find that you didn’t provide. Better to include them yourself upfront.
ASV scans generate high-volume traffic that routinely trips IPS, rate-limited WAFs, and volume-based firewall rules; these need temporary adjustment to monitor-only mode, or the scan returns inconclusive (and inconclusive is reported as failed).
This is where most first-time scan failures originate. ASV scans are high-volume by design; they generate a lot of traffic quickly to complete efficiently. That behaviour routinely triggers active protection systems (IPS, WAF with rate limits, volume-based firewall rules) that were built to detect exactly that pattern. The result is an inconclusive scan. Under ASV Program Guide Section 7.6, an unresolved inconclusive scan must be reported as a failed scan.
System Type | Interference Risk | Action Required |
|---|---|---|
IPS dropping traffic from IP after port-scan detection | High | Temporarily set to monitor/log only for the scan window. |
WAF blocking IPs after request-rate threshold | High | Configure to allow non-attack traffic from the ASV source. |
Spam filters blacklisting IPs after SMTP probing | Medium | Exclude the ASV IP range from automated blacklisting. |
QoS devices throttling traffic on volume anomalies | Medium | Temporarily lift thresholds during the scan window. |
Network controls shunning IPs after detected port scan | High | Disable shunning for scan duration. |
Static firewall rules, standard IDS (log-only mode), antivirus, VPN credential rejection, and application-layer WAF rules that block SQL injection but let other traffic through; these don’t interfere with the scan and don’t require modification.
Critical nuance: Temporary configuration changes do not mean whitelisting the ASV or giving it elevated access. The intent is that the ASV sees the same network view an attacker would see, but without being dynamically blocked mid-scan. You’re not opening anything new; you’re preventing automated defences from distorting the scan result.
If any part of your CDE sits with a hosting provider or CDN, that provider's protections can interfere too, confirm upfront whether they'll supply their own passing scan evidence or be included directly in your scan scope.
If any part of your CDE sits with a hosting provider, cloud host, or ISP, that provider’s active protection systems can also interfere. The ASV Program Guide is explicit: you must coordinate with your provider to allow the scan to complete.
Two options exist for hosted environments:
If you’re on shared hosting or a multi-tenant environment, confirm with your provider which option applies before scheduling your scan. Don’t assume they’ve handled it. If you’re behind a CDN or edge network like Cloudflare, see our dedicated guide on Cloudflare PCI compliance and ASV scanning for how that coordination works in practice.
Load balancers can route scan packets to different backend servers and create an incomplete picture, disclose them to your ASV upfront, and include every Internet-facing virtual component in scope.
Load balancers present a specific issue: if an ASV scan is distributed across load-balanced nodes sequentially, different scan packets may reach different backend servers. This can cause an incomplete picture of the environment. The scan customer is responsible for coordinating with the ASV so the load balancer configuration is understood and accounted for before scanning starts. Disclose load balancers in your pre-scan communication.
For virtualised environments; virtual machines, hypervisors, virtual appliances; each Internet-facing virtual component that connects to or provides a path into the CDE must be included in scope. Virtual hosts aren’t exempt from Requirement 11.3.2.
Run the scan during a tracked change-control window with full monitoring active and a rollback plan ready, and keep temporary configuration changes in place only as long as the scan requires.
There’s no regulatory requirement to schedule scans during off-hours, but it’s best practice. ASV scans should be conducted:
The temporary configuration changes needed to remove interference should be in place only for the duration of the scan. The shorter that window, the lower your exposure.
Confirm scope, temporary config adjustments, hosting coordination, load balancer disclosure, and your maintenance window are all in place before the scan starts.
A failed scan starts remediation, not a penalty process; fix the flagged vulnerabilities and request a rescan; if the result was inconclusive due to interference, resolve it under ASV Program Guide Section 7.6 instead.
A failing scan isn’t the end of the process; it’s the start of remediation. Under PCI DSS 4.0.1, the process is straightforward: fix the vulnerabilities flagged in the scan report, then request a rescan. With Secusy ASV, unlimited rescans are included in every package. There are no additional charges when remediation takes more than one attempt; which it often does. Fix the issue, request a rescan, and the process continues until a passing certificate is issued.
If a scan is inconclusive rather than failing (because of interference), the ASV and scan customer work together under Section 7.6 of the ASV Program Guide to resolve the issue; whether through a new scan after config changes, written evidence that no blocking occurred, or an agreed alternative method.
Every 90 days from your last passing scan, plus any additional scan triggered by a significant environment change under Requirement 11.3.2.1.
Every 90 days from your last passing scan. That’s the 90-day window established under PCI DSS 4.0.1 Requirement 11.3.2; not calendar quarters. If you pass on 15 March, your next scan must pass by 13 June. Additional scans are required after significant changes to your environment under Requirement 11.3.2.1. New public-facing infrastructure, major server changes, or CDE expansion all trigger an out-of-cycle scan requirement.
Preparation is what separates a routine quarterly scan from a stalled compliance cycle. Define your scope precisely, adjust, don’t disable your active protections, loop in your hosting provider, disclose your load balancers, and run it all inside a tracked maintenance window. Do that consistently, and PCI vulnerability scanning stops being a source of first-time failures and becomes a predictable 90-day routine.
Preparation takes less time than dealing with a failed scan. Get your scope defined, your active protections adjusted, and your hosting provider aligned; then book your scan.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.