PCI compliance SAQ A is a self-assessment questionnaire designed for merchants who process credit card transactions exclusively through a third-party service provider with no electronic storage, processing, or transmission of cardholder data. It confirms adherence to the Payment Card Industry Data Security Standard (PCI DSS) for low-risk environments.
Merchants using only a third-party processor-such as a virtual terminal, hosted payment page, or a payment gateway like PayPal-are eligible to complete SAQ A. This form verifies that the business has no direct access to cardholder data and relies entirely on the service provider's secure infrastructure. It applies to Level 1, 2, and 3 merchants with minimal risk exposure.
The PCI Security Standards Council defines SAQ A as a tool for validating compliance for organizations with no internal cardholder data systems. It replaces the need for a full annual audit in low-risk scenarios. The form includes 12 core requirements from the PCI DSS, such as maintaining a firewall, protecting stored data, and testing security systems regularly.
SAQ A is completed annually by the merchant or their designated IT or finance officer. It requires answering yes/no questions across four categories: network security, vulnerability management, access control, and monitoring. Each response must be supported by documented evidence, such as system logs, firewall configurations, or signed service agreements.
For example, a small e-commerce store using Shopify's hosted checkout page would use SAQ A. The store owner does not install software, store card numbers, or manage payment terminals. All transaction data flows directly from the customer's browser to Shopify's encrypted servers. Since no cardholder data touches the merchant's systems, the environment qualifies for SAQ A.
After completion, the merchant submits the form to their acquiring bank or payment processor. The form is reviewed for accuracy and consistency. If discrepancies are found, the merchant may be asked to correct or resubmit. Once approved, the business maintains compliance status for one year.
SAQ A applies only to merchants who meet all of the following criteria:
Common examples include online retailers using Stripe Checkout, subscription services using PayPal Pro, or event ticketing platforms using Square's hosted payment page. These businesses rely entirely on the service provider's encryption and tokenization to protect card details.
A business that processes cards via a mobile app with local caching-even if it uses a third-party processor-does not qualify for SAQ A. The presence of any temporary data storage disqualifies the merchant and triggers the need for SAQ A-EP or SAQ C.
| Merchant Type | SAQ Type | Eligibility Criteria |
|---|---|---|
| Online retailer using hosted payment page | SAQ A | Third-party processing only; no data storage |
| Restaurant using tablet-based POS with cloud sync | SAQ C | Data transmitted to cloud; not fully outsourced |
| Mail-order business using physical terminal | SAQ D | Internal systems involved; multiple entry points |
SAQ A covers 12 PCI DSS requirements, including:
One common error is assuming that because a payment processor is PCI compliant, the merchant is automatically compliant. That is false. The merchant remains responsible for ensuring their own environment meets SAQ A criteria. For example, if a business uses a third-party checkout but still stores customer email addresses linked to past transactions, that creates a data linkage that could be exploited.
A non-obvious requirement: the merchant must confirm that the third-party processor maintains PCI DSS compliance. This is verified through documentation such as a Service Provider Attestation of Compliance (AOC) or a valid Report on Compliance (ROC) from the processor. Without this, the SAQ A submission fails.
I once audited a small nonprofit that used a donation platform with a hosted form. They completed SAQ A without checking whether the platform had a current AOC. During the review, we discovered the provider's certification had lapsed. The organization had to restart the entire compliance cycle. This highlights that compliance is not passive-it requires active verification.
SAQ A is not a substitute for understanding PCI DSS fundamentals. It is not suitable for businesses that manually enter card data into spreadsheets, save transaction receipts with partial card numbers, or use unencrypted email to send payment details. These actions violate the principle of data minimization and create high-risk exposure.
It is also not intended for businesses that use integrated payment systems. For example, a retail store using a POS system connected to a payment gateway via API-even if data is not stored-must use SAQ C or SAQ D depending on the integration model.
Another misconception: SAQ A cannot be used by merchants who accept card payments via phone or fax. These methods involve manual data entry and increase the risk of exposure. Such businesses fall under SAQ D or SAQ C-VT.
Once SAQ A is completed and submitted, the merchant receives confirmation from their acquirer. The document must be retained for at least three years, as required by PCI DSS Section 12.6.2. This retention period ensures audit readiness during investigations or disputes.
If a business changes its payment processor or adds a new channel (e.g., switching from PayPal to Stripe), they must reassess eligibility. A change in processing method may require a different SAQ type.
PCI compliance SAQ A is not a one-time task. It is a recurring responsibility tied to business operations. Merchants must re-evaluate eligibility annually and update their compliance posture when systems evolve. Failure to do so risks fines up to $500,000 per incident, as outlined in the PCI DSS v4.0 standard.
Understanding the boundaries of SAQ A prevents costly missteps. It is not a loophole-it is a structured path for low-risk entities to maintain security and avoid breaches. When used correctly, it helps payment processing remains secure, transparent, and compliant.