PCI DSS SAQ types explained: which one applies to your organization

PCI DSS 4.0.1 (full standard)

Any merchant or service provider that stores, processes, or transmits cardholder data and does not qualify for any SAQ type, or that processes volumes above the thresholds card brands set for self-assessment eligibility. Level 1 merchants processing over 6 million Visa or Mastercard transactions annually require a QSA-led Report on Compliance, not a self-assessment. Service providers handling cardholder data for multiple clients are often required by card brands or acquirers to complete a full ROC regardless of transaction volume.

Scope creep over time. An organization achieves ROC compliance with a well-defined cardholder data environment, then over the following 12 months, new integrations, cloud migrations, or acquired business units gradually expand the environment without triggering a formal scope review. The next annual assessment finds a CDE that is three times larger than the documented one. Compensating controls written for the old architecture no longer apply. The failure is not malicious — it is the predictable result of treating scope as a one-time exercise rather than a continuously maintained artifact.

The full standard covers 12 control domains: network security controls, secure configurations, cardholder data protection, cryptographic key management, malware defenses, secure system and software development, access restriction, authentication controls, physical access controls, logging and monitoring, vulnerability testing, and information security policy. Version 4.0.1 added mandatory targeted risk analysis as a documented input to several control decisions, expanded multi-factor authentication requirements to cover all access to the cardholder data environment, and introduced explicit requirements for payment page script integrity monitoring under Requirements 6.4.3 and 11.6.1. The customized implementation path allows alternative control designs, but each requires a documented risk analysis and testing methodology acceptable to an assessor.

Enforcement runs through card brands (Visa, Mastercard, American Express, Discover, JCB) via merchant acquirers. Non-compliance results in fines levied on acquirers and passed down to merchants, potential transaction fee increases, mandatory forensic investigations after a breach, and in severe cases, loss of card processing privileges. Fine structures vary by card brand and merchant level but can reach $100,000 per month for Level 1 merchants in sustained non-compliance. Post-breach liability shifts significantly — compliant organizations have limited liability exposure on fraudulent transactions; non-compliant organizations absorb the card brand''s fraud losses and investigation costs.

The full standard is the source document for all SAQ types. Every control in every SAQ is drawn from this document. Organizations subject to the full ROC path cannot substitute SAQ completion in lieu of a QSA-led assessment, regardless of how thoroughly they complete the questionnaire.

PCI DSS 4.0.1 SAQ A

Card-not-present merchants — predominantly e-commerce — that have fully outsourced all cardholder data functions to PCI DSS-compliant third parties. The merchant''s website must redirect customers entirely to a third-party payment page, or embed a compliant third-party-hosted iframe in a way that ensures cardholder data never passes through merchant systems and the merchant''s page cannot affect the security of the payment transaction.

Merchants using JavaScript-embedded payment fields, tag managers that load before or during payment page rendering, or analytics scripts with access to form field data misclassify themselves as SAQ A eligible. The iframe or redirect architecture is valid, but the presence of merchant-controlled JavaScript that executes in the same browser session as the payment page eliminates eligibility. In our assessments, approximately 35% of merchants self-filing as SAQ A have at least one JavaScript component that an assessor would flag as affecting payment page security.

SAQ A covers a limited subset of PCI DSS requirements: maintaining compliant relationships with payment processors, ensuring the payment page is hosted by a validated third party, securing the merchant environment against malware, and maintaining basic policies. It does not require vulnerability scanning of merchant systems, penetration testing, or detailed logging controls. It is the shortest SAQ form.

SAQ A is self-administered and submitted to the merchant''s acquirer. If a breach occurs and forensic investigation determines the merchant did not qualify for SAQ A — because, for example, a script on the merchant page could interact with the payment flow — the acquirer and card brands treat the organization as non-compliant at the time of the breach. All financial liability follows from that determination.

SAQ A is a strict subset of PCI DSS. Merchants whose pages influence payment security fall into SAQ A-EP. The technical boundary between SAQ A and SAQ A-EP is the question of whether any merchant-controlled code executes in the same browser context as the payment data entry. If yes, the merchant is not SAQ A eligible.

PCI DSS 4.0.1 SAQ A-EP

