PCI Self-Assessment Questionnaires (SAQs)

This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.

You got a PCI self-assessment questionnaire from your acquiring bank. It's long, much of it seems irrelevant to your actual environment, and you're not sure what most of the questions are asking. You need to understand what SAQs actually are, which one you're supposed to complete, and how to answer accurately without accidentally committing fraud on your attestation document. Many organizations fill out SAQs incorrectly because they don't understand the questions, misinterpret their scope, or simply guess at answers. That's how compliant-on-paper organizations end up in serious trouble during an actual audit or breach investigation.

An SAQ is a self-assessment tool—a questionnaire designed to help you evaluate your PCI DSS compliance. It's your roadmap to understanding what controls you should have, where you likely have gaps, and whether you're actually secure. An Attestation of Compliance (AOC) is your signed statement that you've completed the SAQ and are compliant with the requirements. That's what you submit to your acquiring bank. Getting the SAQ right is important; what matters legally is the AOC because that's where you're asserting truthfulness. False attestation on an AOC has legal consequences.

Different SAQs for Different Merchant Environments

The PCI Council provides different SAQs for different merchant types and environments. Choosing the right one is critical because the wrong SAQ creates confusion about what you're actually responsible for. Your acquiring bank should tell you which SAQ applies to your situation, but understanding them yourself prevents mistakes and helps you ask intelligent questions.

SAQ A is for merchants who use an external payment processor or payment service provider and never directly handle cardholder data. If you use Stripe, Square, PayPal, or any hosted payment solution and those processors handle all card data, you're likely SAQ A. The questionnaire is short because your scope is minimal—you're verifying that your connection to the processor is secure and that you have an incident response plan. This is the simplest SAQ.

SAQ A-EP is for merchants using e-commerce solutions with an Approved Integrator (a third party that handles the payment processing integration on your behalf). It's similar to SAQ A but includes additional questions about e-commerce specific controls.

SAQ B-IP is for merchants with IP-connected payment terminals but minimal card data storage. You use payment terminals to process cards, but the terminal handles the data and you never store card information. The questionnaire focuses on terminal security and network isolation.

SAQ B is for merchants with payment terminals but limited system complexity. It's more extensive than SAQ B-IP but still focused on terminal-specific controls. You might be SAQ B if you run a retail operation with a point-of-sale system that processes cards but you're not storing credit card data in your own systems.

SAQ C is for merchants with basic internet connectivity and simple systems. You might handle some card data but your environment is straightforward—maybe a small business with a single payment application and limited staff access. The questionnaire covers basic network security and access controls.

SAQ D is the most comprehensive. You're SAQ D if you have complex systems, handle and store cardholder data, develop custom payment solutions, or have an environment that doesn't fit neatly into the other categories. SAQ D is lengthy because you're being asked about all twelve requirements in detail. Many Level 1 merchants and payment processors complete SAQ D because their environments are complex.

The critical first step is correctly identifying which SAQ applies to you. Wrong SAQ means you're either overstating compliance obligations (implementing controls you don't actually need) or understating them (missing critical controls). Ask your acquiring bank explicitly which SAQ they require you to complete. If you're uncertain, err on the side of a more comprehensive SAQ rather than a simpler one. It's better to implement extra controls than to discover later that you misinterpreted your scope.

Understanding What the Questionnaire Is and Isn't

An SAQ is a tool for self-assessment, not a compliance document. It helps you evaluate your current state. It should reveal gaps you need to address. If you complete an SAQ honestly and find major deficiencies, that's the questionnaire working correctly—it's telling you what you need to fix before you submit an attestation.

Many organizations complete SAQs without understanding this distinction. They fill it out quickly, submit an attestation, and assume they're compliant. If an auditor later tests their controls and finds they don't actually work, they've created a serious problem. They've attested to compliance under penalty of perjury and then failed to demonstrate it.

The questionnaire is also not a final compliance determination. Even if you answer yes to all questions and have supporting documentation, you're not certified compliant. You're asserting that you've implemented the controls described in the framework. An auditor will verify whether those assertions are true. An SAQ is your self-assessment. An audit is independent verification.

The Questions: Yes Answers Versus No Answers

SAQ questions are yes/no with space for commentary and evidence. Answering yes means you're certifying that the control exists in your environment and is functioning. Answering no means either the control doesn't exist or doesn't apply to your environment.

The temptation is to answer yes to look compliant or to avoid additional requirements that a no answer might trigger. That creates a trap. Answering yes when the control doesn't actually exist means you've attested to something false. If an auditor tests that control and discovers it doesn't work, you've committed attestation fraud. That's worse than having a gap you're honestly remediating.

Better to answer accurately. If you answer no to network segmentation because you don't have it, that becomes a finding you need to remediate before you submit your final attestation. But at least you're telling the truth. You can develop a remediation plan, implement the control, and then re-answer the question truthfully. If you'd answered yes initially and auditors discovered no network segmentation exists, you've created a legal problem that goes beyond compliance.

This is why many organizations don't submit their final attestation until they've worked through the SAQ completely, addressed gaps, and verified that their answers align with reality. The questionnaire is a planning tool first, an attestation document second.

Supporting Documentation and Evidence

SAQ answers require documentation. "Yes, we perform network segmentation" requires firewall rules, network diagrams, and evidence of isolation—not just a yes answer. "Yes, we encrypt cardholder data" requires encryption configuration documentation, key management procedures, and proof of encryption implementation. "Yes, we monitor logs" requires samples of reviewed logs, incident response records, or monitoring system screenshots.

