PCI-DSS SAQ types explained: selecting the right self-assessment questionnaire

The PCI-DSS Self-Assessment Questionnaire (SAQ) is a validation tool for merchants and service providers who are eligible to assess their own PCI compliance rather than undergoing a full Report on Compliance (ROC) audit by a Qualified Security Assessor (QSA).

SAQ eligibility depends on transaction volume, payment channel, and how cardholder data is handled. Merchants processing fewer than 6 million Visa or Mastercard transactions annually are generally eligible for SAQ, though acquirers may impose additional requirements.

Selecting the wrong SAQ type is a common compliance failure. Using SAQ A when your environment actually requires SAQ D creates a false compliance posture that acquirers, partners, and QSAs will identify during validation.

SAQ A applies to e-commerce merchants who have fully outsourced all cardholder data functions to PCI-validated third-party service providers, with no electronic storage, processing, or transmission of cardholder data on the merchant's systems or premises.

This is the simplest SAQ with approximately 22 requirements focused on service provider management, policies, and physical security. It applies to merchants using payment processors like Stripe Checkout, PayPal hosted checkout, or similar fully outsourced models.

Eligibility requires that the merchant's website does not directly receive cardholder data. Payment pages must redirect to or embed validated third-party collection methods where card data bypasses the merchant's infrastructure entirely.

SAQ A-EP applies to e-commerce merchants who partially outsource payment processing but whose website can impact the security of payment transactions. This typically occurs when merchants use JavaScript-based payment forms (like Stripe Elements) that are served from the merchant's domain.

SAQ A-EP contains approximately 191 requirements, substantially more than SAQ A. Requirements include vulnerability management, secure development, change management, and monitoring controls for the merchant's web environment.

The distinction between SAQ A and SAQ A-EP depends on whether the merchant's website directly interacts with the cardholder's browser during payment. If your payment page is served from your domain and includes JavaScript that handles payment fields, SAQ A-EP likely applies.

SAQ B applies to merchants using only imprint machines or standalone dial-out terminals with no electronic cardholder data storage. This is increasingly rare in digital commerce but remains relevant for certain retail and service business models.

SAQ B-IP applies to merchants using standalone IP-connected payment terminals with no electronic cardholder data storage. Requirements focus on terminal security and network segmentation.

SAQ C applies to merchants whose payment application systems are connected to the internet but do not store electronic cardholder data. SAQ C-VT is a variant for merchants using virtual terminal solutions accessed by individual computers.

SAQ P2PE applies to merchants using validated Point-to-Point Encryption solutions with approved payment terminals. P2PE significantly reduces PCI scope by encrypting card data at the point of interaction.

SAQ D applies to all merchants not eligible for any other SAQ type. It contains all applicable PCI-DSS requirements (approximately 250+ for merchants) and represents full PCI compliance scope.

Merchants requiring SAQ D include those who store cardholder data electronically, process card-present transactions with custom payment applications, operate as payment facilitators, or have complex payment architectures that do not fit other SAQ categories.

Service providers (entities that store, process, or transmit cardholder data on behalf of other entities) use SAQ D variants: SAQ D for Merchants or SAQ D for Service Providers, depending on their role in the payment chain.

Follow the PCI SSC's SAQ eligibility criteria document to determine your SAQ type. The decision tree considers: payment channels used, whether cardholder data is stored, whether processing is outsourced, and whether validated P2PE solutions are deployed.

Document your SAQ selection rationale including: payment architecture diagram, data flow showing where cardholder data enters and exits your environment, list of payment service providers with their PCI validation status, and explicit statement of which SAQ eligibility criteria you meet.

Engage your acquiring bank or payment processor for SAQ type confirmation. Some acquirers require specific SAQ types regardless of eligibility criteria, particularly for higher-volume merchants approaching the 6 million transaction threshold.

• Map all payment data flows from card entry to settlement
• Identify every system that stores, processes, or transmits cardholder data
• Document payment service providers and their PCI validation status
• Apply PCI SSC SAQ eligibility criteria decision tree
• Confirm SAQ type with acquiring bank or payment processor

Complete your SAQ annually or upon significant environment changes. Each SAQ includes an Attestation of Compliance (AOC) that an authorized officer must sign, confirming that the assessment was performed accurately and that all applicable requirements are met.

Maintain evidence supporting every 'in place' response in your SAQ. Acquirers and QSAs may request evidence during validation. Evidence includes policies, configuration screenshots, scan reports, penetration test results, and access review records.

Quarterly ASV external vulnerability scans are required for most SAQ types (SAQ A is typically exempt). Internal vulnerability scans and penetration testing requirements vary by SAQ type, with SAQ D requiring the most comprehensive testing program.