E-commerce merchants whose website does not directly receive cardholder data but whose page is involved in the payment flow — through direct post methods, JavaScript-hosted payment fields embedded on the merchant page, or any architecture where the merchant''s web infrastructure could theoretically affect how cardholder data is captured. The critical distinction from SAQ A is that the merchant page participates in the transaction even if it does not capture card numbers.

The most common failure is not completing the form wrong — it is not completing this form at all. Merchants that should be here are filing SAQ A instead. The second most common failure among merchants who do correctly identify as SAQ A-EP is treating the script inventory requirement as a one-time exercise. Scripts change. Third-party tag managers introduce new scripts continuously. A script inventory built in January is likely incomplete by April.

SAQ A-EP requires significantly more controls than SAQ A: vulnerability scanning of merchant-facing systems, penetration testing, web application security controls, malware protection, access controls, and — under v4.0.1 — explicit compliance with Requirements 6.4.3 and 11.6.1 covering payment page script inventory and integrity monitoring. The merchant must demonstrate their website has not been compromised and that controls prevent unauthorized script injection.

Same enforcement mechanism as other SAQ types. The additional risk for SAQ A-EP merchants is that this form is frequently misclassified downward to SAQ A, which means organizations that should be performing penetration testing and script monitoring are not doing so. When a Magecart-style attack occurs against one of these merchants, the forensic investigation quickly establishes they were not SAQ A eligible — converting their self-assessed compliance into documented non-compliance at exactly the moment liability is determined.

SAQ A-EP sits between SAQ A and SAQ C in terms of scope and burden. Merchants whose systems are internet-connected and process payments through application software rather than hosted fields move to SAQ C. The line between A-EP and C is the presence of a payment application running on merchant infrastructure versus a merchant webpage that serves as a conduit to a third-party capture mechanism.

PCI DSS 4.0.1 SAQ B

Merchants that accept cards only through imprint machines (the old mechanical card stamping devices) or standalone dial-out terminals — meaning phone-line connected, not IP-connected — with no electronic storage of cardholder data whatsoever. This is a deliberately narrow category. It describes a physical retail model that predates internet-connected payment infrastructure.

Terminal replacement without a compliance review. A merchant files SAQ B, then their processor sends them a new IP-connected terminal to replace the aging dial-up unit. The merchant continues filing SAQ B. The architecture has changed; the compliance path has not.

SAQ B covers physical security of terminal devices, protection against device tampering and substitution, and basic policy requirements. Because these terminals have no network connectivity, the control surface is genuinely small. No requirements for firewalls, network segmentation, vulnerability scanning, or application security.

Standard acquirer-based enforcement. The practical risk for SAQ B filers is misidentifying their terminal type. A dial-out terminal that has been upgraded or replaced with an IP-connected model — which happens when processors upgrade terminal fleets — moves the merchant out of SAQ B eligibility without necessarily triggering a compliance review.

SAQ B is the physical-only analog to SAQ A''s e-commerce focus. Both represent minimum-scope paths for specific, narrow architectures. SAQ B-IP covers the next step up — IP connectivity — and brings meaningfully more controls into scope.

PCI DSS 4.0.1 SAQ B-IP

Merchants using standalone, IP-connected payment terminals that are PCI PTS-approved, where the terminals are isolated from all other network systems and no cardholder data is stored electronically. The IP connection introduces network-based attack surface that dial-out terminals do not have, which is why this SAQ is longer than SAQ B.

The terminal is IP-connected, PTS-approved, and sitting on the same network segment as the point-of-sale system, the inventory management server, and the back-office workstations. The merchant''s network team configured the terminal when it arrived and moved on. No formal isolation was validated. The merchant files SAQ B-IP. A network scan during assessment reveals the terminal can communicate with at least three non-payment systems. That is not isolation.

SAQ B-IP requires network security controls to isolate the terminal, confirmation that PTS-approved devices are in use and listed on the PCI SSC''s approved device list, protection against physical tampering, and basic authentication and policy controls. It does not require full network segmentation validation or penetration testing, but it does require that the terminal''s network connectivity is isolated from business systems.

Acquirer-enforced. The specific risk here is that IP-connected terminals in retail environments are rarely as isolated as merchants believe. Shared network segments, VLAN configurations that drift, and printer or POS system interconnections frequently create connectivity between terminal and non-terminal systems.

