One Script Can Move You to SAQ D: Map Payment Form and Data Flow First

Use SAQ A only when every eligibility criterion is met: your business is card-not-present and every piece of account-data processing is fully outsourced to a validated third party. If that’s not airtight, plan for SAQ D. The gap between these two questionnaires isn’t cosmetic. SAQ A covers a narrow slice of controls, while SAQ D pulls in the full PCI DSS requirement set, and picking wrong can mean a failed validation or a false sense of security you’ll pay for later.

TL;DR:

• Merchants using only redirect or iframe payment forms may qualify for SAQ A if they verify that no scripts or content on their site can modify the payment form or store card data.
• SAQ D covers merchants who process, store, or transmit cardholder data directly, and involves comprehensive controls, including quarterly scans and detailed documentation.
• Eligibility for SAQ A depends on architecture and technical flow, not transaction volume, requiring detailed mapping of all systems and third-party providers involved.
• Common pitfalls include assuming a redirect or iframe automatically qualifies for SAQ A and neglecting to reassess scope after adding scripts or changing checkout configurations.
• Small businesses should regularly review their payment flow and keep all documentation—Attestations of Compliance, scans, and contracts—up to date to prevent scope creep.

Table of Contents

• SAQ A vs SAQ D: What Each One Actually Covers
• Understanding SAQ D and Who Actually Needs It
• Key Differences: Eligibility, Scope, Effort, and Testing
• How to Determine Which PCI SAQ Applies to Your Business
• Getting Ready for SAQ D: Evidence, Scans, and QSA Involvement
• What Actually Trips Merchants Up on This Decision
• How Tatem Web Design Helps With PCI Scoping and Remediation
• Official PCI SSC Resources Worth Bookmarking
• Sources
• FAQ

SAQ A vs SAQ D: What Each One Actually Covers

SAQ A vs SAQ D comes down to one question: how much of the cardholder data environment still touches your systems? SAQ A exists for merchants who have handed that responsibility off almost entirely. According to the official SAQ A documentation, it applies only to card-not-present merchants who fully outsource all account-data functions to PCI DSS validated third-party service providers (TPSPs) and never electronically store, process, or transmit account data themselves.

That’s a specific, testable standard, not a vibe. A merchant qualifies for SAQ A when the business never sees cardholder data in any electronic form, whether that’s a mail-order catalog business using a phone-based processor or an e-commerce store that redirects checkout entirely to a payment gateway. Paper records, if they exist at all, stay on paper and get destroyed on a schedule.

What is SAQ A supposed to catch that other questionnaires don’t? It’s built for merchants whose only real job is making sure the outsourcing arrangement is documented and current. That still means real work.

• Confirm the TPSP holds a current Attestation of Compliance (AOC) and that its scope actually covers the services you’re using.
• Verify your checkout page doesn’t run any script capable of altering the payment form, including tag managers and analytics tools.
• Keep any paper-based cardholder data controls (locked storage, defined retention, secure destruction) documented and current.
• Complete any ASV scanning obligations that still apply if you have internet-facing components in scope.

Redirect-based checkouts often qualify, but a redirect alone proves nothing. The PCI SAQ selection guidance from Cartelta makes the point directly: an iframe or redirect doesn’t automatically confirm SAQ A eligibility. You still have to document where the payment form elements originate and whether any script on your side could interfere with them.

Understanding SAQ D and Who Actually Needs It

SAQ D is the catch-all. If you store, process, or transmit cardholder data yourself, or you simply don’t meet the criteria for any other SAQ type, the official SAQ D for Merchants documentation puts you here by default. Understanding SAQ D starts with recognizing it isn’t one narrow path. It’s the widest net PCI DSS throws, and it catches merchants who once assumed they were SAQ A candidates until an audit revealed a card-present terminal, an in-house payment page, or a legacy system still touching card numbers.

Typical SAQ D merchant environments include:

