What Is SAQ A (Self-Assessment Questionnaire A)?

A Self-Assessment Questionnaire A(SAQ A) is a mandatory compliance validation tool used by merchants to evaluate and report their adherence to the Payment Card Industry Data Security Standard (PCI DSS). The specific SAQ A tier a merchant is required to complete depends entirely on their payment architecture and how their systems capture, store, and transmit sensitive Primary Account Numbers (PANs).

Who Needs to Complete an SAQ?

Any merchant that stores, processes, or transmits cardholder data must validate PCI DSS compliance. Most merchants and service providers qualify for self-assessment rather than a full onsite audit: merchants with fewer than 6 million annual card transactions, and service providers with fewer than 300,000, can typically complete an SAQ instead of a Report on Compliance (RoC). Which SAQ type applies depends on your specific payment architecture — not just your transaction volume.

The PCI SAQ Types

The PCI SSC defines several SAQ types. The right one depends entirely on how your business handles cardholder data:

• SAQ A — Card-not-present merchants that fully outsource all cardholder-data functions to PCI DSS–compliant third parties. Your systems never store, process, or transmit card data. The shortest questionnaire.

• SAQ A-EP — E-commerce merchants who outsource payment processing but whose website can still affect the security of the transaction (for example, a payment page that loads scripts from your own domain).

• SAQ B — Merchants using only imprint machines or standalone dial-out terminals, with no electronic cardholder-data storage.

• SAQ B-IP — Merchants using standalone, approved payment terminals connected to the processor over IP, with no electronic storage.

• SAQ C — Merchants with payment-application systems connected to the internet, with no electronic cardholder-data storage.

• SAQ C-VT — Merchants who key transactions one at a time into a virtual terminal on an isolated device.

• SAQ P2PE — Merchants using a validated point-to-point encryption solution, with no electronic storage.

• SAQ D — Everyone else: merchants that store, process, or transmit cardholder data on their own systems, plus all service providers. The most comprehensive questionnaire.

What Changed in PCI DSS v4.0 for SAQ A?

PCI DSS v4.0.1 removed two requirements that previously applied to SAQ A: Requirement 6.4.3 (payment page script management) and Requirement 11.6.1 (change- and tamper-detection mechanisms). Both requirements still apply to merchants completing SAQ D. This change made SAQ A eligibility slightly easier to reach, but the core condition remains the same: all payment page elements delivered to the customer's browser must originate directly from a PCI DSS–compliant third-party service provider.

Understanding SAQ Types and the Compliance Burden

For enterprise Chief Technology Officers (CTOs), managing PCI DSS compliance is often viewed as a persistent operational drag. Handling raw payment credentials on internal infrastructure triggers the highly complex and expensive SAQ D standard.

Falling under the SAQ D classification forces development teams into endless cycles of security patching and audit preparation. It requires merchants to implement mandatory file integrity monitoring, execute complex network segmentation, and undergo highly expensive annual on-site audits conducted by Qualified Security Assessors (QSAs). This compliance nightmare severely restricts an engineering team's capacity to build revenue-generating features.

How Hellgate.io Reduces Your SAQ Scope

Hellgate solves the data hostage paradox and drastically reduces compliance overhead through the Composable Payment Architecture (cpa). The foundational keystone of this ecosystem is Guardian, a highly specialized, fully PCI-compliant vault and tokenization module delivered as managed, dedicated infrastructure.

Guardian physically and legally decouples data storage from data processing. It achieves this through a sophisticated Edge-Proxy Interception Architecture. When a consumer submits their payment details, Guardian's Inbound Proxy intercepts the HTTP request at the edge. It strips the raw PAN from the payload, securely stores it within the dedicated vault, generates a non-sensitive Hellgate Token, and forwards only this safe token to the merchant's backend servers.

Because the merchant's internal infrastructure never touches, processes, or stores the raw PAN, their compliance burden is instantly reduced from the highly complex and expensive SAQ D standard to the minimal SAQ A standard. This architectural shift instantly descopes the environment, returning thousands of hours of engineering capacity back to your team.

Frequently Asked Questions (FAQ)

What is the difference between SAQ A and SAQ D?

SAQ A is the simplest questionnaire, reserved for merchants who have fully outsourced all cardholder data functions to validated third parties, meaning raw PANs never touch their internal servers. SAQ D is the most exhaustive questionnaire, required for merchants who directly store, process, or transmit raw credit card data on their own infrastructure, triggering strict security and auditing mandates.

Does using a tokenization service completely eliminate the need for an SAQ?

No. Any merchant that accepts credit card payments must maintain and validate PCI compliance. However, utilizing an advanced proxy and vaulting solution ensures you only have to complete the minimal SAQ A standard, rather than the burdensome SAQ D.

How does Guardian securely route payments if I only have a token? Through its Outbound Proxy. When your orchestration engine needs to authorize a payment, the request containing the safe token is routed out through Guardian. Guardian resolves the token in real-time, injects the raw PAN into the payload, and transmits it directly to the target Payment Service Provider, allowing you to route transactions without bringing your core systems into PCI scope.

Who is eligible to complete SAQ A?

Merchants are eligible for SAQ A if they fully outsource all cardholder data storage, processing, and transmission to validated third parties, and if all elements of their payment pages are delivered directly from a PCI DSS–compliant provider — with none of that functionality hosted on the merchant's own servers.

What's the difference between SAQ A and SAQ A-EP?

SAQ A applies when your payment page is fully hosted and served by your provider. SAQ A-EP applies when your website still controls or influences the payment page — for example, if it loads a script or iframe from your own domain — even though the actual card data capture is outsourced.

How many transactions before I need to complete an SAQ?

There's no lower threshold — any merchant accepting card payments must validate PCI DSS compliance in some form. The SAQ path (self-assessment instead of a full onsite audit) is available to merchants with fewer than 6 million annual card transactions.

Stop wasting engineering hours on PCI audits.

Liberate your development team from the endless cycle of SAQ D compliance. Leverage Hellgate Guardian's edge-proxy architecture to vault raw data independently, drop your compliance scope to SAQ A, and regain control over your payment stack. Explore the Hellgate Developer Docs to see how easily you can implement our proxy interceptors, or visit Hellgate.io to book a technical demo today.