SAQ B-IP sits between SAQ B and SAQ C. The distinguishing factor from SAQ C is that SAQ B-IP applies only to standalone terminals — not to payment application software running on general-purpose computers. Once a payment application runs on a computer that also handles other business functions, SAQ C or SAQ D territory begins.

PCI DSS 4.0.1 SAQ C

Merchants with payment application systems connected to the internet, where the cardholder data environment is properly segmented from other network systems and no cardholder data is stored electronically. This typically covers retail merchants running payment software on a POS system that connects to the internet for authorization, where the payment network is separated from the general business network.

Merchants implement network segmentation at installation — firewall rules, VLANs, dedicated payment network — and then do not test or validate that segmentation after subsequent infrastructure changes. Two years later, a network printer gets added to the payment VLAN for convenience. A shared file server develops a route into the payment network because someone needed access during a troubleshooting session. The segmentation record says ''segmented.'' The network says otherwise.

SAQ C covers firewall configuration, patch management, malware defenses, secure system development practices, access controls, physical security, monitoring, and incident response. It is a materially more demanding form than SAQ B or B-IP. Network segmentation is not just recommended — it is a qualifying condition. Without demonstrated segmentation, the merchant falls into SAQ D.

Acquirer-enforced. Segmentation failures are the most common reason SAQ C filers are escalated to SAQ D requirements during assessments or post-breach forensics. Segmentation that exists on paper but has not been validated through testing provides no qualifying protection.

SAQ C requires segmentation that SAQ B-IP does not formally require to the same depth. SAQ C also covers payment application software, not just hardware terminals. The line between SAQ C and SAQ D is cardholder data storage — SAQ C is only available to merchants that store no cardholder data electronically. Anything that touches stored card data goes to SAQ D.

PCI DSS 4.0.1 SAQ C-VT

Merchants that accept card payments exclusively through a web browser-based virtual terminal provided by a payment processor. The merchant enters cardholder data directly into the payment service provider''s website — they never handle card data in their own systems. The computer used for virtual terminal access must be dedicated solely to that function and isolated from other business systems.

The virtual terminal computer is also the office computer. It processes payments through the browser-based terminal, handles email through the same browser, and is used by multiple staff members throughout the day. There is no isolation. The entire value of the C-VT model — that the merchant''s environment is minimal because data goes straight to the processor — depends on that computer not being a general-purpose workstation. In practice, that condition is violated in the majority of C-VT environments we review.

SAQ C-VT covers the security of the single computer used for virtual terminal access: malware protection, patch management, browser security, physical security of the workstation, account and password controls, and basic policy requirements. Because data entry goes directly to the payment processor''s environment, merchant system controls are focused on the integrity of the access point, not on a cardholder data environment.

Acquirer-enforced. The specific enforcement risk is that the dedicated-computer requirement is almost never maintained in practice. Small merchants using virtual terminals use those same computers for email, web browsing, and administrative tasks, which eliminates the isolation the SAQ requires.

SAQ C-VT is conceptually closest to SAQ A in that both models route cardholder data entirely through third-party infrastructure. The difference is the mechanism: SAQ A uses browser-side redirection or iframe; SAQ C-VT uses direct keyboard entry into a processor-hosted web interface. Both models require genuine isolation to maintain their narrow scope.

PCI DSS 4.0.1 SAQ P2PE

Merchants using hardware payment terminals within a solution that appears on the PCI SSC''s list of validated Point-to-Point Encryption solutions. The P2PE solution encrypts cardholder data at the point of card interaction inside the hardware terminal, before it ever enters the merchant''s network. This reduces the merchant''s cardholder data environment to near zero.

Merchants implement encryption at the terminal level using a vendor product they were told is ''P2PE compliant'' without verifying that the solution appears on the PCI SSC''s published list. The solution may genuinely encrypt data from swipe to processor. It may even use strong, current cryptographic standards. But if it is not on the validated solutions list, the merchant is not P2PE SAQ eligible. They are filing the wrong form while leaving network controls unimplemented.

SAQ P2PE is one of the shortest SAQs, covering physical security of the P2PE terminals, the process for managing and replacing terminals, basic account security on systems adjacent to terminals, and policy requirements. It explicitly does not cover network security controls because — if the P2PE solution is implemented correctly — there is no cardholder data on the merchant network for network controls to protect.

