How to Fill Out a PCI SAQ Without the Common Mistakes

To fill out a PCI SAQ correctly, confirm with your acquirer which SAQ applies, check every eligibility criterion before you answer anything, map your scope, answer each requirement only where you can show evidence, explain every “Not Applicable” response and have an executive officer sign the Attestation of Compliance (AOC). Most SAQ errors come from rushing the first two steps.

A Self-Assessment Questionnaire (SAQ) looks like paperwork. In practice it is a signed statement to your acquirer that your business meets a defined set of PCI DSS requirements. When it is wrong, the problem usually surfaces at the worst possible moment: after a breach, when a forensic investigator compares what you signed with what was actually in place. These are the mistakes we see most often when reviewing SAQs, and how to avoid them.

Key takeaways

• The AOC is a signed declaration, so every answer needs evidence behind it.
• Picking the wrong SAQ type is the most common and most costly error.
• Outsourcing payments reduces your scope but never removes your responsibility.
• SAQs must reflect PCI DSS v4.0.1, including the requirements that became mandatory on 31 March 2025.
• “Not Applicable” answers and compensating controls need written justification.

How to fill out a PCI SAQ, step by step

Work through the SAQ in this order. Skipping ahead to the requirements is where most mistakes start.

Your PCI compliance level decides whether you can self-assess at all. The SAQ forms themselves are in the PCI SSC document library.

PCI SAQ completion checklist

Before anyone signs, check that each step has the evidence behind it and a named owner:

What are the most common PCI SAQ mistakes?

Mistake 1: Choosing the wrong SAQ

There are several SAQ types, and each has strict eligibility criteria. Merchants often choose the shortest one they think might fit, rather than the one that matches how they take payments. Typical errors include:

• Using SAQ A when the website’s own code builds or influences the payment form, which usually means SAQ A-EP applies instead.
• Using SAQ B-IP or C-VT when the payment device or workstation is connected to other systems on the network.
• Completing one SAQ when the business has several payment channels, such as e-commerce plus a telephone team, without checking with the acquirer how to cover both.

If you are unsure, our guide to which PCI SAQ you need walks through the options, and SAQ A vs SAQ A-EP covers the e-commerce distinction in detail. Our free PCI compliance check also suggests your likely SAQ from how you take payments.

Mistake 2: Drawing scope too narrowly

Scope covers every system component that stores, processes or transmits card data. It also includes systems that are connected to those components or that can affect their security, such as authentication servers, logging tools and the workstations used to administer them.

The classic error is the flat network. A merchant assumes the card terminal or payment server is “separate” because it sits in a different room or has its own IP range, but nothing actually stops traffic from the office network reaching it. Without effective segmentation, the whole network is in scope.

If you rely on segmentation to reduce scope, it must be proved. Requirement 11.4.5 requires segmentation testing at least once every 12 months and after changes to segmentation controls, in SAQs that include it.

Mistake 3: Assuming outsourcing removes responsibility

Using a payment gateway, a hosted checkout or a cloud platform can shrink your scope dramatically. It does not transfer accountability. Under Requirement 12.8 you must still:

• Keep a list of the third-party service providers that handle card data or could affect its security.
• Have written agreements in which those providers acknowledge their responsibility for the data.
• Monitor their PCI DSS compliance status at least once a year, usually by obtaining their current AOC.
• Know which requirements each provider manages and which remain with you.

An expired or missing provider AOC is one of the simplest findings to avoid.

Mistake 4: Answering against an old version of the standard

PCI DSS v4.0.1 is the current version. The requirements that v4.0 introduced as “future-dated” became mandatory on 31 March 2025, so answers that were acceptable under v3.2.1 may no longer be enough. Areas that often catch merchants out include:

