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 failed ASV scan is not a compliance catastrophe; it is a structured signal that specific vulnerabilities or configuration gaps exist within your externally facing environment, and it comes with a defined, workable path to resolution. The PCI Security Standards Council built the ASV programme precisely to surface these issues before attackers do, and the framework includes formal mechanisms for remediation, dispute, and rescan that any organisation can navigate with the right guidance.
What makes a failed scan frustrating for most organisations is not the finding itself but the gap between receiving a dense technical report and knowing what to do next. Many IT managers and business owners open their scan results and are immediately confronted with CVE identifiers, CVSS scores, port lists, and vulnerability classifications that were never explained to them at the outset.
Without a clear framework for reading those results, it is genuinely difficult to distinguish a critical remediation task from a false positive that can be formally disputed, and that distinction has a direct bearing on how quickly you pass your rescan.
This article gives you that framework. We will walk through the ASV scan process from report delivery to rescan submission, explain the formal dispute mechanism for false positives and compensating controls, and lay out a prioritised remediation approach so you are spending effort where it counts.
Whether this is your first failed scan or a recurring issue your team has been wrestling with quarterly, the goal here is to make the path to a passing report clear, actionable, and achievable.
Approved Scanning Vendor (ASV): An organisation approved by the PCI Security Standards Council (PCI SSC) to conduct external vulnerability scans of internet-facing systems within a cardholder data environment, as required under PCI DSS Requirement 11.3.2.
CVSS (Common Vulnerability Scoring System): An industry-standard framework for rating the severity of security vulnerabilities on a scale from 0.0 to 10.0. PCI DSS requires that any finding scored 4.0 or above constitutes an automatic scan failure unless remediated or successfully disputed.
False Positive: A vulnerability finding reported by an ASV scan tool that does not represent a genuine exploitable weakness in the target environment, for example, a service version flagged as vulnerable when a patch has already been applied at the OS level without updating the banner.
Compensating Control: An alternative security measure accepted under PCI DSS when a merchant or service provider cannot meet a specific requirement as stated, but has implemented equivalent protection through other documented means, subject to formal review and approval.
The ASV scan is a structured, external vulnerability assessment of your internet-facing systems, following the PCI SSC ASV Programme Guide. Understanding each phase, scoping, scanning, report generation, and submission, is essential before you can effectively act on a failed result.
When your ASV initiates a scan, they are probing the external IP addresses and fully qualified domain names (FQDNs) that you have declared as in scope, meaning every internet-facing component of your cardholder data environment (CDE). This is not a passive inventory check.
The scanning engine actively tests those addresses for known vulnerabilities, open services, misconfigured protocols, expired certificates, and software versions with published CVEs. The output is a structured scan report that categorises every finding by severity and assigns a pass or fail status to the overall scan.
Under the PCI SSC ASV Programme Guide, a scan automatically fails if any finding carries a CVSS base score of 4.0 or higher on an in-scope component. It also fails under specific automatic failure conditions, regardless of CVSS score.
These include any active web application vulnerability identified during scanning, any evidence of malware on in-scope systems, and certain configurations, such as systems accessible via unencrypted protocols where encrypted alternatives should be in place. These automatic failure conditions are non-negotiable at the scanning level, though some may be addressed through the dispute process.
One of the most consequential decisions in the ASV scan process happens before the scan even begins: defining the scope. Many organisations inadvertently underscope their scan by omitting IP ranges associated with a DMZ, a cloud-hosted component, or a recently added payment integration. If an acquirer or QSA later identifies that in-scope systems were excluded, the passing report becomes invalid.
Equally, over-scoping can produce noise, findings on systems that genuinely fall outside your CDE. Working with a knowledgeable ASV partner to validate your scope declaration before each quarterly scan is one of the most effective ways to reduce failed rescans and scope disputes later.
The entire point of the ASV scan process is to give you a defensible, quarterly snapshot of your external attack surface. A failed scan, read correctly, tells you exactly where that surface is exposed. The next step is knowing how to read the report it generates.
An ASV scan report organises findings by severity, IP address, and CVE identifier. Reading it correctly means separating automatic-failure-level findings from informational findings, then triaging by CVSS score and system criticality before taking any remediation action.
Every PCI-compliant ASV scan report follows a structure defined by the PCI SSC’s ASV Programme Guide. At the highest level, the report will show an overall pass or fail status, a summary of findings by severity category, and a detailed breakdown of each vulnerability by IP address or FQDN.
The severity categories map directly to CVSS scores: findings above 4.0 are flagged as failures, while those below 4.0 are informational and do not by themselves cause a scan failure, though they still represent real exposure worth addressing.
For each failing finding, the report will typically include the CVE identifier (the publicly catalogued vulnerability reference), the CVSS base score, a description of the vulnerability, the affected port and service, and evidence collected during the scan, such as the banner string or version number that triggered the finding.
This evidence section is critical when you are evaluating whether a finding represents a genuine vulnerability or a false positive. If your server has been patched but is still reporting an old version string in its banner, that gap between what the scanner sees and what is actually installed is precisely the kind of discrepancy you can formalise as a dispute.
Not all failing findings represent equal risk, even if they all technically prevent a passing report. A reasonable triage approach is to begin with findings on systems that are directly involved in payment processing or cardholder data storage, these represent the highest risk and often the highest scrutiny from acquirers.
Next, address findings with CVSS scores of 7.0 or above, as these represent high or critical severity vulnerabilities where exploitation is more likely and more damaging. Lower-scoring failures in the 4.0–6.9 range can follow, along with any findings you intend to dispute.
The discipline of reading your report in this structured way, rather than treating it as an undifferentiated list of problems, is what separates organisations that clear their scan quickly from those that spend weeks thrashing through remediation without a clear outcome.
Effective ASV scan remediation means applying patches and configuration fixes in a deliberate sequence, starting with the highest-severity findings on in-scope payment systems, and verifying each fix before requesting a rescan, not simply applying changes and hoping the next scan passes.
Remediation after a failed ASV scan is not simply a patching exercise. It is a systematic process of closing the specific gaps the scanner identified in a way that will be verifiable when the ASV re-scans. That distinction matters because a common mistake is to apply a patch to an underlying system but leave a configuration, such as a version banner, an exposed service, or an open port, unchanged. The scanner will find the same evidence it found before and produce the same finding.
These are the most frequent cause of CVSS 4.0+ failures. For these, the remediation is straightforward in principle: apply the relevant vendor patch or upgrade to a supported version. In practice, patching a production payment system requires change management discipline, testing in a staging environment, scheduling a maintenance window, and confirming the patch is correctly applied before the rescan. Where a vendor patch does not yet exist for a known CVE, this becomes a compensating control scenario, which requires documentation and your ASV's formal review.
This represent another major failure category. Scanners will flag any service accessible from the internet that represents a known attack vector or is simply not required for the system's function. Remediation here means either closing the port at the firewall level, disabling the service entirely, or restricting access to specific trusted IPs if the service is legitimately required. Firewall rule changes need to be tested and verified; it is surprisingly common for a rule to be applied to one interface and not another, leaving the service still externally reachable.
They have become more prominent as PCI DSS requirements around deprecated protocols have tightened. If your scan flags the use of TLS 1.0 or 1.1, or weak cipher suites, the remediation is to reconfigure your web server or load balancer to enforce TLS 1.2 or 1.3 as a minimum and to disable the specific cypher suites identified. Most web server platforms, Apache, Nginx, and IIS, have well-documented configuration directives for this, and your ASV partner should be able to point you to current guidance specific to your stack.
Such as expired SSL certificates, misconfigured DNS records, or missing DNSSEC where required are often the most straightforward to remediate but are commonly overlooked because they do not feel like security vulnerabilities in the traditional sense. They are nonetheless findings that will prevent a passing report and should be addressed promptly as part of standard environment hygiene.
False positives in ASV scan results can be formally disputed through your ASV using the exception process defined in the PCI SSC ASV Programme Guide. A valid dispute requires documented evidence that the finding does not represent a genuine vulnerability in your specific environment.
The dispute mechanism is one of the most underused tools in the ASV compliance process, partly because many organisations do not know it exists and partly because they are unsure what constitutes a valid basis for dispute.
The PCI SSC’s framework recognises that automated scanning tools, by their nature, will sometimes produce findings that are technically accurate at the signature level but do not reflect a real exploitable vulnerability in the scanned environment.
The most common legitimate dispute scenarios include version-based false positives, where a scanner flags a software version as vulnerable, but the underlying CVE has been backport-patched by the vendor, and the version string no longer accurately reflects the actual patch level.
Linux distributions in particular routinely backport security fixes without incrementing the version number, which means a scanner reading the version string will produce a false positive for vulnerabilities that have already been addressed. Your dispute evidence in this case would be the vendor advisory confirming the backport, or the output of a package manager command showing the installed patch level.
Where a genuine vulnerability exists but cannot be remediated in the standard way, for instance, a legacy system that handles a specific payment function and cannot be patched because the vendor no longer supports it, a compensating control may be documented and submitted through your ASV.
A compensating control is not a way to ignore a vulnerability; it is a formal declaration that you have implemented an equivalent or stronger protection through other means, such as network segmentation that prevents the vulnerable system from being directly reachable from the internet. The compensating control must be reviewed and accepted by your ASV before the dispute is recorded as resolved.
To raise a dispute with your ASV, you will typically need to provide the specific finding reference from the scan report; a clear description of why the finding is a false positive or why a compensating control applies; supporting evidence such as vendor advisories, configuration outputs, or network diagrams; and a signed attestation confirming the accuracy of your submission.
A responsive ASV partner will review your evidence and, if accepted, will mark the finding as resolved in the report, allowing the overall scan to pass without requiring the underlying system to change. This is a legitimate, PCI SSC-sanctioned process, not a workaround.
Passing an ASV rescan requires that every finding that caused the original failure has either been remediated and verified or formally disputed and accepted by your ASV, and that the rescan is conducted against the same scope with the same in-scope IP addresses and domains.
The rescan is not simply a repeat of the original scan. It is a targeted verification that the specific conditions that caused failures have been resolved. Most ASVs will conduct a rescan within a defined timeframe after you notify them that remediation is complete, and the cost and scheduling of rescans should be confirmed with your ASV partner upfront.
At SecusyASV, rescans are handled as part of a straightforward, transparent process, so you are never left uncertain about what comes next.
Before requesting a rescan, conduct your own internal verification of every remediation action taken. This means confirming that patches are applied and active, that port and service changes are in effect across all relevant infrastructure, that SSL/TLS configuration changes are live on all relevant endpoints, and that any dispute documentation has been submitted and accepted by your ASV.
A rescan requested before all remediation is confirmed risks producing another failed report, which resets the clock and adds operational burden without advancing your compliance posture.
One of the most common causes of a failed rescan is a scope mismatch, where the remediation was applied to a system that was not the actual one scanned or where a load balancer or CDN is masking the underlying server that carries the finding.
Before each rescan, verify with your network or infrastructure team that the IPs being scanned are the actual systems where remediation was performed and that there is no intermediate layer presenting a different configuration to the scanner than what your team believes is in place.
Once your ASV issues a passing scan report, that report must be retained and submitted to your acquiring bank or payment processor as required under your compliance programme. PCI DSS requires quarterly scans, which means a passing report is valid for the quarter in which it was conducted, not indefinitely.
Build a proactive scanning calendar that schedules each quarterly scan with enough lead time to accommodate remediation and a rescan if needed so you are never approaching your compliance deadline with an unresolved failure.
All compliance requirements and procedural references are drawn from the PCI Security Standards Council's ASV Programme Guide and PCI DSS v4.0 documentation. Readers are encouraged to consult the PCI SSC's official publications at pcisecuritystandards.org for the most current version of all referenced requirements and scoring thresholds."
A failed ASV scan carries real urgency, but it is not an insurmountable obstacle. The PCI SSC designed the ASV programme with a built-in path from failure to resolution, through clear report structures, a defined remediation framework, a formal dispute process for false positives, and a rescan mechanism that lets you validate your fixes quickly.
What separates organisations that resolve failures efficiently from those that stay stuck in repeated failure cycles is not technical sophistication. It is the discipline to read their results carefully, prioritise remediation in the right sequence, engage the dispute process where it legitimately applies, and work with an ASV partner who provides clear guidance at every step.
The quarterly rhythm of ASV scanning is not just a compliance checkbox; it is one of the most reliable ways to maintain visibility into your external attack surface and catch exploitable vulnerabilities before they become breach incidents. Treat each failed scan as the detailed roadmap it is, and the path to a passing report is always shorter than it first appears.
A failed ASV scan under PCI DSS is a structured finding, not a compliance endpoint, with a defined resolution path that includes report analysis, prioritised remediation, formal dispute of false positives, and a verified rescan. Organisations that understand the ASV scan process, apply remediation in a deliberate sequence beginning with CVSS 4.0+ findings on in-scope systems, and engage the PCI SSC-sanctioned dispute mechanism where appropriate will resolve failures efficiently and maintain a defensible, quarterly-compliant external vulnerability posture.
SecusyASV's PCI SSC-approved scanning platform gives you the results clarity, dispute support, and rescan access you need to move from failed to passing with confidence. Start your scan today and have a compliant report in hand before your next quarterly deadline.
A failed ASV scan means one or more of your internet-facing systems has a vulnerability scored 4.0 or higher on the CVSS scale, or triggered an automatic failure condition such as an active web application vulnerability or an unencrypted protocol in use. It does not mean you are immediately out of compliance — it means you must remediate the specific findings, or formally dispute any false positives, and submit a passing rescan report to your acquirer before your compliance deadline.
Yes. The PCI SSC's ASV Programme Guide includes a formal exception process that allows merchants to dispute findings that do not represent a genuine vulnerability in their specific environment. Common valid disputes include version-based false positives — where a patch has been applied but the software banner still shows an older version string — and compensating controls, where a legacy system cannot be patched but equivalent protection is in place through network segmentation or other documented means. Your ASV reviews the evidence and, if accepted, marks the finding as resolved without requiring a system change.
The timeline depends on how quickly you complete remediation and notify your ASV. Most ASVs will schedule a rescan within a few business days of receiving your confirmation that fixes are in place. The rescan itself typically completes within hours. The most common cause of delay is incomplete remediation — patches applied but banners unchanged, or firewall rules updated on one interface but not another — so verifying every fix before requesting the rescan is what determines your actual turnaround time.
A false positive is a vulnerability finding produced by the scan tool that does not reflect a real, exploitable weakness in your environment. The most frequent example is a version-based false positive: your system reports an older software version in its banner, but the underlying CVE has already been addressed through a vendor backport patch that did not increment the version number. Linux and other distributions routinely do this. The scanner reads the banner, not the actual patch state, and flags a vulnerability that no longer exists. These can be formally disputed with your ASV using vendor advisories or package manager output as evidence.
Yes. Under PCI DSS, a passing ASV scan report — not just a completed scan — is required for quarterly compliance. If your scan fails, you must remediate or dispute every failing finding and then undergo a rescan to generate a passing report. Some findings may be resolved through the formal dispute process rather than system changes, but the rescan step cannot be skipped. Confirming rescan costs and scheduling upfront with your ASV is important, particularly if you are working against a quarterly compliance deadline.
Any finding with a CVSS base score of 4.0 or higher on an in-scope system constitutes an automatic scan failure under the PCI SSC ASV Programme Guide. Findings below 4.0 are treated as informational — they appear in the report and represent real exposure worth addressing, but they do not by themselves prevent a passing result. Findings scoring 7.0 or above represent high or critical severity and should be prioritised first in your remediation sequence, as they carry the greatest exploitability risk and typically face the most scrutiny from acquirers and QSAs.
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.