What is the difference between SAQ A and SAQ A-EP?

SAQ A is for merchants who fully outsource all payment processing to a PCI DSS validated third party using either a redirect or an iframe. The merchant's website never directly handles, processes, or transmits cardholder data. SAQ A-EP applies when the merchant's website controls how cardholder data is redirected or transmitted to the payment processor — such as using JavaScript-based payment forms that run on the merchant's page. The key distinction is whether your website code can affect the security of the payment transaction.

How many requirements does SAQ A have?

SAQ A is the shortest Self-Assessment Questionnaire with approximately 22 requirements. It covers a subset of the full PCI DSS standard, focusing on Requirements 2, 6.4.3, 8, 9, 11.3.2, and 12. This is significantly fewer than the 329 requirements in the full PCI DSS standard (SAQ D). However, PCI DSS v4.0.1 added new requirements including 6.4.3 (client-side script management) and 11.6.1 (payment page tampering detection) that affect even SAQ A merchants.

Can MOTO (mail order / telephone order) merchants use SAQ A?

Yes. MOTO merchants can qualify for SAQ A if they do not store cardholder data electronically and their payment processing is fully outsourced to a PCI DSS validated third-party processor. The key requirement is that no cardholder data is stored, processed, or transmitted electronically within the merchant's environment. Paper-based records containing cardholder data must still be physically secured under Requirement 9.

Does using an iframe automatically qualify me for SAQ A?

Not necessarily. Using an iframe from a PCI DSS compliant payment provider is one way to qualify for SAQ A, but you must also ensure that no other elements of your website can affect the security of the payment transaction. If your website uses JavaScript that could interfere with the iframe or intercept payment data, you may need to complete SAQ A-EP instead. Additionally, under PCI DSS v4.0.1, even iframe-based implementations must address Requirement 6.4.3 for client-side script management.

What happens if I incorrectly self-assess as SAQ A when I should be SAQ A-EP?

Incorrectly completing the wrong SAQ type is a serious compliance gap. If a breach occurs and your acquiring bank or card brand determines you were completing the wrong SAQ, you may face increased penalties, fines, and liability. Your acquirer may also require you to undergo a more rigorous assessment. It is critical to carefully evaluate your payment architecture against the SAQ eligibility criteria, and when in doubt, consult your acquiring bank or a Qualified Security Assessor (QSA).

← All SAQ Types

SAQ A — Fewest Requirements

PCI DSS SAQ A Compliance Guide

The simplest PCI DSS self-assessment for card-not-present merchants who fully outsource all payment processing to validated third parties.

Understand SAQ A eligibility, requirements, common pitfalls, and how GRCTrack streamlines your compliance journey.

Start Your SAQ A Assessment Talk to a PCI Expert

What Is SAQ A?

SAQ A is the shortest PCI DSS Self-Assessment Questionnaire, designed for merchants who have fully outsourced all payment card processing to PCI DSS validated third-party service providers. These merchants never see, store, process, or transmit cardholder data in any electronic format within their own environment.

SAQ A applies to two primary merchant types: e-commerce merchants who use a redirect or iframe from a PCI DSS compliant payment processor (where the entire payment page is hosted by the third party), and mail-order/telephone-order (MOTO) merchants who send cardholder data directly to their processor without electronic storage.

With approximately 22 requirements, SAQ A represents the lightest compliance burden of any SAQ type. However, PCI DSS v4.0.1 introduced new requirements that even SAQ A merchants must address, including client-side script management (Requirement 6.4.3) and payment page tampering detection (Requirement 11.6.1), making it important to stay current with the evolving standard.

Who Qualifies for SAQ A?

E-commerce merchants using a payment processor redirect (customer leaves merchant site entirely)

E-commerce merchants using an iframe hosted entirely by a PCI DSS validated payment provider

MOTO merchants who send cardholder data to their processor without electronic storage

Merchants with no electronic storage, processing, or transmission of cardholder data

Merchants whose entire payment page is delivered from the third-party payment processor

Merchants who have confirmed all third-party payment providers are PCI DSS compliant

Key SAQ A Requirements

Req 2: Secure Configurations

Apply secure configurations to all system components. Even with outsourced payments, any systems in scope must be securely configured with vendor defaults changed.

Req 6.4.3: Script Management

New in PCI DSS v4.0.1 — manage all payment page scripts loaded in the consumer browser. Ensure only authorized scripts execute on pages that include payment iframes.

Req 8: Access Controls

Identify users and authenticate access to system components. Ensure strong passwords, unique IDs, and appropriate access controls for any systems that interact with payment processing.

Req 9: Physical Security

Restrict physical access to cardholder data. For MOTO merchants, this includes securing any paper-based records containing cardholder data.

Req 11.3.2 & 11.6.1: Monitoring

Perform external vulnerability scans (ASV scans) and implement change-and-tamper-detection mechanisms on payment pages to detect unauthorized modifications.

Req 12: Policies & Procedures

Maintain an information security policy, manage third-party service provider relationships, and implement a security awareness program for personnel.

Common SAQ A Mistakes

Confusing Iframe and Redirect Eligibility

Many merchants assume that any iframe implementation qualifies for SAQ A. However, if your website JavaScript can interact with or affect the iframe content, or if you use a direct post method, you likely need SAQ A-EP instead. The distinction depends on whether your site code can impact payment data security.

Ignoring Req 6.4.3 and 11.6.1 (v4.0.1)

PCI DSS v4.0.1 added requirements for client-side script management (6.4.3) and payment page tampering detection (11.6.1) that apply to SAQ A merchants. Many merchants are unaware these new requirements exist and fail to implement script inventories and integrity monitoring on their checkout pages.

Misunderstanding the Iframe vs. Redirect Distinction

A redirect sends the customer to the payment processor's domain entirely. An iframe embeds the processor's page within your page. Both can qualify for SAQ A, but the technical implementation details matter — particularly whether your page scripts could interfere with the payment content.

Failing to Validate Third-Party Compliance

SAQ A eligibility requires that all third-party payment processors are PCI DSS validated. Merchants often assume their processor is compliant without verifying their Attestation of Compliance (AOC) or checking their listing on the PCI SSC or card brand service provider registries.

How GRCTrack Helps with SAQ A Compliance

SAQ type selection wizard that evaluates your payment architecture and confirms SAQ A eligibility

Pre-built SAQ A control library with all applicable requirements mapped and guided step-by-step

Automated tracking of Req 6.4.3 and 11.6.1 obligations with implementation guidance for script management

Third-party service provider management to verify and document processor PCI DSS compliance

Evidence collection templates designed specifically for SAQ A documentation requirements

AI-powered compliance guidance built by certified QSAs to answer SAQ A-specific questions

SAQ A Compliance — Frequently Asked Questions

Related PCI DSS Resources

All SAQ Types PCI DSS 4.0.1 Guide PCI DSS FAQ SAQ A-EP Guide E-Commerce Guide

Ready to Complete Your SAQ A Assessment?

GRCTrack guides you through every SAQ A requirement with step-by-step compliance workflows.

Start Your SAQ A Assessment Compare SAQ Types