PCI DSS Self-Assessment Questionnaire

Self-Assessment Questionnaires (SAQs) are validation tools for merchants and service providers that are not required to undergo a full on-site QSA assessment. The SAQ you complete depends on how you handle cardholder data — not on your size, revenue, or industry. Selecting the right SAQ is critical: choosing one that is too simple creates compliance gaps and post-breach liability, while choosing one that is too broad wastes months of effort on controls you did not need to validate.

Each SAQ is a subset of the full PCI DSS requirement set, pre-filtered to the requirements the PCI Council considers relevant to a specific payment acceptance model. Every SAQ package includes the questionnaire itself plus an Attestation of Compliance (AOC) — the signed summary document your acquirer or customers actually collect.

The SAQ Types at a Glance

Question counts are approximate and shift slightly between v4.0 and v4.0.1 documents, but the relative effort is accurate: SAQ A is a week of work; SAQ A-EP or C is a real security program; SAQ D approaches the effort of a full assessment.

The SAQs Most Startups Actually Face

SAQ A: Fully Outsourced

If your customers' card data goes directly from their browser to a PCI-compliant provider — via a full-page redirect or an iframe hosted entirely by the provider — and you never receive, store, or transmit account data, SAQ A likely applies. Checkout-hosted flows from major processors typically qualify.

Do not assume SAQ A is trivial anymore. v4.x expanded it: even fully outsourced merchants must address the security of the page that embeds or redirects to the payment provider. Following industry guidance issued in 2025, SAQ A merchants must confirm their site is not susceptible to script-based attacks — in practice by managing scripts on the page that leads to payment and confirming eligibility with their acquirer — because attackers compromise the merchant's page to swap the legitimate iframe or redirect for a malicious one.

SAQ A-EP: The Expensive Middle Ground

If your website serves the code that creates the payment form — for example, a JavaScript integration where fields are rendered by a script executing in the context of your page — you affect the transaction's security even though card data flows directly to the provider. That pushes you to SAQ A-EP, which pulls in most of Requirements 1, 2, 5, 6, and significant parts of 8, 10, 11, and 12 — roughly 150 questions, plus quarterly ASV scans and annual penetration testing.

The A vs A-EP boundary is the most consequential integration decision an e-commerce startup makes. An iframe/redirect integration can literally save you six figures of compliance effort compared to a JS-field integration, with minimal UX difference. Check your specific integration against your provider's PCI guidance — most major providers document exactly which of their integration modes map to SAQ A vs A-EP.

SAQ D: The Full Standard

SAQ D applies when nothing narrower fits: you store PANs, you process card data through your own systems, or you're a service provider validating by self-assessment. It covers all 12 requirements. If you find yourself facing SAQ D, first ask whether re-architecting (tokenization, P2PE, outsourcing) could drop you into a smaller SAQ — that redesign is almost always cheaper than sustaining SAQ D year over year.

Eligibility Rules and Multiple Channels

Every SAQ except D has eligibility criteria printed in its front matter — a list of statements that must all be true. Read them literally. If one criterion fails ("merchant does not store account data electronically" and you have PANs in a legacy database), you are not eligible, no matter how convenient the shorter SAQ would be.

Two rules trip up growing companies:

1. One SAQ per channel. If you run e-commerce (SAQ A) and a call center keying cards into a virtual terminal (SAQ C-VT), you validate each channel against its applicable SAQ — or consolidate under SAQ D. Talk to your acquirer about how they want multiple channels reported.
2. Your acquirer has the final word. SAQ selection is ultimately determined by your acquiring bank or the card brands, not by you. Acquirers can demand a more rigorous SAQ, a QSA-assisted SAQ, or a ROC at their discretion — especially after a security incident.

Completing the SAQ Correctly

The process, end to end:

1. Confirm scope. Perform the annual scope confirmation Requirement 12 demands — payment channels, data flows, systems, and third parties. Your SAQ answers are only meaningful for a correctly defined scope.
2. Verify eligibility. Check every eligibility criterion for your chosen SAQ against your actual architecture.
3. Answer each question with one of the defined responses: In Place, In Place with CCW (compensating control worksheet), Not Applicable (with justification), Not Tested, or Not in Place. v4.x SAQs also note where the customized approach is available.
4. Document N/As. "Not Applicable" without a written justification is a common reason acquirers bounce SAQs back.
5. Attach evidence of required scans. If your SAQ requires ASV scans (A-EP, B-IP, C, D), you need four passing quarterly scans — or, in your first year, at least one passing scan plus a documented quarterly schedule.
6. Complete the AOC and have it signed by an officer of the company. This signature is a formal representation to your acquirer; treat it with the seriousness of a financial certification.
7. Submit to your acquirer (or customer, for service providers) and calendar the next annual cycle — plus quarterly scans and any semi-annual tasks like access reviews and segmentation tests for service providers.

