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.
A false-positive PCI ASV scan finding is one of the most common and most misunderstood obstacles in PCI compliance. Your scan comes back with a “critical” vulnerability on a port you don’t expose to the internet, or a CVE that was patched months ago but the scanner still reads the old version banner. You know it’s wrong. The scanner doesn’t. And left unresolved, that single inaccurate finding can block your AOSC just as effectively as a genuine vulnerability would.
Automated vulnerability scanners, by design, cast a wide net. They detect indicators such as version numbers, open ports, service banners, and flag anything that pattern-matches a known vulnerability. When your underlying configuration, patching, or compensating controls mean that vulnerability cannot actually be exploited in your environment, the result is a false positive: a finding that looks serious on paper but doesn’t reflect your real risk posture.
The good news: PCI SSC guidance requires every Approved Scanning Vendor to support a formal dispute process for exactly this situation. This guide walks through what qualifies as a genuine false positive, how the ASV false positive dispute process actually works, what evidence gets disputes approved, when a dispute is the wrong tool, and how to stop the same finding from resurfacing every quarter.
False Positive: A vulnerability finding generated by an automated ASV scan that does not represent a genuine, exploitable security risk in the scanned environment, typically arising because compensating controls, patching, or configuration differences prevent the vulnerability from applying.
Approved Scanning Vendor (ASV): A company qualified by the PCI Security Standards Council to conduct external vulnerability scans of internet-facing systems in scope for PCI DSS and to issue official scan reports accepted by acquirers and payment brands.
Dispute (ASV Context): The formal process defined by PCI SSC guidelines through which an organisation challenges a scan finding believed to be a false positive, supported by documented technical evidence.
Compensating Control: An alternative security measure that achieves an equivalent level of risk mitigation to a PCI DSS requirement, recognised where the standard requirement can't be directly met for a legitimate technical or business reason.
Vulnerability Scan Exception: A formal acknowledgement that a flagged vulnerability is real but cannot be immediately remediated, handled through documented compensating controls rather than a dispute.
A finding qualifies as a false positive when the scanner's detection logic doesn't match the real state of your system, not simply when you disagree with the severity or don't want to fix it.
False positives typically arise from a handful of well-understood detection gaps:
What does not qualify as a false positive: a real vulnerability you plan to fix later, a finding you consider “low risk”, or a vulnerability on a system slated for decommissioning. Those need a documented remediation plan or exception, not a dispute. If you’re still validating your scan scope before this stage, our guide on what’s included in a PCI ASV scan is a useful starting point.
Get your false positive PCI ASV scan finding reviewed and reversed with proper documentation support.
You submit the finding, your evidence, and a technical explanation to your ASV before the scan cycle closes; the ASV independently reviews it against PCI DSS requirements and either amends the report, adds a note, or upholds the finding.
The PCI SSC requires every qualified ASV to support this process, and it’s a defined procedure with specific documentation requirements and review stages, not an informal email exchange. In general, it follows six steps:
If the finding is accepted, the ASV issues a revised report reclassifying it, and your overall scan status updates accordingly. If it’s rejected, the ASV is required to provide a documented rationale, and you can strengthen your evidence and resubmit. Related reading: How to pass a PCI ASV scan the first time.
Evidence that lets your ASV independently confirm the vulnerability doesn't provide verifiable proof, not assertions about your general security posture.
Documentation that supports a successful dispute typically falls into four categories:
Each piece of evidence should be labelled with the CVE it relates to, timestamped, and sourced from official or verifiable channels. What consistently fails: anecdotal statements (“we already fixed this”), unlabeled screenshots, or a support ticket number with no attached proof.
PCI DSS false positive documentation must be precise and directly responsive to the exact finding flagged; general security documentation, without a clear link to the specific CVE and affected component, won't satisfy the review standard.
The evidence you submit needs to prove that this specific finding, as identified in the scan, doesn’t represent an actual vulnerability in this specific environment, not that your organisation is broadly secure. A well-structured submission package includes:
Once resolved, retain the full dispute package, your submission, the ASV’s correspondence, and the final reclassification as part of your PCI DSS compliance records. Acquirers and QSAs may request this evidence trail during their own reviews. If you’re building out your broader scan cadence, see our guide on ASV scan frequency and how often to scan.
Not every problematic finding is a false positive; genuine vulnerabilities that can't be immediately remediated need a documented exception or compensating control, not a dispute.
A dispute asserts the scanner is wrong about whether the vulnerability exists. An exception acknowledges the vulnerability is real but argues the risk is mitigated through alternative means or that remediation is already scheduled. Conflating the two is a common first-time mistake, and pursuing a dispute for a genuine vulnerability will simply fail and delay your compliance timeline further.
Exceptions are typically the right path for:
For genuine exceptions, work with your QSA to document the compensating control within your compliance program. Some acquiring banks require explicit sign-off, and the documentation standard is comparably rigorous to a dispute. If you’re unsure which category a finding falls into, our breakdown of what happens when your ASV scan fails covers the decision points in more detail.
Have our team walk through your flagged vulnerability before you decide whether to dispute or remediate.
Most disputes resolve within a few business days to three weeks; the single biggest factor is the completeness of your initial submission, not the complexity of the finding itself.
Incomplete or poorly organised dispute packages force your ASV to go back and request clarification or additional evidence, and each exchange adds days or weeks to the clock. Complete, clearly labelled, technically precise submissions let the reviewing team move directly to assessment.
Once submitted, your ASV conducts an internal review, often including targeted re-testing of the specific component in question. If the evidence holds up, they issue a revised report reclassifying the finding; if it was your only failing item, your overall scan result updates to passing. While a dispute is in progress, keep your acquiring bank or payment facilitator informed. Most acquirers accept documentation of a pending dispute as part of a compliance timeline explanation, and proactive communication signals that you’re managing the situation, not ignoring it.
Fix the root detection issue once, update service banners, standardise configurations, or get a verified control whitelisted, instead of re-disputing the same finding every scan cycle.
A false positive PCI ASV scan finding is a solvable problem, but PCI DSS doesn’t accept “trust me” as a dispute. Every successful challenge is built on evidence your ASV can independently verify, patch confirmations, configuration exports, or vendor advisories, submitted through the proper channel before your scan cycle closes. Know your finding, understand the specific CVE, correctly separate disputes from exceptions, and submit a clearly organised package that leaves no ambiguity about what you’re asserting and why.
Choosing an ASV that treats dispute support as a core part of the service, not an afterthought, makes a measurable difference in how quickly your compliance status is restored.
See how Secusy ASV scanning documents evidence automatically to cut down on recurring false positives.
A vulnerability flagged by the scanner that doesn't represent a genuine, exploitable risk in your specific environment, often caused by backported patches, compensating controls, or configuration differences the scanner can't see.
Compile technical evidence, vendor patch documentation, configuration exports, or network diagrams, and submit a formal dispute through your ASV's dedicated form or portal, referencing the CVE and scan date.
Typically a few business days to three weeks. Complete, well-labeled submissions resolve fastest; incomplete evidence packages are the main cause of delay.
Vendor patch confirmations, configuration exports, firewall/network diagrams, and compensating control documentation, each labelled by CVE and sourced from verifiable, official channels.
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.