PCI DSS SAQ Types Explained (A, A-EP, B, B-IP, C, C-VT, D, P2PE)

Choosing the right PCI DSS SAQ

The PCI SSC publishes nine Self-Assessment Questionnaires (SAQs) to give eligible merchants and service providers a validation path that is scoped to their actual card acceptance profile. The right SAQ is the one that matches how card data actually enters, flows through, and leaves your environment. Picking the wrong SAQ is a common PCI DSS mistake -- one that becomes visible during breach investigation, acquirer review, or a subsequent move to a Report on Compliance.

SAQ selection starts with three questions: which channels do you use to accept cards, what technology handles card data on each channel, and do you store any cardholder data after the transaction. The answers drive which SAQ you are eligible for and which controls apply.

All SAQ types at a glance

The table below summarizes the current PCI DSS v4.0 SAQ family. Question counts are approximate and vary slightly between minor revisions of PCI DSS; always confirm with the current SAQ document on the PCI SSC website. Each SAQ includes an Attestation of Compliance that must accompany it.

Exact question counts vary across PCI DSS revisions and between the defined and customized approaches.

SAQ A - fully outsourced e-commerce and MOTO

SAQ A is the shortest SAQ and the target of most e-commerce scope reduction efforts. To qualify for SAQ A your website must either redirect customers entirely to the processor's hosted page or use a direct post or hosted iframe where the processor's infrastructure handles all cardholder data. Your servers never see the PAN. SAQ A applies only to card-not-present channels; card-present merchants cannot use SAQ A.

PCI DSS v4.0 expanded SAQ A to include controls that protect the payment page from e-skimming and script-tampering attacks. Even when the PAN never touches your servers, a compromised script on the page can capture card data before it ever reaches the processor. SAQ A now includes testing procedures related to Requirement 6.4.3 and 11.6.1 to address this risk.

SAQ A-EP - partial outsourcing with payment-page influence

SAQ A-EP is longer than SAQ A because the merchant has more ability to affect payment security. An A-EP merchant typically hosts the checkout page that loads the processor's iframe or JavaScript. The PAN never transits merchant infrastructure in a meaningful way, but scripts and pages hosted by the merchant are in a position to intercept or manipulate card data if compromised. SAQ A-EP applies e-commerce-relevant PCI DSS controls across access control, vulnerability management, network security, and logging -- roughly five times the work of SAQ A.

SAQ B and SAQ B-IP - standalone terminals

SAQ B is designed for very low-complexity card-present merchants using only imprint machines or standalone dial-out terminals. It is rare today and largely a legacy artifact.

SAQ B-IP covers merchants using only standalone IP-connected terminals approved under the PCI PTS program, where the terminals connect to the processor over IP but do not route through a merchant's payment application. The merchant environment around the terminal is smaller than C, but IP-connected terminals carry more risk than dial-out devices, so the SAQ is longer than SAQ B.

SAQ C-VT - virtual terminals

SAQ C-VT is for merchants who key in transactions one at a time on a web-based virtual payment terminal operated by a PCI DSS-validated service provider. Typical users are professional services firms or small service businesses that take occasional card-present transactions through a computer and a web browser. SAQ C-VT has specific eligibility conditions -- including that the computer used for virtual terminal access is isolated and dedicated to that purpose.

SAQ C - integrated payment applications

SAQ C is for merchants with integrated payment applications that connect to the internet. The PAN transits merchant systems in transit but is not stored. SAQ C is substantially longer than SAQ B-IP because the merchant's environment includes more components that can affect payment security -- the POS, the network, the supporting infrastructure. SAQ C is common for small-to-mid-size brick-and-mortar retailers with integrated POS platforms.

SAQ P2PE - validated point-to-point encryption

SAQ P2PE is the payoff for adopting a PCI SSC-listed Point-to-Point Encryption solution. When all card acceptance flows through a listed P2PE solution, the merchant's environment between terminal and processor is removed from PCI DSS scope and SAQ P2PE covers the remaining obligations -- primarily terminal management, physical security, and incident response. SAQ P2PE is one of the shortest SAQs and a favorite of retail chains that can standardize on a single P2PE platform.

SAQ D - the catch-all

SAQ D applies when the merchant or service provider does not fit any other SAQ, or when cardholder data is stored. SAQ D for Merchants covers every applicable PCI DSS requirement; SAQ D for Service Providers adds service-provider-specific obligations. SAQ D is the longest self-assessment questionnaire and, in effort terms, is close to a Report on Compliance without the QSA signature. Many Level 2 merchants and smaller service providers complete SAQ D annually.

How this fits into PCI DSS compliance

The SAQ is your PCI DSS validation deliverable. Every merchant and service provider that does not owe a Report on Compliance owes one of the SAQs plus its Attestation of Compliance. The SAQ must be signed by an executive officer and submitted to your acquirer on the cadence your acquirer specifies -- typically annually. Getting the SAQ wrong has material consequences: your acquirer may reject it, your card brands may revalidate your level, or a breach investigation may discover that the SAQ you filed did not match your actual environment.

The SAQ also drives control effort. A merchant eligible for SAQ A can often run a PCI DSS program with a handful of controls and a tight scoping narrative. A merchant on SAQ D is running essentially the same program a Level 1 merchant runs, minus the QSA on-site. The difference between SAQ tiers is often more impactful than the difference between merchant levels.

Common mistakes

• Self-selecting a simpler SAQ than your architecture supports -- for example, filing SAQ A while hosting scripts that influence the payment page.
• Ignoring e-skimming controls introduced under PCI DSS v4.0 for SAQ A and A-EP merchants.
• Confusing hosted-page with iframe-hosted checkouts. They are not always the same SAQ.
• Missing PTS validation for standalone terminals claimed under SAQ B or B-IP.
• Using non-dedicated workstations for virtual terminal access under SAQ C-VT.
• Failing to revalidate the SAQ when channels change -- a new mobile app, a new acquisition, or a new recurring-billing capability can all move you to a different SAQ.
• Treating SAQ D as a checkbox instead of a full PCI DSS program. SAQ D scope is nearly the same as a ROC.
• Using outdated SAQ versions when the PCI SSC has released an updated SAQ aligned with the current PCI DSS version.
• Signing the Attestation of Compliance without reviewing every answer with the control owners.

How episki helps

episki keeps your SAQ answers alive throughout the year, linking each question to the evidence and control owner that supports it. When the year-end SAQ is due, you are not assembling answers from memory -- you are confirming the position the platform has been maintaining all along. See the PCI DSS hub for how SAQ workflows fit into a year-round PCI DSS program.