Understanding PCI DSS SAQ Types and Their Compliance Role
Definition and Purpose of PCI DSS Self-Assessment Questionnaires
The PCI DSS SAQ serves as a self-validation tool that allows merchants and service providers to demonstrate their compliance with PCI DSS requirements, provided they do not require a full Report on Compliance (RoC). The SAQ consists of yes/no questions designed to assess adherence to PCI DSS security controls, accompanied by an Attestation of Compliance (AoC) confirming the entity’s adherence to required standards.
Who Needs an SAQ?
- Level 3 and 4 merchants processing between 20,000 to 1 million transactions annually are required to complete an SAQ as part of their compliance obligations.
- Level 1 and 2 merchants, handling over 1 million transactions per year, must undergo a Qualified Security Assessor (QSA) audit but may use the SAQ for preparatory assessments.
Levels to Determine Your PCI SAQ Requirements
PCI DSS compliance levels are determined by the volume of annual card transactions.
These levels dictate the reporting requirements for merchants and service providers, ranging from self-assessment to full external audits.
Level 1
Who qualifies? Merchants processing over 6 million transactions annually or those suffering a data breach, regardless of volume.
Requirements:
- Annual Report on Compliance (RoC) by a Qualified Security Assessor (QSA).
- Quarterly scans by an Approved Scanning Vendor (ASV).
- Annual penetration testing and submission of an AoC.
Key Takeaway: This is the most rigorous level, requiring external audits and comprehensive testing.
Level 2
Who qualifies? Merchants processing between 1 million and 6 million transactions annually.
Requirements:
- Annual SAQ completion.
- Quarterly ASV scans.
- Penetration testing for service providers handling data directly.
Key Takeaway: While less demanding than Level 1, it still requires robust internal controls and regular assessments. Level 2 merchants completing SAQ A, A-EP, or D are required to engage a QSA or Internal Security Assessor (ISA) for annual compliance validation
Level 3
Who qualifies? Merchants processing between 20,000 and 1 million e-commerce transactions annually.
Requirements:
- Annual SAQ submission.
- Quarterly ASV scans.
Key Takeaway: Focused on smaller e-commerce players, this level emphasizes basic security hygiene.
Level 4
Who qualifies? Merchants processing fewer than 20,000 e-commerce transactions annually.
Requirements:
- Annual SAQ completion.
- Quarterly ASV scans if applicable.
Key Takeaway: Designed for small businesses, this level keeps compliance manageable but still enforces critical controls.
PCI SAQ Types Explained
Each SAQ type is designed based on how merchants accept, process, and store cardholder data. Choosing the appropriate SAQ is essential to ensuring accurate compliance validation. Below is a breakdown of each type:
SAQ A: Outsourced E-Commerce and Mail/Telephone Orders
SAQ A is designed for merchants who outsource all their cardholder data processing to PCI DSS-compliant Third-Party Service Providers (TPSP). It’s one of the simplest SAQs, aimed at minimizing compliance burdens for businesses that don’t directly handle sensitive payment data.
1. Eligibility
To qualify for SAQ A, your business must meet very specific criteria:
- Card-Not-Present Transactions Only: SAQ A is exclusively for merchants conducting e-commerce or mail/telephone order transactions where the physical card is not present.
- Fully Outsourced Cardholder Data Processing: All payment processing must be handled by PCI DSS-compliant TPSPs. Your systems should never store, process, or transmit cardholder data electronically.
- No Electronic Storage of Cardholder Data: Any cardholder data within your organization must exist only in physical form (e.g., paper records). No digital storage or transmission is allowed on your systems or networks.
- Third-Party Compliance Assurance: You must ensure that all TPSPs involved in payment processing are PCI DSS compliant and can provide proof of their compliance status.
Overall, if you never touch cardholder data electronically and rely entirely on a third party for payment processing, SAQ A is likely the right fit for your business.
2. Scope
The scope of SAQ A is deliberately narrow to reflect the minimal risk posed by merchants who outsource all payment functions. Here’s what’s included:
- Excluded Systems: Your internal IT systems and networks are out of scope since they don’t handle cardholder data. This significantly reduces the complexity of compliance efforts.
- Focus on Third Parties: The primary focus is on ensuring that your TPSPs maintain PCI DSS compliance.
- Physical Data Handling: If your organization retains any cardholder information (e.g., mail order forms), it must be in physical form only and secured appropriately.
For e-commerce merchants, this typically involves redirecting customers to a third-party payment processor’s page for checkout or embedding an iframe provided by a PCI DSS compliance TPSP, ensuring no cardholder data passes through your website or systems.
3. Key Requirements
SAQ A has fewer requirements compared to other SAQs because of its limited scope. However, there are still critical controls that must be implemented to ensure compliance. These include:
Vendor-Supplied Defaults (Requirement 2)
Ensure that any systems within your environment (e.g., routers or firewalls) do not use default passwords or configurations provided by vendors. While your systems don’t handle cardholder data, maintaining basic security hygiene is essential to prevent unauthorized access.
Access Control (Requirement 8)
Restrict access to any system components that could indirectly impact security (e.g., web servers hosting redirects). Ensure proper authentication mechanisms are in place for any administrative functions.
Physical Security (Requirement 9)
Protect any physical copies of cardholder data (e.g., mail order forms) with access controls such as locked cabinets or restricted areas to prevent unauthorized access or theft.
Information Security Policy (Requirement 12)
Maintain an information security policy that addresses employee responsibilities regarding PCI DSS compliance and ensures ongoing awareness of security best practices.
SAQ A simplifies compliance for businesses that have minimal interaction with sensitive payment data, allowing them to focus on their core operations while relying on trusted third-party providers to handle security-intensive processes.
However, this simplicity comes with responsibility—ensuring your TPSPs maintain PCI DSS compliance is non-negotiable.
If you’re eligible for SAQ A, it’s an opportunity to streamline compliance while maintaining a secure environment for your customers’ payment information.
SAQ A-EP: Partial Outsourcing with Web Control
SAQ A-EP is tailored for e-commerce merchants who outsource payment processing to PCI DSS-compliant third parties but maintain control over the payment page or elements that influence payment page security.
While these merchants don’t directly handle cardholder data, their websites play a critical role in ensuring secure data redirection to third-party processors.
1. Eligibility
To qualify for SAQ A-EP, your business must meet the following criteria:
- E-Commerce Transactions Only: SAQ A-EP applies exclusively to merchants conducting e-commerce transactions. Merchants handling card-present transactions or other channels do not qualify.
- Outsourced Payment Processing: All cardholder data processing must be outsourced to PCI DSS-compliant TPSPs. However, unlike SAQ A, the merchant’s website plays an active role in the payment process.
- Merchant-Controlled Payment Page: The merchant’s website either hosts or controls elements of the payment page, such as a redirect or embedded iframe, which impacts the security of the transaction.
- No Cardholder Data Storage: The merchant’s systems must not electronically store, process, or transmit cardholder data. Any cardholder data entered on the website is immediately and securely transmitted to the third-party processor.
If your website influences how customers interact with the payment page, whether through redirects, scripts, or embedded forms, SAQ A-EP is likely the correct compliance pathway.
2. Scope
The scope of SAQ A-EP is broader than SAQ A due to the merchant’s involvement in the payment process. Here’s what falls under its purview:
- Website Security: The e-commerce website must be secured against vulnerabilities that could compromise customer data during redirection or transmission to third-party processors.
- Script Management: Any scripts running on the payment page must be authorized, monitored, and secured to prevent tampering or unauthorized changes (as mandated by PCI DSS v4.0 Requirements 6.4.3 and 11.6.1).
- Network Segmentation: The e-commerce website must be isolated from other systems within the organization’s environment to minimize potential attack vectors.
- Third-Party Validation: While cardholder data processing is outsourced, merchants are responsible for ensuring that their third-party processors remain PCI DSS compliant and secure.
By design, SAQ A-EP ensures that merchants address risks tied to their digital environment without requiring them to handle cardholder data directly.
3. Key Requirements
SAQ A-EP includes significantly more requirements than SAQ A due to its broader scope and focus on securing the payment page environment.
Additional key obligations include:
Secure Redirects and Frames
If using redirects or iframes for payment processing, merchants must ensure these elements are securely integrated and cannot be exploited by attackers to intercept customer data during transmission.
Vulnerability Management (Requirement 11)
Regular vulnerability scans of the e-commerce website are mandatory to identify and address weaknesses that could impact transaction security or expose customer data indirectly through compromised systems.
Payment Page Security (Requirement 6.4.3)
Merchants must manage all scripts running on their payment pages by implementing controls such as:
- A method is implemented to confirm that each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Change Detection (Requirement 11.6.1)
A change- and tamper-detection mechanism is deployed as follows:
- To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
- The mechanism is configured to evaluate the received HTTP headers and payment pages.
- The mechanism functions are performed as follows:
- At least weekly
OR - Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
- At least weekly
SAQ B and B-IP: Standalone Terminals
For businesses relying on standalone payment terminals, PCI DSS offers two specific Self-Assessment Questionnaires (SAQs): SAQ B and SAQ B-IP.
These questionnaires cater to merchants using basic card-present payment setups, ensuring compliance while minimizing complexity.
SAQ B
SAQ B is designed for merchants using standalone dial-out terminals connected via a phone line to their payment processor. This SAQ excludes e-commerce businesses and is strictly for “brick-and-mortar” or mail/telephone order merchants operating in isolated environments.
The scope of SAQ B is limited to the physical security of standalone terminals and the secure handling of any paper-based cardholder data. Since the terminals are not network-connected, risks associated with data breaches from external threats are significantly reduced.
SAQ B-IP
SAQ B-IP applies to merchants using standalone Point-of-Interaction (POI) devices that connect to payment processors via an IP network (e.g., Ethernet). As with SAQ B, SAQ B-IP excludes e-commerce channels and focuses on “brick-and-mortar” or mail/telephone order merchants.
The scope of SAQ B-IP extends beyond physical security to include network security controls for protecting IP-connected POI devices. Unlike dial-up terminals in SAQ B, these devices interact with networks, introducing additional risks that must be mitigated through segmentation and encryption.
SAQ C and C-VT: Internet-Based Payment Systems
For merchants operating in environments where payment systems are connected to the internet, PCI DSS provides two tailored Self-Assessment Questionnaires (SAQs): SAQ C and SAQ C-VT.
These SAQs address distinct use cases, ensuring that businesses secure their payment channels while maintaining compliance.
SAQ C
SAQ C is designed for merchants using internet-connected payment application systems, such as point-of-sale (POS) terminals or software. This SAQ primarily applies to “brick-and-mortar” or mail/telephone order merchants who rely on internet-based payment systems but avoid storing sensitive data electronically. SAQ C focuses on environments where cardholder data is processed through payment applications connected to the internet.
The scope excludes broader IT systems unrelated to payment processing, provided they are effectively segmented from the Cardholder Data Environment (CDE).
With its focus on securing internet-connected payment applications, SAQ C provides a clear framework for merchants handling card-present transactions while leveraging online connectivity.
SAQ C-VT
SAQ C-VT applies to merchants manually entering cardholder data into virtual payment terminals via an internet-connected web browser. This SAQ is commonly used by call centers or mail/telephone order merchants handling low transaction volumes.
The scope of SAQ C-VT is narrower than SAQ C due to its reliance on third-party-hosted virtual terminals and manual transaction entry.
E-commerce merchants are explicitly excluded from using SAQ C-VT since it does not apply to web-based checkout processes.
SAQ C-VT focuses on securing the virtual terminal environment and ensuring compliance with PCI DSS requirements relevant to this setup.
SAQ P2PE: Encrypted Hardware Solutions
SAQ P2PE (Point-to-Point Encryption) is a specialized SAQ designed for merchants who process payments exclusively through PCI-listed P2PE hardware terminals.
By leveraging validated encryption solutions, SAQ P2PE drastically reduces the scope of compliance, making it one of the most streamlined options for merchants handling card-present transactions.
To qualify for SAQ P2PE, your business must meet strict criteria that ensure all payment processing is conducted through a PCI-approved P2PE solution. If your business uses standalone hardware terminals with no access to sensitive data and relies on a PCI-listed encryption solution, SAQ P2PE is likely the right fit.
SAQ P2PE offers one of the smallest compliance scopes among all PCI DSS questionnaires because it isolates payment processing to secure hardware devices and eliminates exposure to sensitive data within the merchant’s environment.
This narrow scope significantly reduces compliance complexity and audit effort, allowing merchants to focus on operational security without worrying about broader IT risks.
SAQ P2PE focuses on a few critical PCI DSS requirements tied directly to secure hardware usage and physical controls. With just 33 questions before March 2025 and only 21 compliance questions afterward, it is one of the shortest SAQs available.
SAQ D: Comprehensive Compliance for Complex Environments
SAQ D is the most extensive and demanding SAQ under the PCI DSS framework. It applies to merchants and service providers who process, store, or transmit cardholder data but do not qualify for any of the simpler SAQs.
For organizations handling sensitive payment data directly, SAQ D is a non-negotiable requirement.
Eligibility
SAQ D is intended for entities with complex environments or those that handle cardholder data in ways that go beyond the criteria of other SAQs.
Merchants
- You process, store, or transmit cardholder data electronically within your own systems or environment.
- Your organization does not meet the eligibility criteria for simpler SAQs like A, B, C, or P2PE.
- Examples include businesses with in-house payment processing systems or those storing cardholder data for recurring transactions.
Service Providers
- You manage cardholder data on behalf of other entities (e.g., hosting providers, payment processors).
- This includes entities offering services that could impact the security of cardholder data (e.g., managed firewalls or cloud hosting).
If your organization stores sensitive data electronically or directly handles payment processing infrastructure, SAQ D is mandatory. For service providers processing over 300,000 card transactions annually, an on-site Report on Compliance (RoC) may also be required.
Scope
SAQ D has the broadest scope among all PCI DSS questionnaires because it covers all aspects of the CDE. This includes any system, network, or process involved in storing, processing, or transmitting cardholder data.
- Cardholder Data Storage Systems: Any database or application storing full Primary Account Numbers (PANs) or other sensitive authentication data.
- Payment Processing Systems: Servers, applications, and devices directly involved in transaction processing.
- Connected Networks: Any network segment that interacts with systems handling cardholder data.
- Third-Party Services: Vendors providing services that could impact the security of your CDE (e.g., cloud hosting providers).
Systems and networks effectively segmented from the CDE using robust firewalls and access controls may fall outside the scope of SAQ D.
Given its comprehensive nature, defining and limiting the scope of your CDE through segmentation can significantly reduce compliance effort.
Key Requirements
SAQ D spans all 12 PCI DSS requirements, making it the most rigorous of all SAQs. Below are some of the critical areas covered:
1. Firewall Configuration
- Build and maintain firewalls to isolate the CDE from untrusted networks.
- Restrict inbound and outbound traffic based on business need-to-know principles.
2. Avoid Vendor Defaults
- Replace default passwords and configurations on all devices within the CDE to prevent unauthorized access.
3. Protect Stored Cardholder Data
- Encrypt stored cardholder data using strong cryptographic methods (e.g., AES-256).
- Mask PANs when displayed and ensure sensitive authentication data (SAD) is never stored after authorization.
4. Encrypt Data in Transit
- Use strong encryption protocols (e.g., TLS 1.2 or higher) to secure cardholder data transmitted over public networks.
5. Malware Protection
- Deploy antivirus software across all systems vulnerable to malware and ensure regular updates.
6. Secure Applications
- Develop and maintain secure applications by addressing vulnerabilities identified through regular testing and patching.
7. Access Controls
- Restrict access to cardholder data based on job responsibilities using role-based permissions.
8. Authentication Mechanisms
- Implement multi-factor authentication for all administrative access to systems within the CDE.
9. Physical Security
- Secure physical access to servers, storage devices, and other hardware within the CDE using locked facilities and surveillance systems.
10. Monitoring and Logging
- Track all access to network resources and cardholder data using centralized logging systems.
- Retain logs for at least one year with immediate availability for three months.
11. Regular Testing
- Conduct quarterly vulnerability scans by an Approved Scanning Vendor (ASV).
- Perform internal penetration testing at least annually or after significant changes to network segmentation.
12. Information Security Policies
- Maintain a comprehensive security policy covering all personnel with access to sensitive systems or data.
SAQ D is not just a compliance exercise—it’s a blueprint for securing complex environments where sensitive payment data is directly handled. While it demands significant effort due to its comprehensive scope and rigorous requirements, it provides organizations with a robust framework to mitigate risks associated with storing and processing cardholder data.
For merchants managing in-house payment systems or service providers responsible for securing client environments, completing SAQ D ensures adherence to industry standards while protecting against costly breaches and reputational damage.
In today’s threat landscape, where attackers actively target payment ecosystems, SAQ D compliance isn’t optional, it’s essential for safeguarding your business and maintaining trust with customers and partners alike.
Selecting the Right SAQ: Criteria and Workflow
Choosing the correct PCI DSS Self-Assessment Questionnaire (SAQ) is not just a procedural step, it’s a strategic decision that can streamline compliance efforts and reduce risks.
The process requires a clear understanding of your organization’s role, data flow, and technology stack.
Determine Merchant vs. Service Provider Status
The first step in selecting the right SAQ is identifying whether your organization acts as a merchant, a service provider, or both. This distinction is critical because it defines your compliance obligations under PCI DSS.
Merchant
If your business accepts payment cards for goods or services, you are classified as a merchant. Even if you outsource payment processing to third-party providers, you remain responsible for ensuring compliance with PCI DSS requirements applicable to merchants.
Service Provider
If your organization stores, processes, or transmits cardholder data on behalf of other entities (e.g., hosting providers, and payment gateways), you are classified as a service provider. Service providers must complete SAQ D for Service Providers or undergo a full Report on Compliance (RoC) if they process large volumes of transactions.
Assess Data Flow
Understanding how cardholder data flows through your environment is essential for defining the scope of your compliance efforts. This involves mapping every point where cardholder data is collected, transmitted, processed, or stored—both internally and externally.
Create Data Flow Diagrams
These diagrams provide a visual representation of how cardholder data moves through your systems and networks. They should include all payment channels (e.g., POS systems, e-commerce platforms) and external connections (e.g., third-party processors).
Identify Points of Interaction
Determine where cardholder data enters your environment (e.g., payment terminals, virtual terminals) and exits to third-party providers or storage systems.
Segmentation and Isolation
Use network segmentation to isolate the Cardholder Data Environment (CDE) from other parts of your infrastructure. Proper segmentation can significantly reduce the scope of PCI DSS requirements by limiting which systems fall under compliance.
A well-documented data flow diagram not only helps you select the right SAQ but also demonstrates to assessors that you’ve accurately scoped your environment
Evaluate Technology
Your choice of hardware, software, and third-party solutions directly impacts which SAQ applies to your business. Evaluate the technologies in use across your payment channels to determine their compliance implications:
Standalone Terminals vs. Integrated Systems
If you use standalone terminals with no network connectivity (SAQ B) or IP-connected terminals (SAQ B-IP), your compliance requirements will differ from those using integrated POS systems or e-commerce platforms (SAQ C or A-EP).
Outsourcing Payment Processing
Businesses outsourcing all payment functions to PCI-compliant third parties may qualify for simpler SAQs like A or A-EP. However, if your website influences transaction security (e.g., via hosted payment scripts), additional controls will apply under SAQ A-EP.
Encryption Solutions
Merchants using validated Point-to-Point Encryption (P2PE) solutions can significantly reduce their compliance scope by ensuring that sensitive data is encrypted at the point of interaction and cannot be accessed in clear text.
The more control you retain over payment processing systems and environments, the more complex your compliance obligations become. Outsourcing functions to trusted third parties can simplify this process but requires due diligence to ensure their compliance
Look for Opportunities to Reduce PCI DSS Compliance Scope
For merchants handling payment card data, the path to PCI DSS compliance often hinges on minimizing exposure to sensitive information like Primary Account Numbers (PANs).
Solutions like tokenization and tamper detection systems enable businesses to reduce their compliance burden by shrinking the CDE and meeting stringent SAQ eligibility criteria.
Platforms like DataStealth streamline this process by integrating tokenization and real-time monitoring into existing workflows without requiring code changes—critical for merchants aiming to transition from SAQ D to SAQ A-EP or SAQ A.
Tokenization replaces PANs with tokens created using methods that make them infeasible to reverse without access to the tokenization system, ensuring that sensitive data never resides in a merchant’s systems.
By outsourcing encryption and token management to PCI DSS-validated providers (e.g., DataStealth’s secure vaults), merchants eliminate the need to store or process PANs internally.
This allows organizations to exclude entire systems from their CDE, such as databases and applications that previously handled raw cardholder data.
For example, a merchant using tokenization for recurring billing can replace stored PANs with tokens, reducing their compliance scope to only the tokenization gateway, aligning with SAQ A’s requirement for fully outsourced payment processing.
For e-commerce merchants, e-skimming protection systems like DataStealth’s in-line monitoring of scripts and security-impacting HTTP headers allow SAQ A merchants to confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce system(s) and others to address PCI DSS v4.0 Requirements 6.4.3 and 11.6.1 by continuously scanning payment pages for unauthorized scripts or modifications.
Next Steps
Merchants looking to simplify PCI DSS compliance can achieve significant benefits by adopting tokenization and tamper detection solutions. These technologies reduce the compliance scope, lower audit complexity, and enhance security without disrupting existing workflows.
If your organization is aiming to transition from SAQ D to a more manageable SAQ like A or A-EP, now is the time to act. Contact DataStealth today to explore how our tokenization and real-time monitoring solutions can help you reduce PCI scope, strengthen security, and streamline compliance, without requiring code changes.