Before you submit an SAQ claiming compliance, gather supporting documentation for every yes answer. If an auditor or your acquiring bank requests evidence, you need to be able to produce it immediately. Many organizations complete SAQs without assembling supporting documentation, creating risk of being asked to remediate or re-attest if the documentation is challenged.

The good news is that you probably already have much of this documentation. Network diagrams, firewall configurations, encryption key management procedures, and access control policies likely exist somewhere in your environment. You just need to compile them in a coherent way that demonstrates the control is implemented and functioning.

Red Flags That Trigger Further Scrutiny

Certain SAQ answers raise red flags with auditors and acquiring banks. Any cluster of no answers to basic controls like encryption, network segmentation, or access control suggests significant risk. Answering no to vulnerability scanning or penetration testing indicates inadequate verification practices. Answering no to incident response plans suggests unprepared breach response.

Acquiring banks use SAQs partly as risk filtering tools. If your SAQ shows major gaps, you might face additional requirements beyond self-assessment—a third-party audit, for example. This doesn't mean you've done something wrong. It means your acquiring bank wants independent verification of controls when self-assessment reveals significant risk.

The strategic approach is honesty paired with a remediation plan. If you answer no to a critical control, explain your remediation plan. "We currently don't have network segmentation in place, but we're implementing it by Q2." That shows intent to address the gap. It's better than answering yes and hoping an auditor doesn't test it.

The Different SAQ Types Explained in Practical Terms

If you're a small e-commerce business using Stripe, you're SAQ A. You're verifying that your website connects securely to Stripe, that your systems don't store card data, and that you have an incident response plan. The questionnaire is maybe 30 questions and takes a day or two to complete. Most of the answers are yes if you're using Stripe correctly.

If you're a retail operation with a point-of-sale system processing cards through a payment terminal, you're likely SAQ B-IP or SAQ B. You're verifying that your terminal is secure, that it's isolated from the rest of your network, that access to it is controlled, and that you have monitoring in place. The questionnaire is moderate length—maybe 80-120 questions depending on your environment.

If you're a healthcare practice processing credit cards for patient payments, you're probably SAQ C or SAQ D depending on whether you store card data. If you're using a hosted payment processor, you might be SAQ A. If you're storing card data for recurring charges, you're SAQ D. The questionnaire expands significantly with cardholder data storage because you have to address encryption, access controls, and monitoring at a more granular level.

If you're a payment processor, a large merchant with complex systems, or an organization that develops custom payment solutions, you're SAQ D. This is the comprehensive questionnaire covering all twelve requirements with detailed questions about your technical architecture, access controls, monitoring, and policies. An SAQ D can be 300+ questions. It's not something you complete in an afternoon.

How to Approach SAQ Completion Properly

The right approach to SAQ completion is methodical. First, determine which SAQ applies to you. Ask your acquiring bank if you're uncertain. Second, read through the entire questionnaire to understand the scope. Don't start answering immediately. Third, map your environment against the questions. Where are your systems? What systems touch card data? Who has access? How are you monitoring?

Fourth, gather documentation before you answer. Don't answer yes and then look for documentation later. Answer based on what you actually have. Fifth, complete the questionnaire honestly. If you don't have a control, say so. That's not failure—that's clarity. Sixth, develop remediation plans for any gaps. What do you need to implement? When will it be ready?

Seventh, implement the necessary controls. Testing, documentation, training, and all the operational details. Eighth, re-evaluate your answers. Do they accurately reflect your current environment? Ninth, assemble your supporting documentation. Can you prove every yes answer? Tenth, answer the final attestation question: are you honest in your assertions and able to verify your compliance? If the answer is yes, submit. If not, complete the remediation before submitting.

This approach takes time, but it prevents you from submitting an SAQ that doesn't align with reality and then having to explain discrepancies later.

The AOC: What You're Actually Signing

The Attestation of Compliance is the legal document you're signing. It says that you've completed the SAQ, reviewed your answers for accuracy, and are attesting to PCI DSS compliance. Some versions of the AOC include language about penalties for false statements, explicitly making clear that signing is a legal commitment.

Before you sign an AOC, be confident that your answers are accurate and that you can support them with documentation. A signer (usually a senior executive) is asserting to the acquiring bank that the organization is compliant. That assertion has legal weight.

If your organization later suffers a breach and an investigation reveals that your SAQ was inaccurate, the false attestation becomes evidence of negligence or fraud depending on the context. It's not something you want in an adversarial discovery process.

Closing: From Questionnaire to Actual Compliance

You now understand SAQs as honest self-assessment tools, not compliance theater. The questionnaire tells you what controls you should have. Your accurate answers reveal gaps you need to address. The AOC is where accuracy matters legally, not just for audit purposes.

Before submitting your SAQ, verify your answers against your actual environment. Have supporting documentation ready. If you're uncertain about any answer, that's usually a signal you need to either implement that control or document why it doesn't apply to your scope. The goal isn't to fill out a questionnaire. The goal is to understand your compliance state honestly and address gaps systematically. When you've done that work, the SAQ becomes a straightforward document reflecting genuine compliance rather than a checkbox exercise.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about PCI DSS as of its publication date. Standards, costs, and requirements evolve — consult a qualified compliance professional for guidance specific to your organization.