False Positive PCI ASV Scan: How to Dispute a Flagged Vulnerability
Learn how to dispute a false positive PCI ASV scan finding, the required evidence, ASV process steps, and how to protect your compliance status.
PCI compliance for BigCommerce is one of the most misunderstood requirements in e-commerce, largely because BigCommerce’s own PCI DSS Level 1 certification gives merchants a false sense that compliance is fully handled for them. It isn’t. BigCommerce is a PCI DSS Level 1-certified platform. That certification is genuinely significant, but PCI DSS compliance is assessed at the entity level, meaning your store, as a distinct business accepting card payments, carries its own compliance obligations regardless of what the platform has already certified.
This guide breaks down exactly where BigCommerce’s certification ends, and your responsibility begins: which SAQ type applies to your setup, when quarterly ASV scans are required, where checkout-related risk actually lives, and what’s changed under PCI DSS v4.0. Whether you’re running a growing SMB storefront or managing compliance across a mid-market operation, you’ll find a clear, practical path to closing your compliance gaps without disrupting your store.
PCI DSS (Payment Card Industry Data Security Standard): A global security standard from the PCI Security Standards Council (PCI SSC) defining technical and operational requirements for any organisation that stores, processes, or transmits cardholder data.
ASV (Approved Scanning Vendor): A vendor approved by the PCI SSC to run external vulnerability scans against merchant-facing IP addresses and domains. Required quarterly for most merchants accepting card payments online.
SAQ (Self-Assessment Questionnaire): A validation tool merchants use to document their own PCI DSS compliance. Which SAQ type applies depends on how payment data is accepted and processed.
Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data, plus any systems connected to or capable of affecting that environment's security.
BigCommerce, as a platform, is PCI DSS Level 1 certified, the highest tier available, but a BigCommerce store is not automatically compliant. Compliance depends on your checkout configuration, your integrations, and whether you've completed your own required steps.
This distinction matters because your acquiring bank and the card brands hold you, the merchant, responsible for your own compliance posture, not BigCommerce. Platform-level certification tells you the foundation is solid. It doesn’t tell you anything about what you’ve built on top of it: custom scripts, third-party apps, or self-managed domain infrastructure.
Run a free ASV scan preview and find out what an attacker, or an auditor, would see today.
BigCommerce's certification covers its shared hosting infrastructure, core platform codebase, and internal operational processes, not your custom code, apps, or externally managed domains.
What’s covered: the platform’s internal hosting environment and the systems BigCommerce directly controls. When payment data flows through a BigCommerce-hosted checkout to a certified gateway with no custom code intercepting it, your compliance exposure is meaningfully reduced, and you may qualify for a simpler SAQ.
What’s not covered: custom themes with payment-related scripts, third-party apps from the BigCommerce marketplace, external systems connected via API, and any server or domain infrastructure you operate independently. If your checkout includes custom JavaScript or a third-party tool touching payment or order data, that falls under your compliance responsibility, regardless of BigCommerce’s certification.
Most standard BigCommerce merchants using a fully hosted or redirected checkout qualify for SAQ A; merchants with embedded payment fields on their own domain typically need SAQ A-EP.
The determining factor isn’t your platform; it’s your checkout’s actual data flow. Audit that flow directly rather than assuming based on platform marketing claims.
Yes. Any internet-facing IP address, domain, or subdomain you control, including custom domains, staging environments, and connected apps, needs a quarterly external vulnerability scan.
This is a persistent point of confusion: because the storefront is hosted by BigCommerce, merchants assume there’s nothing left to scan. In practice, most merchants control at least some external-facing infrastructure: a custom domain, an admin portal, integration endpoints, or supporting servers for fulfilment and analytics. Anything in this category that touches or could affect the cardholder data environment belongs in your scan scope.
SAQ types A-EP, B-IP, and C all carry a mandatory ASV scanning requirement. SAQ A is reserved for merchants who’ve fully outsourced cardholder data handling with no custom checkout code, may not require scanning, but its eligibility criteria are strict, and many BigCommerce merchants don’t actually meet them once their checkout is audited.
Checkout pages are the highest-risk area for PCI compliance, not because BigCommerce is insecure, but because this is where merchants most often introduce custom code and third-party scripts that expand compliance scope.
BigCommerce gives merchants real flexibility in configuring checkout, which is a genuine business advantage and a compliance risk. Every piece of custom JavaScript, every marketing pixel, every embedded form element not hosted by a certified payment provider is a potential compliance concern.
Hosted vs. embedded checkout: Redirect-based checkout keeps cardholder data off your pages entirely and favours SAQ A eligibility. Embedded or iframe-based payment fields, even when data is tokenised, mean your pages must be demonstrably protected against manipulation, which is exactly what SAQ A-EP (and its ASV scan requirement) is built for.
Script risk: An unvetted script on a checkout page, a marketing pixel, a tag manager, a personalisation tool; can be used to skim payment data if compromised. PCI DSS v4.0 now requires merchants to maintain a documented, justified inventory of every script authorized to run on payment pages.
Talk to a PCI compliance specialist and get a clear answer before your next assessment deadline.
Forgotten staging environments, weak TLS configuration on custom domains, and exposed endpoints from third-party apps account for most BigCommerce scan failures.
PCI DSS v4.0, now the sole active version of the standard, adds mandatory script management for payment pages and expands multi-factor authentication requirements to cover all access to the cardholder data environment; not just admin accounts.
Requirement 6.4.3 specifically mandates an authorised inventory of every script running on payment pages, each with a documented business justification and an integrity-verification mechanism. For BigCommerce merchants using tag managers or personalisation tools on checkout, this is a new, concrete compliance task, not a formality.
MFA is now required for any access to the cardholder data environment, including your BigCommerce admin panel and any integrated system with access to order data, if reachable via the public internet. v4.0 also shifts the standard toward a risk-based approach: controls must be shown to be effective, not just documented as present.
Inventory every domain and subdomain tied to your store, confirm your checkout's actual data flow to determine SAQ type, and remediate before you scan — not after.
PCI compliance for BigCommerce isn’t a status the platform grants you, it’s a posture you build on top of a certified foundation. BigCommerce’s Level 1 certification meaningfully reduces the compliance burden at the infrastructure layer, but your responsibility begins exactly where the platform’s control ends: custom code, checkout configuration, third-party integrations, and any external-facing systems you operate independently. Getting your SAQ type right, running a clean quarterly ASV scan, and keeping an honest inventory of what’s running on your checkout pages is usually all it takes to close the gap.
Get your quarterly ASV scan scheduled with Secusy ASV and keep your BigCommerce store audit-ready year-round.
BigCommerce holds PCI DSS Level 1 certification for its own platform infrastructure. That doesn't make your store automatically compliant, you still need the correct SAQ and, in most cases, quarterly ASV scans.
Yes, if you control any internet-facing IP, domain, or subdomain connected to your store, including custom domains, staging sites, and third-party app integrations.
No, when merchants use a hosted payment page or certified gateway, payment data routes directly to the processor. Merchants must still ensure their own scripts and apps don't inadvertently expose payment data.
Checkout page scripts, third-party pixels, tag managers, and personalization tools, are the most common source of risk, followed by forgotten staging environments and legacy redirects.
Both hold PCI DSS Level 1 certification. BigCommerce's more open API and greater customization flexibility can introduce additional compliance risk if custom code or scripts are added to checkout without a documented review process.
ASV scans are required quarterly, and your SAQ is completed annually, but script inventories and integration reviews should be treated as an ongoing discipline, not an annual task.
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.