In the PCI DSS SAQ, the SAQ stands for Self-Assessment Questionnaire. It is a set of questions designed for merchants and service providers to assess their compliance with PCI DSS (Payment Card Industry Data Security Standards). All SAQ types have a specific purpose to serve, and they are designed to meet the exclusive requirements of a particular scenario. In this blog, we will focus on understanding all the PCI DSS SAQ types and their use cases.
What are the PCI DSS SAQ Types and Why Do They Matter?
PCI DSS SAQ Types:
There are a total of 9 PCI DSS SAQ types specially curated for a specific purpose. They are SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, SAQ D for Merchants, SAQ D for Service Providers, and SAQ P2PE-HW. Each type is designed according to the need and what kind of payment processing method implemented by the merchant or service provider. Let’s understand each of them in detail.
1. SAQ A: Designed for a payment environment where the card is not present during the payment, and a third party does the processing. All card data functionality is outsourced to a PCI DSS-compliant third-party service provider with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
- Used by- Mail, telephone order, and e-commerce platforms that directly redirect the customer to the payment processor’s site and have no direct contact with the customer’s card data.
- Number of Questions: Approximately 24.
2. SAQ A-EP: E-commerce merchants that outsource all payment processing to PCI DSS-validated third parties, and whose websites do not directly receive cardholder information, may impact the security of the payment transaction. No electronic storage, processing, or transmission of cardholder data on the merchant’s systems or premises.
- Used by: e-commerce platforms that have direct access to card data, but an outsourced entity does the processing.
- Number of Questions: Approximately 180.
3. SAQ B: Designed exclusively for imprint machines and standalone terminals.
- Used by: This type is used in payment environments where no card data is stored electronically. Such as Manual imprint machines, standalone terminals, etc.
- Number of Questions: Approximately 45.
4. SAQ B-IP: Merchants use only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage.
- Used by: Environments where no electronic card data is stored. For example, a countertop payment terminal with internet connectivity.
- Number of Questions: Approximately 80.
5. SAQ C: Merchants with payment application systems connected to the Internet and no electronic cardholder data storage.
- Used by: TheSAQ C type is the most suitable for a payment environment where the data entry point is the payment application on a connected system. Such as POS at retail shops.
- Number of Questions: Approximately 160.
6. SAQ C-VT: Designed for merchants who manually enter card information one at a time into an Internet-based, virtual payment terminal hosted by a PCI DSS-compliant third-party service provider. No electronic cardholder data storage.
- Used by: Merchants who are required to enter card data manually into the web forms.
- Number of Questions: Approximately 80.
7. SAQ D for Merchants: This type is for all merchants who do not fulfill the criteria for SAQ A, SAQ-AEP, SAQ-C, and C-VT. SAQ-D is divided into two categories: merchants who handle only consumer transactions, and service providers who handle both consumer, business-to-business transactions, and payment data processing activities.
- Used by: All other merchants. It is the most complex in SAQs with a larger set of controls adopted only if none of the above is suitable.
- Number of Questions: Approximately 300+.
8. SAQ D for Service Providers: Designed for all the service providers that are defined by the payment brand.
- Used by: All the service providers who are not eligible for any other SAQs.
- Number of Questions: Approximately 300+.
9. SAQ P2PE-HW: Merchants using only hardware payment terminals included in and managed via a validated, PCI SSC-listed Point-to-Point Encryption (P2PE) solution, with no electronic cardholder data storage.
- Used by: Only by P2PE-listed terminals.
- Number of Questions: Approximately 35.
Why do They Matter So Much?
- Magnitude of consequences: There are various severe consequences related to failure of PCI DSS compliance. Heavy fines and penalties ranging from $5000 to $100,000 per month. According to estimates, in every data breach, it costs $150-$200+ for every compromised card, with other expenses such as legal fees, forensic investigations, and notification costs. This also opens the possibility of lawsuits from banks and customers.
- Importance of continuous vigilance: This makes it very crucial to have regular self-assessments to avoid the false sense of security. Commonly, businesses start believing that by using a particular payment processor, they are safe. Many businesses think that they are too small to be targeted, but in reality, when automated attacks are executed, they target everyone. Another misbelief is that we were compliant last year. The thing is, compliance is not a one-time event; it is an ongoing process. Attackers keep inventing new methods and approaches to attack your payment environment.
- Role of SAQs: SAQs help identify the actual risk level involved in the payment environment. Provide insights into the present vulnerabilities in the system before they are exploited by the attackers. Provide the true data flow mapping. This process takes care of baseline protections such as firewalls, encryption, and access controls. Ensure standardization of security systems and processes across the industry while providing protection for the entire payment ecosystem.
What Is the Core Purpose and Scope Behind Each SAQ Type?
Each SAQ type is intended to serve a specific purpose according to the requirements of the payment environment. From the simplest one to the highest complexity, each type is designed to deal with all types of payment ecosystems. Let’s understand them one by one.
SAQ A
- Purpose: The primary goal behind this type is to reduce the unnecessary burden of compliance for very low-risk merchants, as their contribution is almost negligible in the payment and cardholder data handling process.
- Scope: Merchants have no active role in handling any sensitive data.
SAQ A-EP
- Purpose: To create a balance between security and convenience for direct e-commerce integration.
- Scope: For a website that only collects the data and passes it directly to the outsourced processors.
SAQ B
- Purpose: To deal with legacy/simple payment methods that hold the least amount of digital risk.
- Scope: Mainly deals with the physical imprints or standalone terminals having no connection with any network.
SAQ B -IP
- Purpose: The objective is to keep the internet-enabled terminals secure while maintaining a manageable scope.
- Scope: Mostly dealing with the internet-enabled payment terminals, isolated from other systems.
SAQ C
- Purpose: To manage the administration of the integrated payment systems in business environments.
- Scope: Manages the payment applications running on merchant systems with internet connectivity.
SAQ C-VT
- Purpose: To manage and control the manual card entry operations through web interfaces.
- Scope: Mostly deals with the virtual terminals where staff enter the card data manually.
SAQ D (Merchants)
- Purpose: To ensure comprehensive security for highly complex or high-risk payment environments.
- Scope: All scenarios that are not fitting simpler SAQs, custom systems, card storage, and multiple channels.
SAQ D (Service Provider)
- Purpose: To maintain the highest standards in payment ecosystem gatekeepers.
- Scope: All companies processing, storing, or transmitting card data for other businesses.
SAQ P2PE-HW
- Purpose: Reward investment in validated encryption technology.
- Scope: Merchants using certified point-to-point encryption that encrypts card data.
Risk Comparison and Use Cases
The categorization of SAQ types based on risk involved can be seen in the below table:
| Aspect | Low-Risk (A, B, P2PE) | Medium-Risk (A-EP, C, C-VT, B-IP) | High-Risk (D) |
|---|---|---|---|
| Card Data Storage | None | May handle or transmit | May store |
| System Involvement | Minimal | Moderate | Full |
| Security Requirements | Limited subset of PCI DSS | Moderate subset of PCI DSS | All PCI DSS controls |
| Complexity of Compliance | Simple | Moderate | Complex |
| Assessment Frequency | Annual | Annual | Annual |
| External Vulnerability Scans (ASV Scan) | Required for SAQ -A only | Required (if Internet-connected) | Required |
Use Cases
Let’s explore the PCI DSS SAQ types use cases based on the industry-specific implementations
- Healthcare: Small clinics using front desk payment terminals fall under SAQ B-IP for standalone internet-connected devices. Hospitals with integrated billing systems require SAQ C due to application connectivity. Telemedicine platforms with online payment forms need SAQ A-EP, while medical billing call centers using virtual terminals require SAQ C-VT.
- Hospitality: Independent restaurants using basic countertop terminals qualify for SAQ B-IP. Hotels with property management systems integrating reservations and payments need SAQ C. Online booking platforms redirecting to third-party processors use SAQ A, while resorts with multiple payment channels require SAQ D.
- Retail: Pop-up shops using square readers fall under SAQ B-IP. E-commerce-only stores using Shopify Payments qualify for SAQ A. Chain stores with integrated POS systems require SAQ C, while department stores with custom payment systems need SAQ D.
- Professional Services: Consultants using Stripe invoice links qualify for SAQ A. Law firms using virtual terminals for phone payments require SAQ C-VT. Accounting firms with integrated practice management software need SAQ C, while multi-service firms processing through various channels must complete SAQ D.
Final Thoughts
Navigating PCI DSS compliance doesn’t have to be overwhelming. The key is identifying which SAQ type matches your specific payment environment. This alone can save you time, resources, and unnecessary complexity. Remember, compliance isn’t just about avoiding fines; it’s about protecting your customers’ trust and your business reputation. Start by honestly assessing how you handle card data, then choose the appropriate SAQ accordingly. If you’re uncertain, it’s always better to consult a Qualified Security Assessor (QSA). Most importantly, it is crucial to treat compliance as an ongoing commitment, not a one-time checkbox. Regular self-assessments, staff training, and staying updated with the recent PCI DSS-related changes will keep your payment environment secure and your business protected in an ever-evolving threat environment.
FAQS
1. What’s the difference between an SAQ and a Report on Compliance (RoC)?
SAQ is a self-assessment tool for lower-risk merchants, while an RoC is a comprehensive third-party audit conducted by a Qualified Security Assessor (QSA) required for Level 1 merchants processing over 6 million transactions annually.
2. Can I complete an SAQ on my own, or do I need a QSA?
You can complete an SAQ independently, but organizations with complex cardholder data environments or those new to PCI DSS often benefit from working with a QSA to ensure accuracy and attest the compliance.
3. What happens if I choose the wrong SAQ type?
Completing the wrong SAQ makes you non-compliant and could lead to significant penalties. If breached, you’ll have only 90 days to achieve compliance, which may be impossible for complex SAQs like SAQ D.
4. Do I need to answer “Yes” to every question to be compliant?
To attest PCI DSS compliance, you must answer “Yes” or “Not Applicable” to every requirement. A single “No” answer makes your SAQ non-compliant, though compensating controls may be approved by your acquiring bank.
5. What is an Attestation of Compliance (AoC)?
An AoC is a formal document that accompanies your SAQ or RoC, attesting to your compliance status and summarizing the assessment results for payment processors and stakeholders.
6. Are quarterly vulnerability scans required for all SAQ types?
Most SAQ types require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) if your systems are internet-connected, particularly for SAQ A, AEO, B-IP, C, C-VT, and D types.
7. What are compensating controls and when can I use them?
Compensating controls are alternative security measures that must meet the intent and rigor of the original requirement, provide similar defense, exceed PCI DSS requirements, and be commensurate with the additional risk, requiring formal approval from your acquiring bank.
8. How has PCI DSS v4.0.1 changed SAQ requirements?
PCI DSS v4.0.1 introduced new requirements for malware protection, software inventory management, phishing protection, and script management, with some designated as best practices until March 2025 before becoming mandatory.
9. Can service providers use any SAQ type?
No, SAQ D for Service Providers is the only SAQ available to service providers. All other eight SAQ types are exclusively for merchant use only.
10. Does using a third-party payment processor eliminate all my PCI responsibilities?
No, even when fully outsourcing payment processing, your website’s redirection to the third party creates security risks. You must still demonstrate compliance, typically through SAQ A, and verify your processor’s PCI DSS compliance.
