PCI DSS SAQ selection: why merchants pick the wrong path and what it costs in practice
Geert WarmenbolApril 29, 2026
Key takeaways
Approximately 28-30% of merchants select the wrong PCI DSS SAQ, and the error almost always runs optimistic: claiming simpler eligibility than the actual environment supports.
JavaScript from your origin domain running on a payment page disqualifies SAQ A eligibility regardless of where card data is sent. Google Tag Manager on the checkout page is the most common real-world trigger for unintended SAQ A-EP scope.
SAQ misclassification does not produce an immediate compliance violation. It produces undetected control gaps that surface during post-breach forensic investigation when the acquiring bank applies merchant agreement liability.
PCI DSS v4.0 Requirement 12.3.2 requires targeted risk analysis for customized controls to be maintained continuously, not completed once at implementation. Most organizations treat it as a documentation milestone.
Scope reduction is an engineering project, not a documentation exercise. Network segmentation, redirect architecture, and iFrame isolation must be technically validated. A policy stating that employees should not store card data does not reduce scope.
SAQ D Requirement 6.3.3, continuous patching of all in-scope software, is the hardest control to demonstrate operationally because most patch management programs run on cycles, not continuously, and the gap between cycle and continuous is what auditors test.
TL;DR
PCI DSS SAQ selection fails in a predictable direction: merchants pick the simplest path their environment might support, make one optimistic assumption about scope, and build a compliance program against the wrong boundary. The error is invisible until it is not. The JavaScript on the payment page, the tag manager loading scripts from your domain, the legacy system that was excluded from scope because it would have been inconvenient to include -- these are not edge cases. They are the standard pattern. Getting the SAQ right requires data flow analysis, not documentation.
How the wrong SAQ gets selected
A mid-sized e-commerce merchant integrated Stripe Elements for payment processing. Stripe handles the card data. The merchant has no database storing PANs. The payment form is an iFrame served from Stripe's domain. The compliance team reviews the SAQ eligibility criteria and selects SAQ A: 22 controls, attestation complete, job done. Six months later, during a routine assessment engagement, we map the JavaScript loading on the checkout page. Google Tag Manager is present. GTM loads several scripts from the merchant's origin domain. Those scripts run in the same browser context as the payment page. Whether they access the payment iFrame directly is not the question. The question is whether code executing in that context could. It can. SAQ A eligibility requires that the merchant's systems do not interact with the payment page. GTM means they do.
The merchant was not trying to misrepresent their compliance posture. They genuinely believed their Stripe integration qualified for SAQ A. Nobody on the team had considered what Google Tag Manager meant for JavaScript execution context. The compliance program they built was thorough for the 22 controls SAQ A requires. It had no coverage for the additional controls SAQ A-EP requires because nobody knew the scope question had been answered incorrectly. This is the structural pattern: the misclassification happens at scope assessment, everything downstream is built on a wrong foundation, and the error is invisible until something forces a re-examination.
How SAQ eligibility actually works and where the boundaries are
The PCI DSS SAQ framework is built around a single underlying question: what does your environment do with cardholder data? The SAQ types create brackets based on the answer. SAQ A applies when the answer is nothing -- you redirect entirely to a third-party processor with no code execution on your side that touches the payment context. SAQ A-EP applies when your systems host the payment page but all processing and storage is outsourced. SAQ B applies to physical card-present environments using standalone terminals not connected to other systems. SAQ C applies to merchants with payment application systems connected to the internet. SAQ D is the catch-all: if your environment does not cleanly fit a more specific SAQ, or if you store cardholder data electronically, SAQ D applies.
The boundaries matter because the requirement counts are not merely different in size -- they are different in kind. SAQ A's 22 requirements focus on vendor management and ensuring your service providers are handling compliance. SAQ A-EP's requirements include vulnerability management, web application security testing, and system change management, because your servers are in the data path even if they do not store data. SAQ D's 329 requirements for merchants cover every PCI DSS control family because your environment is the environment.
PCI DSS v4.0 introduced the customized approach under Requirement 12.3.2, allowing merchants to implement alternative controls that achieve the intent of a standard requirement through different technical means. This is genuinely useful for mature security programs with specific architecture constraints. It also introduces a new failure mode: customized controls that were implemented with a one-time risk analysis that has not been reviewed as the threat environment changed. The customized approach creates documented flexibility. It also creates documented liability if the risk analysis that justified the customization is out of date.
Example
SAQ A eligibility for e-commerce merchants requires that the merchant's website does not receive cardholder data, that all payment processing is handled on the service provider's systems, and that the only connection to the payment process is a link or redirect. The JavaScript trigger is where this breaks down operationally. An iFrame served from a third-party payment processor domain isolates the payment form. But if JavaScript from the merchant's origin domain runs on the parent page, that code executes in the same browser context as the iFrame. Browser security policies limit cross-origin frame access, but the execution context is shared. PCI SSC guidance treats this as pulling the merchant out of SAQ A eligibility because the merchant's code can potentially influence the payment environment. Google Tag Manager, analytics scripts, A/B testing tools, and chat widgets loaded from the merchant's domain on the checkout page all create this execution context.
The same issue applies to Content Security Policy. Merchants who believe their iFrame payment integration qualifies for SAQ A should review their checkout page CSP headers. A permissive CSP that allows inline scripts or scripts from broad domains creates execution context that SAQ A eligibility does not accommodate. A properly locked CSP that restricts script execution to the payment processor's domain and prevents all other script loading is evidence that the isolation is genuine. Most checkout pages do not have this CSP configuration because it breaks analytics, marketing tags, and every other third-party script the business team has requested.
What the assessment data shows
Assessment base: Drawn from Vulnox PCI DSS gap assessments and SAQ validation engagements across e-commerce merchants, SaaS platforms, and payment service providers, 2023 to 2024.
SAQ misclassification appears in approximately 28-30% of merchant environments we assess, and the error is almost always optimistic
When we review a merchant's SAQ selection before beginning a gap assessment, roughly three in ten are using a SAQ that does not match their environment. The errors are not random. They cluster in two places: e-commerce merchants claiming SAQ A eligibility while running JavaScript from their domain on the payment page, and merchants with in-house payment applications claiming SAQ C eligibility when their architecture and data flows put them in SAQ D scope. The pessimistic error -- selecting a more demanding SAQ than required -- is rare. The optimistic error is the pattern.
A compliance program built against the wrong SAQ has genuine gaps in the control families the correct SAQ would have required. The program passes attestation because the merchant is attesting against the wrong boundary. The gaps remain undetected until a post-breach investigation maps the actual environment against the PCI DSS requirements that should have applied.
Google Tag Manager is present on the payment page in a majority of e-commerce merchants claiming SAQ A eligibility
In assessments of e-commerce merchants using iFrame or redirect payment integrations who have selected SAQ A, we find tag management platforms loading scripts from merchant-controlled domains on the checkout page at a high rate. The merchants are usually aware they are using tag management. They are almost never aware that tag management on the payment page is a SAQ A eligibility disqualifier. The implementation decision was made by a marketing or analytics team. The compliance team did not know to ask about it.
This finding is reliable enough to be a first-pass assessment heuristic: if a merchant claims SAQ A eligibility and their website uses a tag management platform, examine the checkout page script inventory before accepting the eligibility claim. The failure is almost never intentional. It is a knowledge gap between the technical decision and the compliance implication.
Requirement 6.3.3 continuous patching is the most consistently non-compliant operational control in SAQ D environments
In SAQ D gap assessments, Requirement 6.3.3 -- all software protected from known vulnerabilities through an established patching process -- produces compliance gaps in a significant majority of assessed environments. The gap is always the same: organizations have patch management programs that run on monthly or quarterly cycles. The requirement is continuous. Auditors who test this control ask for evidence that the patching process responds to newly published vulnerabilities on an ongoing basis, not just on a scheduled cycle. A monthly patch cycle that addressed all vulnerabilities as of last Tuesday is not evidence of a continuous process if a critical CVE was published this Wednesday.
The operational gap between a scheduled patch cycle and a continuous patching process is not bridged by documentation. It requires either a monitoring and response workflow that identifies new vulnerabilities against the in-scope asset inventory in near real-time, or a compensating control that demonstrably reduces the risk of the gap. Most organizations have neither and are relying on auditors who do not test the control rigorously.
Reducing scope increases risk more often than it reduces compliance burden
Common belief
Scope reduction is a straightforward optimization: fewer systems in scope means fewer controls to implement, less compliance work, and a simpler SAQ. Organizations invest in scope reduction as a cost-saving measure. The assumption is that if you can legitimately exclude systems from PCI DSS scope, you should.
What we found
The most consistent segmentation gap we find in scope-reduced environments is not a firewall misconfiguration. It is a shared service or shared credential that was implemented for operational convenience after the segmentation was established. A monitoring tool deployed to an out-of-scope server that also monitors in-scope servers. A service account with access to both environments. An administrative jump host that was added to simplify management and sits in both network segments. None of these were intended to bridge the segmentation boundary. All of them do.
The premise is correct but the execution creates a structural problem. Scope reduction requires genuine architectural isolation: network segmentation that prevents in-scope systems from communicating with out-of-scope systems, data flow controls that prevent cardholder data from reaching excluded systems, and ongoing validation that the isolation holds as the environment changes. When these controls are solid, scope reduction is legitimate and valuable. When they are partially implemented or not validated, scope reduction creates a false boundary that the compliance program treats as real.
The systems excluded from scope still exist. They still have the same vulnerabilities, the same patch cycles, and the same configuration issues they had before. What changed is that the compliance program no longer covers them. If the segmentation that was supposed to isolate them from in-scope systems has a gap -- a misconfigured firewall rule, a shared service account, an application integration that was installed after segmentation was validated -- cardholder data can reach excluded systems through a path the compliance program is not monitoring.
In Vulnox assessments that include network segmentation validation, we find segmentation gaps in a meaningful share of environments that implemented scope reduction. The gap does not invalidate the scope reduction retroactively in all cases, but it means the security assumption that justified the scope reduction does not hold. The compliance program is running against a boundary that is not where the network thinks it is.
SAQ A, SAQ A-EP, and SAQ D: where the practical boundaries are
SAQ A
22 requirements. Applies to e-commerce merchants with fully outsourced payment processing, no electronic storage of cardholder data, and no code from the merchant's origin domain running in the payment page context. The merchant's website links to or embeds a payment page served entirely from the third-party processor's domain with no script execution from the merchant's servers. Covers vendor management, service provider oversight, and basic security policy requirements.
The eligibility test is binary and unforgiving. Either your origin domain has no code execution context on the payment page or it does. If it does, you are not in SAQ A. The 22 controls are straightforward to implement. The difficulty is in confirming that eligibility is genuinely met, which requires a complete inventory of every script loading on the checkout page and confirmation that none originate from domains you control.
SAQ A-EP
191 requirements. Applies to e-commerce merchants whose payment page is hosted on their own servers but who outsource all cardholder data storage and processing to a third party. The merchant's server serves the payment page, which means the merchant's systems are in the data flow even if they never see card numbers. Includes vulnerability management, web application security testing, system change management, and the full software security requirements that SAQ A skips.
The requirement jump from SAQ A to SAQ A-EP is not proportional: 22 controls to 191 is a significant operational difference. Merchants who discover they should be in SAQ A-EP after building a compliance program for SAQ A face a substantial remediation project. The most common trigger -- JavaScript from the merchant's domain on the payment page -- is often fixable through architectural changes like locking the CSP and removing third-party scripts from the payment page, which would restore SAQ A eligibility. Whether those changes are feasible depends on how many business tools depend on that JavaScript.
SAQ D (Merchant)
329 requirements covering all PCI DSS control families. Applies to merchants who store cardholder data electronically, process transactions on their own systems, or do not qualify for a more specific SAQ. No abbreviated paths. Every requirement family applies: access control, vulnerability management, network security, penetration testing, logging and monitoring, incident response, and all software security requirements.
SAQ D is not inherently harder to pass than SAQ A-EP -- both require the same operational discipline. It is more labor-intensive because there are more controls to document and evidence. The operational challenges are in the continuous requirements: Requirement 6.3.3 for patching, Requirement 10.4 for log review, and Requirement 11.3 for penetration testing all require ongoing operational processes that cannot be satisfied by point-in-time documentation.
Where SAQ compliance programs miss
Third-party scripts that change after the compliance review
Even when a merchant correctly identifies every script loading on the checkout page at the time of SAQ completion, that inventory changes. Marketing teams add new tag manager rules. Analytics vendors update their integration snippets to load additional scripts. A/B testing tools add code to the page. The compliance assessment was accurate at the time of completion and is stale thirty days later. SAQ A eligibility is not a state that is validated once; it is a state that requires continuous monitoring of the payment page script inventory. Most compliance programs do not have this monitoring in place.
Service provider SAQ D and the responsibility matrix obligation
SAQ D for service providers includes Requirement 12.9.2, which obligates service providers to provide customers with documentation of which PCI DSS requirements the service provider manages and which are the customer's responsibility. Most service providers we assess have not maintained this documentation in a form that satisfies the requirement. They have service descriptions and security whitepapers. They do not have a mapping that tells customers exactly which controls are covered by the service and which require customer implementation. Customers who do not receive this documentation are making scope and control assumptions that may be incorrect.
The v4.0 customized approach risk analysis that was written once
PCI DSS v4.0 Requirement 12.3.2 requires a targeted risk analysis to justify customized control implementations, and that analysis must be reviewed when the threat environment changes. The failure mode is treating this as a documentation exercise completed at implementation. Organizations that implemented customized controls under v4.0 and documented the initial risk analysis have satisfied the letter of the requirement at point of completion. They have not satisfied the ongoing review obligation. Auditors testing this control in 2025 and 2026 will ask for evidence that the risk analysis has been reviewed and updated since initial implementation. Most organizations will not have this evidence.
Automated compliance tooling that assesses the wrong scope
Automated PCI DSS compliance platforms are useful for control validation against known-in-scope systems. They handle the technical, binary controls well: TLS version, MFA configuration, open ports. They do not handle scope determination. The question of whether a given system is in PCI DSS scope requires data flow analysis that automated tools cannot perform without explicit scope definition input from the operator. Organizations that run automated compliance tooling against a self-defined scope and use the results to inform SAQ completion are validating controls against a boundary they defined themselves. If the boundary is wrong, the tool confirms compliance against the wrong scope.
Where PCI DSS SAQ enforcement is heading
The e-commerce JavaScript scope question will produce a wave of SAQ misclassification findings during post-breach investigations over the next two years as card brands and acquiring banks apply v4.0 eligibility standards retroactively to breach forensics.
PCI DSS v4.0 clarified the JavaScript scope trigger for SAQ A eligibility in ways that v3.2.1 left ambiguous. Many merchants who completed SAQ A attestations under v3.2.1 guidance have not re-evaluated eligibility under v4.0 standards. Their checkout pages have the same JavaScript they always had. The standard they attested against is now superseded. When a breach occurs in one of these environments, forensic investigators will apply current PCI DSS standards to the pre-breach compliance posture, and SAQ A claims that were arguably defensible under v3.2.1 will not be defensible under v4.0.
Confidence: highIf post-breach forensic investigations and card brand assessments published through 2026 do not cite SAQ A misclassification based on JavaScript scope as a finding at meaningfully higher rates than prior years, the v4.0 clarification did not produce the enforcement shift this prediction anticipates.AI-assisted SAQ completion tools will create a new category of compliance program failure within 18 months: merchants with technically correct control documentation and structurally incorrect scope determinations, because AI tools are effective at documenting controls and ineffective at determining scope.
Scope determination requires data flow analysis, network architecture review, and JavaScript execution context evaluation -- tasks that require access to the actual environment and produce findings that are environment-specific. Control documentation -- writing policies, describing implementation of a specific requirement -- is generative text work that AI tools handle well. Merchants who use AI tools for SAQ completion will produce better-documented control responses and will not improve their scope determination accuracy because the AI has no way to evaluate their actual checkout page. The compliance artifacts will look more professional. The scope errors will remain.
Confidence: highIf AI-assisted compliance tool adoption does not correlate with increased SAQ scope misclassification rates in QSA and forensic investigation findings by end of 2026, the prediction is wrong about the direction of the error.
What the SAQ framework gets wrong about merchants
The SAQ framework assumes that the merchant selecting the SAQ understands their own environment well enough to answer the eligibility questions accurately. For large merchants with dedicated security teams, this is a reasonable assumption. For the small and mid-sized e-commerce merchants who make up the majority of SAQ users, it is not. The JavaScript scope question that moves a merchant from SAQ A to SAQ A-EP is a technical boundary that requires understanding of browser execution context, origin policy, and iFrame isolation. The merchant who integrated Stripe on the advice of their developer and added Google Tag Manager on the advice of their marketing team has neither of those people telling them that the combination has PCI DSS compliance implications.
The counterargument is that PCI DSS cannot be simplified to the point where a non-technical merchant can self-assess without any guidance. The controls exist because the risks are real, and the SAQ eligibility criteria exist because the controls required depend on the environment. Simplifying the framework to remove technical eligibility criteria would remove the precision that makes the SAQ system work.
That is correct. The issue is not that the framework is too technical. It is that the compliance ecosystem has not built sufficient accessible tooling to help merchants determine scope accurately before they complete the SAQ. A checkout page script inventory tool, a segmentation validation check, and a data flow mapping utility would catch most SAQ misclassifications before they become post-breach findings. The tools are not complicated to build. They just have not been built as part of the standard SAQ workflow.
Counterargument
Acknowledged above: the framework's technical precision is a feature, not a bug. The gap is in the tooling that helps merchants apply that precision to their own environments.
One thing to do before your next SAQ attestation
Before you complete your next SAQ, pull a complete inventory of every script loading on your checkout page. Use a browser developer tools network tab or a third-party script scanning tool. For every script, identify the domain it loads from and whether that domain is one you control. If any script originates from a domain you control and the payment form is on that page, your SAQ A eligibility claim needs to be re-examined. This takes thirty minutes and requires no external help. It will tell you whether the scope assumption your compliance program is built on is correct.
Further Reading
Gap Analysis
framework gap analysisPCIDSS
PCI DSS framework questionnairePCI DSS SAQ types explained: which one applies to your organization
https://vulnox.io/blog/pci-dss-saq-types-explainedPCI DSS Standards Overview
PCI DSS official standardsPCI DSS Guide UCSF
PCI DSS compliance guidePCI DSS Requirements TechTarget
PCI DSS requirements overview
Frequently Asked Questions
How do I know which PCI DSS SAQ type applies to my organization?
The decision tree starts with a single question: does any system you control electronically store, process, or transmit cardholder data? If the answer is no and you fully redirect customers to a third-party payment processor with no JavaScript running on the payment page from your domain, SAQ A is likely correct. If you have JavaScript on the payment page from your origin -- including analytics scripts, tag managers, or anything that can access the DOM of the payment page -- you are in SAQ A-EP territory even if the card data itself goes directly to the processor. If your servers process card transactions or you store cardholder data, SAQ C or SAQ D apply depending on architecture. The PCI SSC flowchart is a reasonable starting point but treats edge cases optimistically. When in doubt, the more comprehensive SAQ is the defensible choice.
What is the difference between SAQ A and SAQ A-EP for e-commerce merchants?
SAQ A covers merchants who outsource all cardholder data functions to a PCI DSS-compliant third party and have no JavaScript running on the payment page that originates from their domain. SAQ A-EP covers merchants whose payment page is hosted on their own system but who outsource cardholder data processing and storage to a third party. The practical trigger for SAQ A-EP is usually JavaScript: if your site loads scripts from your own servers onto a page where payment data is entered, those scripts can potentially access or modify the payment environment, and SAQ A eligibility is gone. Google Tag Manager on the checkout page is the most common real-world trigger. The merchant did not intend to touch cardholder data. The tag manager created a code execution context that means they functionally can.
What happens if a merchant selects the wrong PCI DSS SAQ?
In the optimistic direction -- claiming a simpler SAQ than your environment warrants -- the practical consequence is that your compliance program does not cover the controls required for your actual environment. You pass your SAQ attestation. Your CDE has gaps in the control families the uncompleted SAQ would have required. A post-breach forensic investigation surfaces those gaps and your acquiring bank or card brand holds you liable under the terms of your merchant agreement. Misclassification is not a technical violation that produces a fine. It is a condition that produces exposure, and the exposure becomes visible when something goes wrong.
How does PCI DSS v4.0 change SAQ eligibility and requirements?
PCI DSS v4.0 introduced the customized approach, which allows merchants to implement alternative controls that meet the intent of a requirement through different means, supported by a targeted risk analysis under Requirement 12.3.2. For SAQ purposes, this matters because customized control implementations require documented risk analysis that must be updated as the threat environment changes -- not a one-time documentation exercise. V4.0 also made several requirements that were previously best practices into formal requirements effective March 2025, including more specific multi-factor authentication scope and updated software development security requirements. Organizations whose SAQ completion relied on the old requirement language without reviewing the v4.0 changes may have gaps they have not identified.
Can a merchant reduce their PCI DSS scope to qualify for a simpler SAQ?
Yes, but scope reduction requires genuine architectural changes, not documentation changes. True scope reduction means cardholder data no longer flows through the systems you are trying to exclude: network segmentation that is validated, not assumed; redirect or iFrame payment solutions where your origin truly has no code execution context on the payment page; tokenization that means your systems never see primary account numbers. What does not reduce scope: a policy that says employees should not store card data, an iFrame with a tag manager loading scripts from your domain, or a redirect that passes through a URL you control. Scope reduction is an engineering project. Claiming scope reduction without the engineering is the most common source of SAQ misclassification we see in assessments.
What does PCI DSS SAQ D require and who needs it?
SAQ D-Merchant covers 329 requirements and applies to merchants who store cardholder data electronically, process payments through their own servers, or have environments that do not qualify for a simpler SAQ. SAQ D-Service Provider covers 330 requirements and applies to service providers who are not otherwise eligible for a different validation type. The additional requirement in the service provider version relates to the obligation to maintain and provide a responsibility matrix for customers. SAQ D has no abbreviated paths: every control family applies, including vulnerability management, penetration testing, logging and monitoring, and the full scope of access control requirements. Requirement 6.3.3, continuous patching of all software, is consistently the hardest operational control for organizations to demonstrate as genuinely continuous rather than periodic.
Where do automated compliance tools break down in PCI DSS SAQ assessment?
Automated tools handle control validation well for technical, binary controls: is MFA enabled, is TLS 1.0 disabled, are these ports open. They handle scope determination poorly. The question of whether a given system is in scope for PCI DSS depends on data flow analysis, JavaScript execution context, and network segmentation validation -- all of which require either manual review or specialized tooling that most compliance platforms do not include. The SAQ misclassification problem is almost never a failure of control implementation. It is a failure of scope assessment that automated tools ran against the wrong boundary.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.