PCI compliance checklist, filtered by your SAQ type

What this checklist covers

PCI DSS v4.0.1 groups its rules under 12 requirements, from network security controls (1) to policies and programs (12). Most small merchants never face all of them: the Self-Assessment Questionnaire (SAQ) your acquirer accepts holds only the requirements that fit the way you take cards. This checklist does the same filtering. Pick one of 9 merchant SAQ types and it lists that SAQ's jobs in plain words, grouped by requirement, each with the requirement number you will find in your form.

It is a working list, not the questionnaire. The SAQ forms sit behind the PCI Security Standards Council's license, so every line here is our own summary of the requirement text, which the Council publishes openly in its Prioritized Approach Tool. When you fill in the real form, the numbers tell you which line answers which question. If you have not settled your SAQ yet, the SAQ type finder asks about your terminals, checkout and phone orders first, and PCI SAQ types explained walks through each one.

How to use it

1. Pick your SAQ type. The list, the line count and the recurring count change at once. Arriving from the finder sets it for you.
2. Start with “Before you start”. Those lines confirm you still qualify for the SAQ. If one fails, your SAQ type is wrong, and the rest of the list is too.
3. Tick lines as you finish them. Ticks stay in this browser, so you can close the page and pick up later. Switch the view to “Open lines” to see only what is left.
4. Print it or copy it for the binder, your bookkeeper or whoever signs the Attestation of Compliance. The print shows the list only, with your ticks.
5. Come back for the recurring lines. Switch to “Recurring” for the jobs that repeat: scans, reviews, training. Put them in the PCI deadline calendar.

Worked example: a café with one countertop terminal

A café takes cards on a standalone terminal from its processor. The terminal is on the Council's list of approved PTS devices, plugs into the café's router, and sits on its own network segment, apart from the till PC and the guest Wi-Fi. Nothing is stored electronically; the only card data on site is the merchant copy of the occasional paper receipt. That is SAQ B-IP.

Picking SAQ B-IP gives 22 lines across 6 requirement families plus the eligibility and paperwork block, and 5 of them repeat. The heavy work sits in Requirement 9: a list of the terminal's make, model and serial number, a regular look for tampering, and staff who check the identity of anyone who says they have come to repair it. Requirement 1 is the network segment that keeps the terminal apart. The scan line asks the café to look for Requirement 11.3.2 in its form and ask the acquirer if unsure; we do not guess it for SAQ B-IP.

The recurring work, by how often it comes round

The list is not a one-off. These lines repeat on the schedule the requirement itself sets; the SAQ and the Attestation repeat on the schedule your acquirer or the card brand sets. The last column shows which SAQ types put each line on the checklist.

SAQ A-EP, SAQ B-IP, SAQ C-VT, SAQ C: each carries a scan line worded as a check of your own form, because the open Council documents do not say whether those forms include Requirement 11.3.2.

Where the rules come from

• Who sets your SAQ. The Council writes the standard; it does not decide who validates or how. In its words, “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.” That is why the first line of every list sends you to your acquirer.
• SAQ A, January 2025. The Council removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1” from SAQ A, and added an eligibility criterion that the merchant “confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).” The SAQ A list therefore has no script-inventory line and carries that criterion under “Before you start”. More in PCI SAQ A.
• Req. 11.3.2 and 11.3.2.1. SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor's payment page, so an SAQ A website is not scan-free. Scans run at least once every three months by an Approved Scanning Vendor; pick one from the Council's ASV list. Where the passing report goes is the brand's or acquirer's call: “Scan customers should contact their acquiring bank or each Participating Payment Brand to determine to whom results should be submitted.”
• Req. 12.8.1. Handing card data to a processor shrinks the list, but it never empties it: “The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.” Every SAQ type here keeps the service provider lines in Requirement 12.
• SAQ D. SAQ D for Merchants covers every requirement, so its list is the longest and touches every family. If yours is SAQ D, read PCI SAQ D before you start.