• Businesses that store cardholder data electronically for recurring billing or dispute handling.
• Merchants running their own payment page instead of a fully hosted redirect.
• Companies mixing channels, like an e-commerce store that also swipes cards in a retail location.
• Any merchant that can’t produce clean evidence for a narrower SAQ.

Service providers face an even tighter path. A separate service-provider version of SAQ D is the only questionnaire available to SAQ-eligible service providers, according to PCI SAQ guidance from GRC Solutions, so if you provide payment processing services to other merchants, don’t waste time evaluating SAQ A.

SAQ A typically runs a few dozen questions, while SAQ D can stretch into a much larger questionnaire depending on the form, according to PCI DSS guidance from the University of California, Riverside. That length difference reflects real scope, not paperwork bloat. SAQ D maps to the full 12 PCI DSS requirements, meaning network security, access controls, encryption, logging, monitoring, and quarterly ASV scans for any internet-facing systems in the cardholder data environment, per PCI compliance guidance on SAQ D. Some requirements can legitimately be marked “Not Applicable” if you document the justification clearly, but that explanation has to hold up if your acquirer or a QSA asks for it.

Key Differences: Eligibility, Scope, Effort, and Testing

The false assumptions that trip merchants up almost always trace back to the same root cause: treating architecture like a formality instead of evidence. A merchant who “just uses a payment gateway” but still runs a custom checkout script may be one line of JavaScript away from SAQ D. Eligibility is architecture-driven, not volume-driven, according to Cartelta’s SAQ selection guide, and mapping the actual technical flow matters more than counting transactions or trusting a label from your payment processor.

How to Determine Which PCI SAQ Applies to Your Business

Which PCI SAQ do I need? Answer that by tracing your payment flow end to end before you touch the questionnaire itself.

1. Map the data flow. List every system that could touch a card number, including your website, POS terminals, call center scripts, and any backend database that stores transaction history.
2. Check the origin of every payment form element. Confirm whether checkout fields load directly from a validated TPSP or whether your own scripts, plugins, or a tag manager could modify them. This is where a lot of merchants misjudge their scope, since a content management system update or a marketing pixel can silently break SAQ A eligibility.
3. Collect the paperwork. Gather TPSP AOCs, service contracts, and any ASV scan reports, and assign an owner responsible for keeping each document current.
4. Apply the decision rule. If any account data touches your systems electronically, or you can’t fully verify outsourcing with documentation, default to SAQ D and start planning remediation instead of hoping for the best.

Pro Tip: Re-run this mapping exercise every time you change checkout code, switch processors, or add a new third-party script. A single new analytics tag can move you from SAQ A eligible to SAQ D territory overnight, and PCI selection guidance specifically recommends re-assessing after any of these changes.

If your team can’t answer step 2 with confidence, that’s the signal to call your acquirer or a Qualified Security Assessor before you submit anything. Guessing on the questionnaire type is how businesses end up with a failed validation months later. Readers running e-commerce operations may find a closer look at proving SAQ A eligibility for online stores useful for this exact mapping exercise.

Getting Ready for SAQ D: Evidence, Scans, and QSA Involvement

Preparing for SAQ D starts with an honest inventory: every system in the cardholder data environment, every supporting system that touches it (domain controllers, logging servers, backup systems), and every cloud service with admin access to any of it. Draw the diagram before you fill out a single question.

• Schedule quarterly ASV scans for internet-facing systems and fix common failures (outdated TLS configurations, exposed admin panels, unpatched web servers) before your scan window opens.
• Prioritize remediation in this order: network segmentation, access control tightening, patch management, then logging and monitoring.
• Document every “Not Applicable” answer with a clear, defensible explanation an outside reviewer could follow.

Pro Tip: Don’t wait for your acquirer to ask for a Report on Compliance. If your transaction volume or risk profile is climbing, budget for QSA involvement now, since acquirers increasingly push higher-risk merchants toward a full ROC rather than a self-assessment. Small businesses working through this for the first time often benefit from a structured approach to cutting SAQ A prep time, which applies the same evidence discipline to SAQ D scoping.

