PCI DSS SAQ A vs SAQ D: scope differences that actually determine which one applies
Julian ThorneApril 29, 2026
Key takeaways
SAQ A eligibility requires that merchant systems have zero ability to influence the payment page -- not just that a third-party payment provider is used. Developer access to iframe JavaScript code is a disqualifying factor regardless of which payment provider processes the transaction.
SAQ A covers 22 controls. SAQ D covers 300+. The difference is not administrative -- it includes quarterly ASV scans, annual penetration testing, network segmentation verification, and physical security controls that SAQ A merchants are not required to maintain.
Direct post payment flows, where card data passes through a merchant server before reaching the payment processor, place the merchant in scope and disqualify SAQ A regardless of how briefly the data is present.
Application logs retaining card data from error handling routines are one of the most common unexpected scope expansions in Vulnox PCI assessments -- merchants who believe they do not store cardholder data frequently find PANs in debug logs they had not reviewed.
SAQ A-EP sits between SAQ A and SAQ D: 191 controls, designed for merchants whose website participates in the payment flow without directly processing card data. Most merchants who incorrectly claim SAQ A eligibility actually qualify for A-EP.
Network segmentation reduces SAQ D scope but only if the segmentation is tested, not just documented. PCI DSS Requirement 11.4.1 requires penetration testing of segmentation controls annually and after significant changes.
TL;DR
SAQ selection is a data flow question. The merchant who picks SAQ A because they use Stripe is not necessarily wrong -- but the decision is not made by the choice of payment provider. It is made by what merchant systems can see, touch, or influence during the transaction. Most SAQ misclassification starts with a correct vendor decision and an incomplete boundary analysis.
The compliance scope that looked smaller than it was
A regional e-commerce retailer built their checkout flow using a hosted payment page iframe from a major payment processor. Their developers had direct access to the JavaScript configuration of the checkout page, including the JavaScript that loaded the iframe. The merchant's security team reviewed the setup, noted that card data never appeared in their server logs, and selected SAQ A for their annual compliance submission. Two years and two successful self-attestations later, a QSA review initiated by their acquiring bank found the merchant was operating under SAQ D requirements. The iframe was hosted on a subdomain the merchant controlled. Their developers could modify the JavaScript behavior of the payment page. The payment page was in scope. SAQ A had never applied.
The merchant had not falsified anything. Their card data logs were clean. Their vendor was PCI-compliant. They had simply applied a rule -- iframe equals outsourced equals SAQ A -- that the PCI DSS framework does not actually contain. The correct rule is: zero merchant influence on the payment page equals SAQ A eligibility. The iframe is one mechanism for achieving that separation. It is not proof that the separation exists.
How PCI DSS scoping actually works and where the SAQ boundary sits
The PCI DSS scope determination question has one root: does this system store, process, or transmit cardholder data, or could it affect the security of systems that do? A system that meets any part of that test is in scope. A system that cannot meet any part of it is out of scope. The SAQ type follows directly from the scope determination -- it is not a separate decision.
SAQ A was designed for merchants whose payment environment is genuinely isolated: the customer leaves the merchant's environment to complete payment on a third-party page, or the payment is handled entirely by a third-party system the merchant cannot influence. The 22 controls in SAQ A reflect the controls relevant to an environment where the merchant's only obligation is to not inadvertently expose card data through their own systems -- which, having no card data, means mostly vendor management and basic security hygiene.
SAQ D is everything else. It is explicitly the catch-all: any merchant who cannot demonstrate qualification for a more specific SAQ type defaults to SAQ D. The 300+ controls in SAQ D reflect the full PCI DSS requirements for environments where card data is present or where merchant systems could affect card data security.
The contested ground between these two is where most scoping errors occur. It is not the obviously in-scope merchant who processes cards directly. It is the merchant whose payment integration sits close to the SAQ A boundary without clearly crossing it: the iframe hosted on a merchant-controlled subdomain, the redirect flow where the merchant page sets parameters that affect the payment session, the checkout page that loads third-party scripts alongside the payment module. Each of these sits in a gray zone where the specific technical implementation determines which side of the boundary the merchant lands on.
Example
A Vulnox assessment of a SaaS platform offering white-label e-commerce found the platform operator claiming SAQ A for their base merchants. The payment iframe was technically hosted by a validated payment processor. The platform's template system, however, allowed merchant operators to inject custom JavaScript into checkout pages -- a feature designed for analytics and personalization. That JavaScript executed on the same page as the payment iframe. PCI DSS scoping rules place any system that could affect the security of a payment page in scope. The template injection feature meant the platform's infrastructure could affect the payment page. The platform was operating under SAQ D requirements. None of their merchants were.
PCI DSS v4.0 Section 4 of the standard covers scoping and network segmentation in detail. The guidance clarifies that systems providing security services to in-scope systems -- including DNS, authentication, and monitoring -- are also in scope. Merchants reviewing their own scope should map not just the payment transaction path but the supporting infrastructure that enables the transaction to occur securely.
Where the scope boundary breaks in practice
Assessment base: Vulnox PCI DSS assessment data, 2024-2025, covering e-commerce merchants on hosted platforms, custom-built checkout implementations, and hybrid redirect-iframe payment flows.
Application error logs retaining card data from failed transactions
In Vulnox PCI assessments, one of the most consistent unexpected scope findings is PANs appearing in application error logs. The pattern is specific: a payment transaction fails mid-process, the application logs the error including the request payload for debugging purposes, and the payload contains card data submitted before the failure occurred. The merchant's policy states they do not store cardholder data. Their production database contains no card numbers. Their application logs do. The logs are retained for 90 days on systems that are not in the merchant's declared cardholder data environment.
SAQ A eligibility requires that cardholder data never enters merchant systems. A PAN in an application log on a merchant server is cardholder data in a merchant system, regardless of how it got there or what the policy says. Merchants who have not reviewed their error handling and logging configuration for card data retention have not completed their scope determination.
Redirect payment flows where merchant page sets transaction parameters
A merchant using a payment redirect flow -- where the customer is sent to a third-party page to complete payment -- claimed SAQ A eligibility on the basis that card data never appeared in their environment. The redirect URL generated by the merchant's server included session tokens and transaction parameters that the payment processor used to pre-populate the payment form. The PCI DSS scoping guidance includes systems that affect the security of the payment process in scope. The merchant's server was generating parameters that influenced how the payment session behaved. The merchant qualified for SAQ A-EP, not SAQ A.
The distinction between SAQ A and SAQ A-EP is not whether card data enters the merchant environment -- it is whether the merchant's systems participate in the payment flow at all. A server that generates redirect parameters is participating. A server that does nothing more than display a link to a third-party payment page is not.
CI/CD pipeline access to payment server infrastructure
A merchant with otherwise clean scope determination had a Jenkins deployment server with SSH access to their payment application server for automated deployments. The merchant's scope diagram included the payment application server as in-scope and the Jenkins server as out-of-scope. The PCI DSS scoping rule for connected systems places any system that can connect to an in-scope system, and could affect its security, in scope. The Jenkins server could deploy code to the payment server. It was in scope. The penetration testing program covered the payment server. It did not cover the Jenkins server.
Scope determinations that trace the card data path correctly but miss the infrastructure management path leave the most operationally significant attack surface unexamined. An attacker who compromises the deployment pipeline has equivalent access to one who compromises the payment server directly.
SAQ A, SAQ A-EP, and SAQ D: where the lines sit
SAQ A
22 controls. Applies when all payment card processing is fully outsourced to PCI DSS validated third parties and the merchant's website, systems, and staff cannot access, influence, or modify card data or the payment page in any way. No quarterly ASV scans required. No penetration testing required beyond basic security review. Validation focuses on vendor management and confirming that the merchant's own infrastructure is genuinely isolated from card data.
SAQ A is achievable but requires genuine technical isolation, not just a policy statement about outsourcing. The merchant who hosts the payment iframe on their own subdomain, whose developers can modify checkout page JavaScript, or whose servers generate redirect parameters influencing the payment flow has not achieved the isolation SAQ A requires. Confirming SAQ A eligibility takes a technical boundary review, not a vendor compliance check.
SAQ A-EP
191 controls. Applies to e-commerce merchants who outsource card data handling but whose website participates in the payment flow -- JavaScript on the merchant page affects the payment, the merchant server generates redirect parameters, or the merchant's systems provide any function that influences payment security. Includes PCI DSS v4.0 Requirement 6.4.3 script inventory and integrity verification requirements. Quarterly ASV scans required.
SAQ A-EP is where most merchants who incorrectly claim SAQ A actually belong. The jump from 22 to 191 controls is significant operationally, and the script management requirements under 6.4.3 are specifically designed for the Magecart attack vector that targets merchants at this level of payment integration. Merchants discovering they qualify for A-EP rather than A should prioritize the script inventory and CSP implementation before the next compliance cycle.
SAQ D
329 controls for merchants, 343 for service providers. Applies to merchants who store, process, or transmit cardholder data directly, or who cannot demonstrate qualification for a more specific SAQ type. Requires quarterly ASV scans, annual penetration testing including segmentation testing, network diagrams, system configuration baselines, physical security controls, and continuous monitoring. The catch-all: any merchant whose environment does not clearly fit a more specific SAQ type defaults here.
SAQ D compliance costs significantly exceed SAQ A or A-EP. The annual compliance program maintenance cost for a SAQ D merchant typically runs 10 to 20 times that of a comparable SAQ A merchant, before factoring in remediation costs for findings. Merchants who can legitimately reduce scope to SAQ A-EP should do so -- the effort required to establish and maintain that boundary is substantially less than the ongoing SAQ D compliance burden.
What scope determinations consistently miss
Tag manager scripts on checkout pages
Tag management systems are a scoping blind spot across PCI assessments. A merchant uses Google Tag Manager to deploy analytics, affiliate tracking, and marketing pixels. The tag manager script loads on every page including checkout. The tag manager can be configured to fire additional scripts based on page conditions -- including conditions present on the payment page. Whether those scripts access card entry fields determines scope. The tag manager itself is a vector for injecting scripts that do affect payment page behavior. Merchants who have not audited what their tag manager can load on checkout pages have not completed their scope determination under PCI DSS v4.0 Requirement 6.4.3.
Shared authentication infrastructure between CDE and non-CDE systems
A merchant with a well-segmented network runs their payment application on an isolated server with correctly configured firewall rules. Authentication for the payment server uses the same Active Directory domain as the rest of the corporate network. An attacker who compromises a corporate workstation and escalates to domain admin credentials has authentication access to the payment server. The network segmentation is real. The authentication boundary is not. PCI DSS scoping guidance includes systems providing security services to in-scope systems in scope. The AD domain controller providing authentication to the payment server is in scope, which means the security controls applied to corporate workstations affect the CDE even if the network segments are properly isolated.
Cardholder data in customer service tools
E-commerce merchants whose customer service teams handle payment disputes frequently have card data appearing in customer service platforms -- support tickets where customers paste their card number to report a problem, order management systems that display partial PANs, or chat logs where card data was shared during a support interaction. The merchant's payment processing infrastructure is correctly scoped and isolated. The customer service platform is not in anyone's scope diagram. Whether the customer service platform retains card data -- and whether the controls applied to it meet PCI DSS requirements -- is a question most scope determinations do not ask.
Where SAQ scoping gets harder
Within 18 months, at least one major e-commerce platform will issue a compliance advisory clarifying that merchants using their checkout customization features -- JavaScript injection, theme modification, or checkout extension APIs -- do not qualify for SAQ A and should be evaluating SAQ A-EP or SAQ D eligibility, following pressure from card brands after breach investigations trace skimming to customized checkout JavaScript.
The pattern is present in current breach data. Magecart attacks have targeted checkout customization features on major platforms specifically because platform-level script injection is a scalable attack vector. Card brands have not yet formally required platforms to communicate SAQ implications of customization features to merchants. The breach investigation data that would drive that requirement is accumulating. The advisory is structurally probable once a breach of sufficient scale is traced to this vector on a recognizable platform.
Confidence: mediumA published platform security advisory or card brand merchant compliance bulletin specifically addressing SAQ eligibility implications of checkout customization APIs, citing breach investigation findings.PCI SSC will clarify SAQ A-EP eligibility criteria within 24 months to explicitly address AI-assisted checkout features -- product recommendation engines and dynamic pricing that execute JavaScript on checkout pages -- as a category requiring A-EP rather than A classification, because current guidance does not address whether AI-driven checkout personalization constitutes merchant participation in the payment flow.
AI-assisted checkout features are being deployed by e-commerce platforms at significant scale. Most execute JavaScript on the checkout page. Whether that JavaScript constitutes merchant participation in the payment flow under current scoping guidance is genuinely unclear -- the guidance was written before AI checkout features existed as a product category. The ambiguity creates an inconsistency in how QSAs are classifying merchants with these features, which typically generates a clarification from PCI SSC within a standard guidance cycle.
Confidence: lowA PCI SSC FAQ update, information supplement, or SAQ revision that explicitly addresses AI-driven checkout features as a scoping factor.
The scoping conversation most merchants are not having with their QSA
SAQ selection is treated as an administrative decision that happens before the compliance work starts. It should be treated as a technical finding that requires the same rigor as any other assessment output. The number of merchants who select their SAQ type based on what they believe their payment integration does, rather than what a technical boundary analysis confirms it does, is substantial. The merchants who end up in the wrong SAQ are not typically careless -- they made a reasonable inference from incomplete information and nobody verified it.
The QSA relationship is where this should get caught. A QSA who accepts a merchant's SAQ selection without reviewing the payment data flow -- including the specific technical implementation of any iframe, redirect, or JavaScript integration -- is accepting a risk that is not theirs to carry. In practice, QSAs vary widely in how thoroughly they challenge scope declarations at the outset of an engagement versus how thoroughly they execute controls testing once scope is fixed. The merchants most likely to be misclassified are the ones whose QSA started from their stated scope rather than verifying it.
Counterargument
The counterargument is that requiring full technical boundary analysis as a prerequisite to SAQ selection adds cost and time to a compliance process that small merchants already find burdensome. A merchant running a simple WooCommerce store with a standard payment plugin should not need to commission a penetration test to confirm SAQ A eligibility. That is a reasonable constraint. The answer is not to skip the boundary analysis -- it is to make the specific technical questions explicit enough that a merchant can verify them without specialized help: Can your developers modify the payment page JavaScript? Does your server generate parameters used by the payment session? Do any systems in your environment log data from failed payment transactions? Those three questions, answered honestly, resolve most SAQ A boundary cases without requiring expert assessment.
One verification step before your next SAQ submission
Before submitting your next SAQ self-attestation, pull the error and debug logs from your application servers and search them for 16-digit sequences. A regular expression covering standard PAN formats takes under a minute to write and under a minute to run. If the search returns results, you have card data in systems you may not have included in your scope. That finding changes your SAQ type regardless of how your payment integration is structured. If the search returns nothing, you have one confirmed data point that your application logging is not retaining card data -- which is one of the conditions SAQ A eligibility actually requires you to verify.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisPCI 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 standardsNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionTop 10 Digital Footprint Monitoring Tools 2025
digital footprint monitoring tools
Frequently Asked Questions
What is the actual difference between SAQ A and SAQ D and how do merchants know which applies?
SAQ A applies when a merchant's systems have zero ability to influence the payment page -- the merchant outsources all card data handling to a validated third party and nothing in the merchant environment touches, intercepts, or can modify what happens at the point of card entry. 22 controls. SAQ D applies to merchants who store, process, or transmit cardholder data on their own systems, or who cannot demonstrate that their systems are completely isolated from the payment flow. 300+ controls. The decision is a data flow question, not a vendor question. Using Stripe does not guarantee SAQ A. What determines it is whether merchant systems can see or influence card data at any point in the transaction.
Does using an iframe payment form qualify a merchant for SAQ A?
Only if the merchant's systems have no ability to modify the JavaScript executing inside the iframe. If the merchant's developers have commit access to the page that loads the iframe, or if the iframe is hosted on a subdomain the merchant controls, SAQ A eligibility fails. The iframe creates visual separation. It does not create scope separation unless the merchant's infrastructure genuinely cannot influence what the iframe executes. This is the most common SAQ A disqualification pattern in Vulnox PCI assessments -- the merchant believed the iframe handled the scope reduction, but the technical boundary did not hold.
What is a direct post method and why does it disqualify SAQ A?
A direct post is a payment flow where the card data is submitted from the customer's browser directly to the merchant's server before being forwarded to the payment processor. The merchant server receives and transmits cardholder data, which places it in scope. SAQ A requires that card data never touches merchant infrastructure. Any payment flow where the merchant's server sits in the data path -- even briefly, even without storing the data -- disqualifies SAQ A. Direct post merchants typically fall into SAQ D or SAQ C depending on their specific environment.
What is SAQ A-EP and how does it differ from SAQ A?
SAQ A-EP applies to e-commerce merchants who outsource payment processing but whose website is involved in the payment flow -- typically because JavaScript on the merchant's page affects how the payment is processed, or because the merchant page redirects customers to a payment processor with parameters that influence the transaction. 191 controls versus SAQ A's 22. SAQ A-EP includes requirements for payment page script management, which directly addresses the Magecart attack vector. Merchants who assumed they qualified for SAQ A but whose checkout page loads scripts that interact with the payment flow are typically SAQ A-EP merchants.
What are the most common PCI DSS scope reduction errors that push merchants into SAQ D?
Three patterns appear consistently in Vulnox assessments. First, debug logs or error logs that capture card data from failed transactions -- merchants who believe they do not store card data but have application logs retaining PANs from error handling routines. Second, CI/CD pipeline components that touch payment infrastructure -- build servers and deployment tools that access payment servers are in scope even if they do not process card data. Third, third-party scripts on checkout pages that interact with card entry fields -- once a merchant's page influences the payment flow, SAQ A no longer applies and the relevant scope depends on how the influence works.
How does network segmentation reduce PCI DSS scope for SAQ D merchants?
Network segmentation isolates the cardholder data environment from other merchant infrastructure, limiting the number of systems a QSA needs to assess. Effective segmentation requires that systems outside the CDE cannot reach systems inside it except through defined, monitored pathways. The segmentation must be verified -- not just documented -- through penetration testing that attempts to traverse the boundary. PCI DSS Requirement 11.4.1 requires penetration testing of segmentation controls at least annually and after any significant changes. Merchants who document segmentation without testing it operationally carry the same compliance risk as merchants who have not segmented at all.
What validation requirements differ between SAQ A and SAQ D merchants?
SAQ A requires confirming that outsourced payment providers maintain valid PCI DSS certification and that internal controls around user access and policy documentation are in place. No quarterly vulnerability scans are required for pure SAQ A merchants. SAQ D requires quarterly external vulnerability scans by an Approved Scanning Vendor, annual penetration testing, documented network diagrams, system hardening evidence, access control logs, and physical security controls. The compliance cost difference between the two is significant -- SAQ D merchants routinely spend 10 to 20 times more annually on compliance program maintenance than SAQ A merchants.
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.