Common SAQ Mistakes

• Choosing the SAQ by desired effort rather than actual data flow. The classic failure: claiming SAQ A while running a JS-based payment integration that requires A-EP. Post-breach, this misclassification converts into liability.
• Forgetting side channels. Support agents accepting card numbers by phone or email, chargeback documentation containing PANs, or an old export file put you outside your SAQ's eligibility instantly.
• Marking controls "In Place" aspirationally. The AOC is a signed attestation. If MFA is "mostly rolled out," it is Not in Place. Use the remediation-plan route honestly.
• Missing a quarterly ASV scan. Four passing quarterly scans means four; a missed Q2 cannot be retroactively fixed.
• Treating the SAQ as an annual event. v4.x expects business-as-usual security. Access reviews, log review, script inventories, and scan cadences run all year; the SAQ merely summarizes them.
• Not collecting AOCs from your own providers. Your SAQ leans on the compliance of your payment provider, hosting provider, and other TPSPs. Requirement 12 obliges you to track their status annually.

SAQ Preparation Checklist

• Payment channels enumerated and a data flow diagram completed for each
• SAQ type identified per channel and eligibility criteria verified line by line
• Payment provider's documentation checked for which SAQ your integration mode supports
• Acquirer consulted on SAQ selection and submission format
• Card data discovery run (databases, logs, file shares, email, recordings) to confirm storage assumptions
• AOCs collected from all third-party providers; responsibility matrix documented
• Required ASV scans scheduled and passing; pen test done if your SAQ requires it
• Every "Not Applicable" answer has a written justification
• Remediation plan with dates for anything Not in Place
• AOC signed by an authorized officer and submitted; next year's cycle calendared

Frequently Asked Questions

Who is allowed to use an SAQ instead of a QSA assessment?

Generally Level 2–4 merchants and Level 2 service providers, subject to acquirer and card brand rules. Level 1 merchants and Level 1 service providers need a QSA (or qualified Internal Security Assessor) Report on Compliance. Mastercard additionally requires Level 2 merchants to have their SAQ work involve an ISA or QSA.

We use Stripe Checkout / a hosted payment page. Which SAQ applies?

A full redirect or provider-hosted checkout page typically qualifies for SAQ A. A JavaScript integration where the payment fields render within your own page context typically maps to SAQ A-EP. Providers publish integration-to-SAQ mappings — verify against their current documentation and confirm with your acquirer rather than assuming.

Do SAQ A merchants really have to worry about payment page scripts?

Yes. The v4.x e-commerce anti-skimming requirements (script management and tamper detection) reflect how modern card theft actually happens — compromising the merchant page that hosts the redirect or iframe. In 2025 the Council moved the detailed script requirements out of the SAQ A document itself but paired that with acquirer-confirmed eligibility criteria that your site is not susceptible to script attacks. Either way, you cannot ignore the security of your checkout page.

Can we complete an SAQ if some controls aren't in place?

You can submit with items marked Not in Place plus a remediation plan and target dates, but your AOC will show non-compliance and your acquirer decides what happens next. What you cannot do is mark them In Place anyway — that converts a compliance gap into misrepresentation.

How long does an SAQ take to complete?

SAQ A: days, assuming a clean outsourced flow. SAQ A-EP or C: typically 2–4 months the first time, because the underlying controls (scanning, logging, MFA, hardening) must actually exist before you can attest to them. SAQ D: 4–9 months for a first pass, comparable to preparing for a QSA assessment.

Does anyone verify our SAQ answers?

Usually not proactively — that is the "self" in self-assessment. Verification arrives after a breach, when a PCI Forensic Investigator reconstructs what was actually true versus what was attested. The gap between the two determines fines, liability, and whether your acquirer keeps you. Answer as if the audit will happen, because eventually it might.

In the next lesson, we will cover network segmentation.

Tracking SAQ controls, scan schedules, and provider AOCs is exactly what compliance automation platforms do well. AuditXYZ helps you compare compliance automation tools and auditors to find one that supports your SAQ type without paying for scope you don't have.