What Actually Trips Merchants Up on This Decision

The mistake I see most often isn’t ignorance of PCI DSS. It’s assuming an iframe or a redirect is a permanent shield. Merchants add a new checkout script, forget to reassess, and end up out of scope for the SAQ they filed last year without realizing it.

Tag managers and CDNs are the quiet culprits here. Teams audit their payment gateway integration and stop, never checking whether a marketing script sitting on the same page can inject code into the payment form. A TPSP’s AOC tells you they’re compliant. It doesn’t tell you your own implementation didn’t break that compliance.

For SMBs, the priority list is short: map your flow, verify script origins, and keep every AOC and scan report in one place with a named owner.

— Matt

How Tatem Web Design Helps With PCI Scoping and Remediation

Getting SAQ A vs SAQ D right the first time saves you the remediation scramble that comes from a wrong guess. PCI compliance consulting starts with scoping your actual environment, not just reviewing your checkout screenshots, so you find out where tag managers, plugins, or legacy systems have quietly expanded your PCI footprint before an acquirer does.

The engagement typically runs in three stages: a scoping audit that maps your payment flow and reviews every TPSP AOC against your actual integration, a remediation plan that prioritizes the fixes with the biggest compliance impact, and either managed ongoing support or hourly help depending on how much your team wants to handle in house. This same discipline carries over into broader security work, including HIPAA compliance services for practices that handle both card payments and protected health information. If you’re not sure whether your current setup still qualifies for SAQ A, get a scoping review through Tatem Web Design’s AI and cybersecurity services before your next assessment deadline arrives.

Official PCI SSC Resources Worth Bookmarking

Start with the source documents: the SAQ A questionnaire and AOC, the SAQ D for Merchants form, and the PCI SSC blog on v4.0 SAQ changes, which covers the new SPoC questionnaire and expanded service-provider reporting.

Sources

• Self-Assessment Questionnaire A and Attestation of Compliance — PCI DSS v4.0
• SAQ D for Merchant — PCI Compliance guidance

FAQ

What Are the Different Types of PCI SAQ?

PCI DSS defines several SAQ types beyond A and D, including SAQ A-EP for e-commerce merchants with partial outsourcing, SAQ B for imprint or standalone terminals, and SAQ P2PE for point-to-point encrypted environments. Each targets a specific processing setup, but SAQ A and SAQ D remain the two most common starting points for most merchants.

What Is SAQ D in PCI DSS?

SAQ D is the questionnaire covering the full set of PCI DSS requirements, used by merchants who store, process, or transmit cardholder data or who don’t qualify for a narrower SAQ. It requires the most documentation, remediation work, and testing of any self-assessment option.

What Does SAQ A Mean for a Merchant?

SAQ A means a merchant has fully outsourced payment processing to validated third parties and never electronically touches cardholder data, per official PCI SSC criteria. It’s the lightest questionnaire available, but only for businesses that can prove that outsourcing arrangement with current documentation.

How Do I Know Which SAQ Applies to My Business?

Map your actual payment data flow, check whether any script on your site can alter the payment form, and confirm every third-party AOC covers your specific setup. If any part of that mapping is uncertain, consult your acquirer or a Qualified Security Assessor before selecting a questionnaire.

What Happens if I Choose the Wrong SAQ?

Selecting the wrong SAQ can result in a failed validation, rejected attestation, or a compliance gap that surfaces during a breach investigation. Acquirers and card brands can require remediation, additional scans, or a full Report on Compliance once the misclassification is discovered.

Recommended

• Avoid a QSA Audit: Prove PCI SAQ A for U.S. Ecommerce (FAQ 1588)
• Cut PCI Work to a Few Hours: Reach SAQ A for Small Businesses