PCI SAQ
What Is a PCI SAQ? Definition and How It Works
Definition
A PCI SAQ (Self-Assessment Questionnaire) is a validation tool for merchants and service providers who are not required to undergo a full QSA audit, allowing them to self-assess their compliance with PCI DSS requirements applicable to their specific payment integration type.
How it works
The SAQ is a structured questionnaire published by the PCI Security Standards Council. Different SAQ types apply to different integration models, because different models have different cardholder data flows and therefore different subsets of PCI DSS requirements. Completing an SAQ involves answering whether each applicable requirement is in place and attesting to compliance.
SAQ A applies to merchants who have completely outsourced card data handling to a PCI-compliant third party, typically through a fully hosted payment page or redirect integration where the merchant never touches cardholder data. SAQ A has the fewest requirements and is the most attainable compliance path for e-commerce merchants.
SAQ A-EP applies to merchants who use a partially outsourced payment form (such as an iframe or JavaScript-based card collection) but whose website directly facilitates the payment. More requirements apply than SAQ A.
SAQ D is the most comprehensive type, applying to merchants who process, store, or transmit cardholder data directly, typically those with direct API integrations or any form of card data storage. SAQ D covers all 12 PCI DSS requirement areas and is equivalent in scope to a QSA audit, just self-assessed rather than independently verified.
Other SAQ types (B, B-IP, C, C-VT, P2PE) apply to specific physical acceptance and point-of-sale scenarios. The PCI SSC publishes guidance documents for each SAQ type to help merchants identify which applies to their environment.
Why it matters
SAQ type is determined by integration model, not by preference: merchants cannot choose a simpler SAQ type than their integration warrants. A merchant with a direct API integration that touches raw card data cannot self-certify under SAQ A. Using the wrong SAQ type creates false compliance that increases liability in the event of a breach.
SAQ A is accessible through architecture: any merchant who can transition from a direct API integration to a hosted payment page or an iframe-based card collection tool immediately reduces their SAQ type from D to A (or A-EP). This is one of the strongest arguments for integration model review from a compliance cost perspective.
Quarterly network scans are required alongside most SAQ types: merchants completing SAQ A-EP and above must also conduct quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). The SAQ completion alone is not sufficient for full compliance validation.
Acquirers enforce SAQ submission: card networks require acquirers to ensure their merchants are PCI-compliant. Most acquirers require annual SAQ submission as a condition of the merchant agreement. Non-submission or late submission may trigger additional fees or compliance review.
With PXP
PXP's hosted payment page integration qualifies merchants for SAQ A, the simplest PCI self-assessment path. PXP provides documentation confirming its PCI DSS Level 1 certification status, which merchants can reference in their SAQ submissions and acquirer compliance reporting.
Frequently asked questions
What is the easiest PCI SAQ type to qualify for?
SAQ A is the simplest type and has the fewest requirements. It applies to card-not-present merchants who have outsourced all card data handling to a PCI-compliant third party and whose systems do not store, process, or transmit cardholder data at any point. Merchants typically qualify for SAQ A through a hosted payment page or redirect integration with a PCI-certified provider.
What is the difference between SAQ A and SAQ A-EP?
SAQ A applies when card data collection is fully outsourced and the merchant's website has no involvement in the payment form itself. SAQ A-EP applies when the merchant's website directly loads or controls the payment form, such as an iframe, even though card data entry itself happens on the provider's infrastructure. SAQ A-EP has additional requirements around website integrity and script security that SAQ A does not.
How often must merchants complete their SAQ?
SAQ completion is required annually as part of ongoing PCI compliance validation. Depending on SAQ type, merchants must also conduct quarterly external vulnerability scans by an ASV and may have additional continuous compliance obligations. Acquirers typically require proof of current SAQ completion and scan results as conditions of the acquiring relationship.
What happens if a merchant completes the wrong SAQ type?
If a merchant completes an SAQ type that does not match their actual integration environment, they are not actually compliant; they have attested to requirements that do not apply while leaving actual requirements unchecked. If a data breach occurs and forensic investigation reveals the SAQ type was incorrect, the merchant faces the full non-compliance consequences. Merchants should consult their acquirer or a QSA if they are uncertain which SAQ type applies.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started