PCI DSS Self-Assessment Questionnaire (SAQ) Explained

A Self-Assessment Questionnaire (SAQ) is the document merchants and service providers use to validate PCI DSS compliance without a full on-site audit. You answer a fixed set of questions about the controls that apply to how you accept cards, sign an Attestation of Compliance (AOC), and submit both to your acquirer or payment brand. It's the route most small and mid-size merchants take — a full Report on Compliance (ROC) signed off by a QSA is only required at the highest transaction tiers or when a brand specifically asks for it.

The SAQ isn't one document. There are nine variants in PCI DSS v4.0.1, and picking the right one is the single most important decision in the process. Choose too narrow an SAQ and you're attesting to controls that don't actually cover your payment flow — which is a compliance gap and a breach-liability problem. Choose too broad an SAQ and you're doing months of pointless work answering questions about systems that never touch cardholder data.

The SAQ types and who they're for

Each SAQ targets a specific way of accepting payments. The key question is always: does your environment ever store, process, or transmit cardholder data, and if so, how?

SAQ A

For card-not-present e-commerce merchants who've fully outsourced all cardholder data handling to a PCI DSS validated third party. Your website redirects or embeds an iframe from a payment service provider — your servers never see card numbers. SAQ A is the shortest variant (around 30 questions in v4.0.1) and is the one most small online merchants complete. You still have to confirm your site can't be tampered with to redirect customers to a fake payment page, which is why SAQ A in v4 added script-integrity and change-detection requirements.

SAQ A-EP

For e-commerce merchants who outsource the payment page but whose website still controls how the payment form is loaded — for example, you serve the page that contains the iframe, or your JavaScript builds the payment request. Your servers don't store card data, but they can influence the page that captures it. SAQ A-EP is far longer than SAQ A (around 150 questions) because your web infrastructure is in scope.

SAQ B

For merchants using only standalone, dial-out (non-IP) payment terminals or imprint machines. No internet connection, no electronic storage. Rare in 2026 but still valid for some low-volume face-to-face retailers.

SAQ B-IP

For merchants using standalone IP-connected PIN entry devices. The terminal is on the network but no other systems store, process, or transmit cardholder data. Smaller question set than SAQ C.

SAQ C

For merchants with payment application systems connected to the internet — typical for small in-store POS setups. The systems involved in payments are isolated from the rest of your network.

SAQ C-VT

For merchants who key card details into a virtual terminal on an isolated device connected to a PCI-validated payment processor. No card data stored locally.

SAQ P2PE

For merchants using only PCI-listed P2PE solutions. The shortest in-person SAQ — because the P2PE solution provider has done the heavy lifting, your environment is treated as out of scope for most controls.

SAQ D for Merchants

The catch-all. If your payment environment doesn't fit any of the above — for example you store cardholder data, accept multiple channels with different controls, or have a custom integration — you fill in SAQ D. It covers all 12 PCI DSS requirements and runs to around 330 questions.

SAQ D for Service Providers

The service-provider equivalent. Any PCI-validated service provider eligible to self-assess (most are required to do a ROC) uses this one.

How the SAQ process actually works

The questionnaire itself is only part of the job. The PCI Security Standards Council publishes each SAQ as a PDF you fill in, but to attest honestly you need to do four things in order.

1. Scope your cardholder data environment. Map every system, process, and third party that stores, processes, or transmits cardholder data, plus everything connected to those systems. Underscoping the CDE is the most common reason SAQs end up being effectively false. Cardholder data environment (CDE) scoping needs to be documented — auditors and forensic investigators will ask for the network diagram.

2. Pick the right SAQ type. Use the eligibility criteria at the front of each SAQ. If you accept cards through more than one channel — say, e-commerce plus telephone — you typically need to complete an SAQ for each channel, or fall back to SAQ D.

3. Test each requirement. An SAQ is not a checklist of intentions. Each question asks whether a control is in place — and the answer must be supported by evidence (policies, configurations, logs, sample records). "In place" means tested in the last 12 months.

4. Sign the Attestation of Compliance. The AOC is the legally meaningful document. It's signed by a company officer and submitted to your acquirer. False attestation is treated harshly if a breach later reveals controls weren't in place.

What changed in PCI DSS v4.0.1

The current SAQ versions reflect PCI DSS v4.0.1, published June 2024. The v4 transition deadline passed on 31 March 2025, so every SAQ submitted today should be against v4.0.1 — v3.2.1 is retired. The two changes that catch most merchants out:

• Script management on payment pages (Requirement 6.4.3 + 11.6.1). Even SAQ A merchants now have to inventory scripts loaded on payment pages and detect unauthorised changes. This was a direct response to Magecart-style skimming attacks.
• Customised approach option. For most controls, you can now meet the intent of a requirement through alternative means — but you have to document the customised implementation and have it reviewed. Customised approach isn't available to SAQ A merchants.

Where most SAQs go wrong

Three patterns we see repeatedly when reviewing merchant compliance posture:

Telephone payments treated as out of scope. A merchant completes SAQ A for their website and forgets that the call centre also takes card-not-present payments by phone. The phone channel makes the entire contact centre — agents, recording systems, screen capture, CRM — part of the CDE. DTMF masking for telephone payments is the standard way to cut that scope back down. Without it, SAQ A doesn't cover you and you almost certainly need SAQ D.

Underscoping the network. Anything connected to the CDE — even a printer or a workstation — is in scope. "Connected to" includes shared VLANs, shared authentication systems, and management networks.

Stale evidence. The questions read "is the control in place" but the evidence to support a yes has to be current. Pen test from 18 months ago, vulnerability scan from last year, policy not reviewed since 2022 — all of those mean the answer should be no.

SAQ A vs. SAQ D for contact centres

If you take any card payments by phone and your agents can hear card numbers, you are not eligible for SAQ A regardless of how secure your e-commerce stack is. Phone payments put your contact centre in the CDE. To stay on SAQ A — or to drop a call centre out of scope entirely — you need a telephone payment solution that prevents the agent from hearing the DTMF tones or seeing the digits. Contact centre PCI compliance explains the architecture. Done correctly, the agent and the recording system never receive cardholder data, so the contact centre falls back out of scope and SAQ A becomes valid again.