All About PCI DSS SAQ Types: Find the Right One for You

A Self-Assessment Questionnaire (SAQ) is a validation tool used by merchants and service providers to prove their compliance with the Payment Card Industry Data Security Standard (PCI DSS). Instead of undergoing a full audit, eligible businesses complete an SAQ based on how they handle payment card data.

There are multiple SAQ types, each tailored to specific merchant environments. Choosing the wrong one can lead to compliance gaps and potential penalties.

Why SAQ Types Matter

Your SAQ type determines the controls you must implement and report on. Completing the wrong type may expose you to unnecessary audit scope or, worse, leave critical security risks unaddressed.

For example:

• A small business using only third-party payment processors may only need SAQ A.
• An e-commerce company hosting payment pages might need SAQ A-EP or D.

Using the incorrect SAQ can delay your validation process and create compliance blind spots.

Overview of All PCI DSS SAQ Types

SAQ A applies to merchants who have completely outsourced all cardholder data functions to PCI DSS-validated third-party service providers. These businesses neither store, process, nor transmit cardholder data on their own systems. A typical example would be an e-commerce store using platforms like Shopify or Wix, where all payment transactions are redirected externally.

SAQ A-EP is intended for e-commerce merchants who outsource payment processing but still host their own payment pages—such as embedding a payment form using JavaScript or an iframe. While payment processing occurs through a third party, cardholder data can still be exposed in the browser, which introduces client-side security responsibilities.

SAQ B is designed for merchants who use only imprint machines or standalone dial-out terminals that do not have internet connectivity. These environments do not involve any electronic storage of cardholder data.

SAQ B-IP is for merchants who use IP-based standalone payment terminals that connect to the internet but do not integrate with other systems that store, process, or transmit card data. This type requires proper network segmentation and monitoring to ensure security.

SAQ C-VT is for merchants who manually key in payment card information using a virtual terminal on a single, dedicated computer. This setup does not involve cardholder data storage and requires the device to be isolated from other systems and used only for payment processing.

SAQ C is meant for merchants with payment application systems—like point-of-sale (POS) terminals—that are connected to the internet. These systems may handle cardholder data, but they operate within a simplified and segmented network environment.

SAQ D is used by merchants and service providers who store cardholder data or whose environments do not qualify for any of the other SAQ types. It is the most comprehensive of all SAQs and applies to businesses with complex or custom payment environments, including those that manage or host their own payment systems or offer payment services to others.

How to Determine Your SAQ Type

To choose the right SAQ, start by looking at how your business accepts and processes payment card data:

• If you store cardholder data, you must complete SAQ D, regardless of your setup.
• If all payment processing is fully outsourced to a third-party provider and your website redirects customers to them, you likely qualify for SAQ A.
• If you host the payment page or embed third-party scripts, even if processing is outsourced, you’ll need SAQ A-EP due to higher security risks.
• If you use physical payment terminals, the type depends on how they’re connected:
  • Dial-out terminals (no internet): use SAQ B.
  • IP-connected terminals (isolated from other systems): use SAQ B-IP.
• If you manually enter card data on a virtual terminal using one device, use SAQ C-VT.
• If you have POS systems connected to the internet, but no data storage, use SAQ C

Always confirm your environment meets the eligibility criteria before selecting a form.

Common Pitfalls to Avoid

1. Using SAQ A when you host payment forms: Some businesses assume they qualify for SAQ A just because they outsource payment processing. However, if you host the payment page or use scripts from third parties (e.g., Stripe Elements, embedded forms), you fall under SAQ A-EP. Using the wrong SAQ overlooks browser-based risks like formjacking, which could lead to non-compliance and data exposure.
2. Not validating third-party vendors: Many merchants rely on external services for payment processing, website hosting, or analytics—without verifying their PCI compliance. If these vendors mishandle card data or introduce vulnerabilities (like insecure JavaScript), it expands your PCI DSS scope and liability.
3. Skipping risk assessments: Even when using a short-form SAQ, it’s critical to understand the risks in your environment. Threats like script tampering or insecure integrations can still exist, especially in e-commerce. A basic risk assessment helps you uncover blind spots and apply proper safeguards.
4. Over-reporting scope: Some businesses default to SAQ D “just to be safe,” but this can lead to unnecessary effort, longer audits, and higher compliance costs. If your environment is simple and qualifies for a shorter SAQ, properly documenting that can save both time and resources.

Preparing for SAQ Completion: Best Practices for Businesses

Before filling out any SAQ, businesses should take a few key steps to ensure the process is smooth, accurate, and audit-ready. Here’s how to prepare:

1. Map your payment data flows: Document how cardholder data enters, moves through, and exits your systems. This helps define your PCI scope and ensures you’re selecting the correct SAQ type.
2. Create an inventory of systems and vendors: List all hardware, software, service providers, and third-party platforms involved in payment processing. Make sure each is PCI compliant or documented as part of your risk management plan.
3. Segment your network: Isolate systems that handle cardholder data from the rest of your environment. This can reduce your PCI scope and make compliance easier.
4. Assign an internal owner: Designate a staff member (or team) responsible for PCI compliance and SAQ completion. They should coordinate documentation, vendor attestations, and internal reviews.
5. Conduct a pre-assessment review: Use the SAQ as a checklist and review your current controls. Identify any gaps early so they can be resolved before submission.

Final Thoughts & Compliance Tips

• Reassess your SAQ type annually or when your systems change.
• Stay updated on PCI DSS 4.0 requirements, especially around script monitoring and client-side risk.
• Use client-side protection tools like Feroot’s Security Platform to monitor JavaScript behavior and ensure secure user experiences.

For businesses using online payments or storing data, consider:

• PaymentGuard AI for real-time script change detection (meets PCI DSS 11.6.1).
• Client-side attack prevention tools to protect forms and input fields
• User Journey Security to map risk on checkout pages

Not sure which SAQ fits your environment?

Feroot helps businesses meet PCI DSS 4.0 with precision tools for script integrity, payment form protection, and client-side visibility.