• Multi-factor authentication. Requirement 8.4.2 extends MFA to all non-console access into the cardholder data environment, not just remote access.
• Passwords. Requirement 8.3.6 raises the minimum length to 12 characters, or 8 where a system cannot support 12.
• Phishing. Awareness training must cover phishing and social engineering (12.6.3.1).
• E-commerce scripts. For SAQ A-EP and other in-scope payment pages, Requirements 6.4.3 and 11.6.1 require you to authorise and inventory every script on the payment page and detect unauthorised changes.

SAQ A changed again in January 2025. Requirements 6.4.3 and 11.6.1 were removed from it and replaced with an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s). That is a statement you need to be able to justify, not a formality.

Mistake 5: Misusing “Not Applicable” and compensating controls

Each requirement is answered with one of a small set of responses, such as “In Place”, “In Place with CCW” (compensating control worksheet), “Not Applicable” or “Not in Place”. “Not Applicable” is the most abused. It is correct only when the requirement genuinely does not apply to your environment, and each one must be explained in the relevant appendix. Marking MFA as not applicable because “we are a small team” is not a valid justification.

Compensating controls are legitimate when you cannot meet a requirement as written because of a documented technical or business constraint. They need a completed worksheet showing how the alternative control meets the intent of the original requirement. The customised approach introduced in v4.0 is a different mechanism, available only through a Report on Compliance, so it cannot be used in an SAQ.

Mistake 6: Missing or failing ASV scans

Where your SAQ includes Requirement 11.3.2, you need a passing external ASV scan by a PCI SSC Approved Scanning Vendor at least once every three months. Common problems are scans that miss some of your public IP addresses or domains, a failed scan with no rescan in the same quarter, and disputed findings with no supporting evidence. For your first validation, one recent passing scan is accepted if you have documented quarterly scanning procedures and have fixed and rescanned anything found.

Mistake 7: Treating the SAQ as a once-a-year event

An SAQ covers your compliance over the year, not on the day you sign it. Internal scans, access reviews and training all run at frequencies the standard sets, and Requirement 6.5.2 expects you to confirm that applicable requirements are in place once a significant change is complete. A simple compliance calendar with named owners prevents most of these misses.

Mistake 8: Signing without evidence

Every “In Place” answer should be something you could demonstrate if asked. Before signing, check that you can produce:

• The network and data flow diagrams that show your scope
• Current AOCs from each relevant service provider
• Your quarterly scan reports, where scanning applies
• Approved policies and records of security awareness training
• Evidence for any compensating controls and justifications for any “Not Applicable” answers

If you cannot produce the evidence, the answer is not “In Place”. Our PCI compliance checklist lists the evidence assessors expect for each requirement, and the same evidence gaps cause most common PCI audit failures in full assessments.

What happens after you submit your SAQ?

Your acquirer reviews the SAQ and the Attestation of Compliance (AOC). It may accept them, ask questions, or ask for a remediation plan with dates for anything not in place. Submission starts the next cycle rather than ending this one:

• Keep the evidence. Store the signed AOC, the full SAQ and the evidence behind each answer. Your acquirer can ask for it, and a forensic investigator will after a breach.
• Keep scanning. Where your SAQ includes Requirement 11.3.2, run an external ASV scan every quarter and keep each passing report; some acquirers ask you to upload them.
• Check changes before they go live. A new payment channel, provider or website change can alter your SAQ type or eligibility.
• Revalidate every year. The SAQ and AOC are completed annually, so put the next date in your compliance calendar now. Our PCI DSS compliance roadmap includes a year-round calendar you can adapt.

Should a QSA review your SAQ?

A QSA is not required to sign an SAQ. If you are completing a PCI SAQ for the first time, or your payment set-up has changed, a short review of your draft by an experienced assessor catches most of the errors above before your acquirer sees them: the wrong SAQ type, a scope boundary that will not hold, a weak “Not Applicable” justification or a missing provider AOC.

Sovereign Secure is a PCI SSC-approved QSA company. Our PCI DSS consultant team reviews SAQs and runs pre-submission gap analyses, and where a merchant has outgrown self-assessment, our assessors carry out a full PCI compliance audit.