Acquirer-enforced. The critical enforcement point is that only PCI-listed P2PE solutions qualify. A merchant using a vendor''s encryption product that is not on the PCI SSC P2PE validated solutions list does not qualify for SAQ P2PE, regardless of how strong the encryption is. The listing status, not the technical quality of the encryption, determines eligibility.

SAQ P2PE represents the most aggressive scope reduction path available for card-present merchants. A merchant who switches from a standard IP-connected terminal (SAQ B-IP or SAQ C) to a PCI-listed P2PE solution can potentially drop to SAQ P2PE — but only if they implement the P2PE solution exactly as the solution provider''s instructions specify. Deviations from those instructions, including using the terminal in an unapproved configuration, void P2PE eligibility.

PCI DSS 4.0.1 SAQ D Merchant

Merchants that do not qualify for any other SAQ type. This includes merchants that store cardholder data electronically in any form, merchants with complex payment environments that span multiple integration types, merchants whose network segmentation is insufficient to support SAQ C eligibility, and merchants whose payment infrastructure involves multiple channels. SAQ D Merchant is the catch-all.

Organizations that graduate from SAQ A or SAQ C to SAQ D because their architecture changed — they started storing tokens, integrated a new sales channel, or brought payment processing in-house — frequently underestimate the additional control burden. They treat SAQ D as SAQ C plus a few extra questions. The reality is that several entire control domains become relevant for the first time: key management, data retention and purge processes, formal vulnerability management programs, and penetration testing requirements.

SAQ D Merchant covers all 12 PCI DSS control domains — every requirement in the standard that applies to merchants. This includes network controls, secure configuration, data protection, cryptographic key management, malware defenses, application security, access control, authentication, physical security, logging and monitoring, vulnerability testing programs, and information security policy and governance. Under v4.0.1, it also includes the targeted risk analysis requirements for controls using the customized implementation path.

Acquirer-enforced. SAQ D Merchant is the longest and most demanding self-assessment a merchant faces. Acquirers may require an Attestation of Compliance alongside the completed questionnaire. For merchants that have grown their processing volumes or complexity without a corresponding compliance upgrade, SAQ D requirements often expose significant gaps that shorter SAQ paths masked.

SAQ D Merchant is distinct from SAQ D Service Provider. The two forms cover the same underlying PCI DSS requirements but include different organization-specific requirements, different AOC structures, and reflect different risk profiles. A merchant that also provides payment services to other merchants — becoming a service provider in the process — may need to satisfy both forms or transition to the ROC path.

PCI DSS 4.0.1 SAQ D Service Provider

Service providers — including managed service providers, hosting companies, payment gateways, and processing intermediaries — that store, process, or transmit cardholder data on behalf of merchants and are eligible for self-assessment rather than a full QSA-led ROC. Not all service providers qualify for self-assessment; card brands and acquirers set eligibility thresholds that often push larger or higher-risk service providers to the full ROC path.

Service providers completing SAQ D rather than pursuing a full ROC when their transaction volumes or client counts actually require the higher-assurance path. The motivation is obvious — SAQ is faster and cheaper than a QSA-led ROC. The risk is that a service provider handling cardholder data for hundreds of merchants with a self-assessed compliance posture represents a systemic risk that the SAQ path was not designed to validate.

SAQ D Service Provider covers all PCI DSS requirements applicable to service providers and adds requirements not present in the merchant SAQ D: executive responsibility for PCI DSS compliance programs, additional incident response requirements, third-party service provider management obligations, and penetration testing that covers both external and internal network layers. Service providers also carry obligations around how they communicate their compliance status to their merchant customers.

Card brands enforce service provider compliance through their registered agent programs. Visa''s Global Registry of Service Providers and similar brand-specific registries list compliant service providers. Merchants are expected to use only listed service providers for functions that affect their CDE. A service provider that loses its listed status — because its AOC lapses or a compliance assessment fails — can trigger cascading compliance problems for every merchant that relies on it.

SAQ D Service Provider sits at the top of the PCI DSS compliance burden hierarchy. It covers more controls than SAQ D Merchant, carries additional executive accountability requirements, and has more demanding third-party management obligations. Organizations that straddle the merchant and service provider categories — a retailer that also processes payments for affiliated brands, for example — need to assess which role governs their compliance obligations for each function.

