PCI DSS
8 min read
PCI DSS Self-Assessment Questionnaire (SAQ) Guide: Types, Eligibility & How to Complete
The Self-Assessment Questionnaire (SAQ) is the primary compliance validation tool for PCI DSS Level 2, 3, and 4 merchants. Choosing the correct SAQ type is critical because it determines which PCI DSS requirements you must validate against. Completing the wrong SAQ or incorrectly assessing your eligibility can result in non-compliant status even if your security controls are adequate. This guide explains each SAQ type, helps you determine which one applies to your organization, and provides practical guidance for completing the questionnaire accurately.
Table of Contents
Overview of SAQ Types
PCI DSS defines eight SAQ types, each designed for specific payment processing environments. The questionnaires range from SAQ A with approximately 22 questions to SAQ D with over 300 questions. The type you need depends entirely on how your organization stores, processes, and transmits cardholder data, not on your merchant level or transaction volume. SAQ A is for merchants that have fully outsourced all cardholder data functions to PCI DSS validated third parties with no electronic storage, processing, or transmission on the merchant's systems. SAQ A-EP targets e-commerce merchants that partially outsource payment processing but whose website can impact the security of the payment transaction. SAQ B covers merchants using only imprint machines or standalone dial-out payment terminals. SAQ B-IP is for merchants using only standalone IP-connected payment terminals. SAQ C applies to merchants with payment application systems connected to the internet but no electronic cardholder data storage. SAQ C-VT is for merchants that manually enter single transactions via a virtual terminal on an isolated computer. SAQ D is the comprehensive catch-all for all merchants not fitting other categories and for service providers. SAQ P2PE applies to merchants using validated point-to-point encryption solutions managed by the P2PE solution provider.
- Eight SAQ types ranging from 22 questions (SAQ A) to 300+ questions (SAQ D)
- SAQ type is determined by payment processing method, not merchant level or volume
- SAQ A requires full outsourcing with no cardholder data on merchant systems
- SAQ D is the comprehensive catch-all for complex environments
- SAQ P2PE is available for merchants using validated point-to-point encryption hardware
SAQ A and SAQ A-EP: E-Commerce Merchants
SAQ A is the simplest questionnaire and applies to card-not-present merchants (e-commerce, mail-order, telephone-order) that have fully outsourced all payment processing to PCI DSS compliant third parties. The merchant's systems do not store, process, or transmit cardholder data in any form. In an e-commerce context, this typically means the customer is redirected to a third-party hosted payment page (like Stripe Checkout or PayPal) for the entire payment interaction. The merchant's website never handles, sees, or touches cardholder data. SAQ A-EP addresses a gap between SAQ A and SAQ D for e-commerce merchants that outsource payment processing but whose website elements could impact the security of the payment transaction. This is common when merchants use embedded payment iframes or JavaScript libraries that load payment forms within the merchant's web page. Although the merchant does not directly handle cardholder data, their website code could be modified by an attacker to capture card data before it reaches the payment processor. SAQ A-EP is significantly more extensive than SAQ A, covering requirements related to web server security, change management, vulnerability scanning, and penetration testing of the e-commerce environment. The distinction between SAQ A and A-EP has become increasingly important as payment page skimming attacks (Magecart-style) have proliferated, targeting exactly the scenario that SAQ A-EP was designed to address.
- SAQ A requires full redirect to third-party hosted payment page with no cardholder data touching merchant systems
- SAQ A-EP applies when merchant website elements could impact payment transaction security
- Embedded iframes and JavaScript payment libraries typically require SAQ A-EP, not SAQ A
- SAQ A-EP is significantly more extensive, covering web server security and penetration testing
- Payment page skimming attacks (Magecart) target the scenario that SAQ A-EP addresses
SAQ B, B-IP, C, and C-VT: Physical and Terminal-Based Merchants
SAQ B applies to merchants using only standalone dial-out payment terminals or imprint machines with no electronic cardholder data storage. The terminals must connect via phone line only and must not be connected to any other systems or the internet. SAQ B-IP covers merchants using only standalone IP-connected point-of-sale terminals, such as those connecting over Ethernet or WiFi to the payment processor. The terminals must not be connected to any other systems in the merchant environment, and the merchant must not store electronic cardholder data. SAQ C applies to merchants with payment application systems (such as a point-of-sale system with a computer component) connected to the internet, but who do not store cardholder data electronically. This is common for small retail environments using PC-based POS systems. SAQ C-VT is designed for merchants who manually enter single payment card transactions via a keyboard into a web-based virtual terminal provided by a PCI DSS validated third party. The virtual terminal must be accessed from an isolated computer that is not connected to other systems in the merchant environment. The computer must be dedicated to the virtual terminal function and must not be used for general web browsing or email. Each of these SAQ types has specific eligibility criteria that must be strictly met; if any criterion is not satisfied, the merchant must use a more comprehensive SAQ type, potentially SAQ D.
- SAQ B: standalone dial-out terminals or imprint machines only, no internet connection
- SAQ B-IP: standalone IP-connected terminals not connected to other merchant systems
- SAQ C: internet-connected POS systems with no electronic cardholder data storage
- SAQ C-VT: single transactions manually entered into a web-based virtual terminal on an isolated computer
- Failure to meet any eligibility criterion requires moving to a more comprehensive SAQ type
SAQ D and SAQ P2PE
SAQ D is the most comprehensive SAQ and serves as the catch-all for merchants that do not qualify for any other SAQ type and for service providers eligible for self-assessment. With over 300 questions covering all applicable PCI DSS requirements, SAQ D is essentially a self-assessed version of the full Report on Compliance. Merchants need SAQ D if they store cardholder data electronically, process cardholder data on their own systems, have complex payment environments spanning multiple channels, or simply do not meet the eligibility criteria for any other SAQ type. SAQ D requires the merchant to address requirements across all 12 PCI DSS requirement families, including access control, network security, encryption, monitoring, and incident response. SAQ P2PE provides a streamlined alternative for merchants that use a validated PCI-listed Point-to-Point Encryption solution. P2PE encrypts cardholder data at the point of interaction (the terminal) and the data remains encrypted through the merchant environment until it reaches the secure decryption environment managed by the P2PE solution provider. Because the merchant never has access to cleartext cardholder data, the SAQ P2PE questionnaire is relatively short and focused on physical terminal security and policies. The P2PE solution must appear on the PCI SSC's list of validated P2PE solutions. Using a terminal that supports encryption but is not part of a validated P2PE solution does not qualify.
- SAQ D covers all PCI DSS requirements with 300+ questions for complex environments
- Merchants that store cardholder data electronically must use SAQ D
- SAQ P2PE is available only when using a PCI-listed validated P2PE solution
- P2PE encrypts data at the terminal with no cleartext accessible in the merchant environment
- Service providers eligible for self-assessment also use SAQ D
How to Complete an SAQ: Step-by-Step
Completing an SAQ accurately requires preparation and methodical execution. Step one: confirm your SAQ type with your acquiring bank before beginning, as they have final authority on which SAQ applies to your processing environment. Step two: review the eligibility criteria on the first page of your SAQ to confirm you meet every criterion. If you cannot confirm any criterion, you may need a different SAQ type. Step three: conduct an inventory of all systems, applications, and processes within your cardholder data environment to understand what is in scope for each question. Step four: work through each requirement systematically, providing honest answers. For each requirement, you must indicate whether it is In Place, In Place with Compensating Control, Not Applicable, or Not in Place. Do not mark a requirement as In Place unless you have evidence that the control is fully implemented and operating effectively. Step five: for any requirement marked Not Applicable, document the justification in the provided space, as assessors and acquirers may question N/A responses. Step six: for any compensating controls, complete the Compensating Controls Worksheet with detailed information about why the original requirement cannot be met and how the compensating control provides equivalent protection. Step seven: have an authorized officer of the company sign the Attestation of Compliance, confirming the accuracy of the assessment. Step eight: submit the completed SAQ and AOC to your acquiring bank per their specified process and timeline.
- Confirm SAQ type with your acquiring bank before beginning the assessment
- Verify all eligibility criteria are met before proceeding with the questionnaire
- Only mark requirements as In Place with evidence of full implementation and operation
- Document justification for all Not Applicable responses
- Complete Compensating Controls Worksheets for any alternative controls used
Common SAQ Mistakes and How to Avoid Them
The most frequent mistake in SAQ completion is selecting the wrong SAQ type, often choosing a simpler version than the organization's processing environment warrants. This is sometimes intentional to reduce compliance burden, but it exposes the organization to findings of non-compliance. Always confirm your SAQ type with your acquirer. The second most common mistake is marking requirements as In Place without adequate evidence. Each In Place response should be supported by documented policies, procedures, system configurations, or other evidence that the control exists and is operating effectively. Another frequent error is misunderstanding the scope of the assessment, particularly which systems and networks are in scope. Organizations that have not properly identified and documented their cardholder data environment may exclude systems that should be included. Treating the SAQ as an annual checkbox exercise rather than a meaningful security assessment undermines its purpose and leaves the organization exposed to real security risks. Organizations should use the SAQ process as an opportunity to validate their security controls, identify weaknesses, and drive improvements. Finally, failing to maintain compliance throughout the year between annual SAQ submissions is a common pitfall. PCI DSS compliance is a continuous obligation, and controls must be operating effectively at all times, not just during the assessment period.
- Selecting the wrong SAQ type is the most common and consequential mistake
- Every In Place response should be supported by documented evidence
- Properly defining CDE scope is critical to avoid excluding in-scope systems
- The SAQ should be a meaningful security assessment, not an annual checkbox
- PCI DSS compliance is continuous; controls must operate effectively year-round
Key Takeaways
- Eight SAQ types cover different payment processing environments from fully outsourced to complex in-house
- SAQ type is determined by how you process payments, not your merchant level
- SAQ A requires complete outsourcing with zero cardholder data on merchant systems
- SAQ A-EP addresses e-commerce merchants whose websites could impact payment security
- SAQ D is the comprehensive catch-all covering all PCI DSS requirements
- Always confirm your SAQ type with your acquiring bank before beginning the assessment
- Maintain compliance continuously, not just during annual assessment periods
Frequently Asked Questions
Which PCI DSS SAQ do I need?
Your SAQ type depends on how you process, store, and transmit cardholder data. SAQ A for fully outsourced with no data on your systems. SAQ A-EP for e-commerce with website impact on payment security. SAQ B/B-IP/C/C-VT for various terminal configurations. SAQ D for complex environments. Confirm with your acquiring bank.
What is the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants that fully redirect customers to a third-party hosted payment page with no cardholder data touching merchant systems. SAQ A-EP is for e-commerce merchants that outsource processing but whose website elements (like embedded iframes) could impact payment security.
How many questions are on each SAQ type?
Question counts vary: SAQ A has approximately 22, SAQ A-EP around 140, SAQ B about 41, SAQ B-IP about 82, SAQ C about 160, SAQ C-VT about 79, SAQ D over 300, and SAQ P2PE about 33. The counts may vary slightly by PCI DSS version.
Can I use compensating controls on an SAQ?
Yes. If you cannot meet a specific requirement exactly as stated, you may implement a compensating control that meets the intent and rigor of the original requirement. Each compensating control must be documented on a Compensating Controls Worksheet explaining why the original cannot be met and how the alternative provides equivalent protection.
Who signs the SAQ Attestation of Compliance?
An authorized executive officer of the company must sign the Attestation of Compliance, confirming the accuracy and completeness of the self-assessment. This is typically a C-level executive or authorized representative who can attest on behalf of the organization.
How often must an SAQ be completed?
SAQs must be completed annually and submitted to your acquiring bank. However, PCI DSS compliance is a continuous obligation. Organizations should maintain compliance throughout the year and be prepared to demonstrate compliance at any time, not just during the annual assessment.
What happens if I choose the wrong SAQ type?
Completing the wrong SAQ can result in a finding of non-compliance because you may not have validated all requirements applicable to your processing environment. Your acquiring bank may reject the submission and require you to complete the correct SAQ type. Always confirm your SAQ type with your acquirer before starting.
Generate PCI DSS policies automatically
PoliWriter creates all the policies you need for PCI DSS compliance, customized to your organization. AI-powered, audit-ready, hours not months.
Get Started Free