SAQ A-EP adds explicit requirements around payment page script integrity monitoring (Requirements 6.4.3 and 11.6.1) that SAQ C does not include because SAQ C is built for payment application software, not browser-based payment pages. A merchant moving from an e-commerce model under SAQ A-EP to a physical retail model under SAQ C must re-examine which controls apply — script monitoring goes away, but network segmentation validation becomes a qualifying condition.

Web application and system security — vulnerability scanning, patch management, and secure development practices appear across all three forms. An organization that builds solid patch management and vulnerability scanning processes for SAQ C qualification carries those controls forward intact if it later grows into SAQ D territory. The investment is not wasted; the scope expands.

SAQ P2PE explicitly does not require network security controls that both SAQ B-IP and SAQ C mandate. A merchant switching from SAQ C to SAQ P2PE through adoption of a listed P2PE solution can remove network segmentation controls, firewall configuration reviews, and vulnerability scanning from their compliance program — but only because the P2PE solution has genuinely eliminated the network-resident cardholder data that those controls were protecting.

Physical security of payment terminals — all three forms require controls around device tamper detection, terminal inventory, and processes for handling suspicious or potentially compromised devices. This control cluster appears because physical terminal compromise is a consistent attack vector across all card-present environments regardless of network architecture.

Service provider-specific requirements in SAQ D Service Provider include executive designation for PCI DSS program ownership, penetration testing scope that explicitly covers multi-tenant segmentation between customer environments, and a responsibility matrix for communicating which PCI DSS controls the service provider manages versus which the merchant must handle. None of these appear in SAQ D Merchant.

All 12 PCI DSS control domains appear in both forms. A service provider that also operates as a merchant — running its own retail or e-commerce channel — shares a large control base across both obligations. Logging infrastructure, access control frameworks, and cryptographic key management built for one role satisfy the same requirements in the other.

Treating SAQ selection as a business decision rather than an architecture determination

SAQ selection is almost universally handled by finance, legal, or compliance teams without meaningful input from the engineers who built the payment infrastructure. Those teams see a list of SAQ types, observe that SAQ A involves fewer questions than SAQ D, and work backward to determine whether the business qualifies. They are starting from the answer rather than the architecture. The question is not ''can we qualify for SAQ A?'' — the question is ''what does our payment architecture actually look like, and which SAQ type was designed for that architecture?'' Those are different questions with different starting points.

Merchants complete detailed, internally consistent SAQ filings that are entirely wrong for their actual environment. Acquirers accept them because acquirers generally do not have the technical capacity to verify architectural claims made in self-assessments. The merchant believes it is compliant. Its payment infrastructure has never been assessed against the controls that actually apply to its architecture. The first external verification of the real compliance posture often occurs during a post-breach forensic investigation.

Validating compliance once per year instead of maintaining it continuously

The PCI DSS annual assessment cycle creates a powerful psychological frame: compliance is something you achieve for the assessment and then maintain until the next one. This is reinforced by how acquirers request attestations — once a year. The result is that organizations treat control maintenance as an annual exercise rather than an operational practice. Configuration changes, new system integrations, vendor swaps, and network modifications happen throughout the year without triggering a compliance review.

The cardholder data environment documented in a January assessment may bear little resemblance to the actual environment in October. New systems get connected. Firewall rules get modified. Segmentation degrades. Patch management lapses between cycles. When a breach occurs in November, the forensic investigation does not compare the environment to the January documentation — it examines the November environment. Compliance posture at assessment time provides no protection for the 11 months of drift that follow.

Assuming outsourcing eliminates PCI DSS obligations

The architecture of SAQ A — where the merchant outsources all cardholder data functions and the form is very short — creates a mental model where more outsourcing equals less compliance burden. Merchants apply that logic more broadly than it works. They outsource their payment processing, their hosting, and their network management, and believe they have outsourced their compliance obligations along with those functions.

PCI DSS does not allow compliance obligations to be fully outsourced. What can be outsourced is the implementation of specific controls — but the merchant retains responsibility for verifying that those controls are in place and functioning at their service providers. A merchant using five PCI-compliant service providers who never validates those providers'' compliance status, never reviews their AOCs, and never assesses how those providers'' controls interact with their own environment has an administrative compliance record and a broken actual security posture.