Start with the payment flow, not the questionnaire
A small business might take payments through a hosted checkout, an embedded online form, a countertop terminal, and occasional telephone orders. These channels do not necessarily have the same systems, risks, or validation route. A checklist that ignores the differences can leave the team answering questions about the wrong environment.
The first task is to understand where account data goes and which systems can affect payment security. The next task is to confirm the correct validation route. PCI Security Standards Council guidance tells organizations to confirm Self-Assessment Questionnaire eligibility and submission requirements with their compliance-accepting entity, commonly an acquirer or payment brand.1
This article provides an original preparation checklist. It does not reproduce the PCI DSS requirements or SAQs, select a questionnaire for your business, or establish a compliance result. Use the Council's current materials and obtain appropriate advice for your actual payment environment.
Draw each channel separately
Write down every way a customer can pay, including less frequent processes. A secure main checkout does not explain what happens when a staff member receives card information by phone, email, or a handwritten note.
Use a simple flow with five stages: customer entry, merchant-controlled systems, payment provider, settlement or reporting, and any stored records. Record which party controls each stage and whether data appears in logs, receipts, exports, help-desk tickets, or recordings.
| Channel | Questions to resolve before choosing a checklist |
|---|---|
| Hosted checkout reached by redirect | Where does the customer enter card data, and what can the merchant page influence? |
| Embedded payment form | Which parts are provided by the processor, and what scripts can affect the surrounding page? |
| In-person terminal | What device, connection, provider, and operating process are used? |
| Telephone or mail order | Who receives the information, through what equipment, and where could it be retained? |
| Subscription or saved payment method | What token or account reference is retained, and what responsibilities remain? |
These questions are a scoping aid, not a declaration that each channel qualifies for a particular SAQ. Ask the accepting entity about mixed channels and any changes from the prior assessment.
Confirm current versions and timing
Use PCI DSS v4.0.1 materials and the applicable current SAQ version. The Council's October 2024 bulletin announced the v4.0.1 SAQs and the retirement of the prior v4.0 materials. Its guidance also emphasizes confirming eligibility and instructions rather than assuming the form is appropriate.1
The March 31, 2025 transition for the v4 requirements originally described as future-dated has already passed. In October 2026, those provisions should not be described as still optional merely because an older guide calls them “future requirements.”2
Record the document version and the date of the accepting entity's instructions in the assessment file. If the payment flow or provider changes, revisit the selection rather than copying last year's answers automatically.
Understand the embedded-form distinction
The Council's February 2025 FAQ explains a specific SAQ A eligibility criterion concerning script attacks. It applies to merchant pages containing an embedded payment page or form, such as an iframe. That particular criterion does not apply to pages that redirect the customer to the processor or fully outsource payment functions in the ways described by the FAQ.3
This is a narrow distinction. It is not an exemption from every other eligibility condition, assessment obligation, or security consideration. The FAQ explicitly says its explanation does not override the other criteria. Confirm the complete applicable requirements with the accepting entity.3
For an embedded form, ask the provider for secure implementation instructions and specific confirmation of how its solution addresses the relevant script risk. Retain the answer and check that your implementation follows it. A general statement that the provider “handles PCI” is not the same as evidence about your page.
A fictional online shop example
A fictional retailer sells through a hosted payment redirect. Customer support occasionally sends payment links. The owner initially assumes these are the only channels. Interviews reveal that a staff member also takes telephone orders and records details before entering them into a provider's interface.
The shop creates this original evidence inventory:
| Item | Current observation | Follow-up |
|---|---|---|
| Web checkout | Customer enters data on the provider's page | Retain the implementation diagram and provider instructions |
| Payment links | Links direct to the provider | Confirm current process and staff training |
| Telephone orders | Separate manual workflow discovered | Ask the accepting entity about scope and validation route |
| Website access | Two administrator accounts; responsibilities unclear | Confirm authorized users and review access controls |
| Provider responsibilities | Marketing statement available, detailed allocation missing | Obtain appropriate current documentation and responsibility allocation |
| Evidence handling | Working notes contain sensitive details | Replace with controlled, appropriately minimized records |
The useful result is not a completed questionnaire. It is a corrected understanding of the environment, an explicit unresolved scope question, and work assigned to the owner. The shop should not submit a form selected for only one channel while ignoring another.
Build a checklist around decisions and evidence
Once the accepting entity confirms the validation route, create a working checklist alongside the official materials. The following fields make the original record easier to review:
- Requirement or question reference: identify the relevant item without copying an entire standard into the spreadsheet.
- Applicability or eligibility decision: record the rationale and who confirmed it.
- System, location, or process: state what the answer concerns.
- Responsible party: distinguish your business, the provider, and shared work.
- Evidence: link to a current record, configuration, test, or procedure.
- Gap and corrective action: identify what remains unverified or incomplete.
- Reviewer and date: preserve who evaluated the response and the version used.
Use statuses such as “supported by evidence,” “needs confirmation,” and “corrective action open.” Do not automatically translate every provider response into a compliant answer. If a control is shared, your part still needs to be identified and checked.
Store the working file securely. Use synthetic examples in training and demonstrations. Do not ask staff to paste real card data into general-purpose documents, AI tools, support tickets, or collaboration channels to explain a problem.
Examine the provider relationship
Request documentation relevant to the specific service you use, its current validation status, and the division of responsibilities. The same provider can offer multiple products with different implementation models. A document covering one service should not be assumed to cover every feature of the relationship.
Ask what your business must configure, operate, and monitor. Ask how changes are communicated and what evidence is available. Where a response is unclear, record the uncertainty and seek clarification before relying on it.
This is also a practical vendor-risk task. A payment provider can be central to business availability even when the merchant sees little account data. Keep commercial dependency and recovery planning visible alongside the assessment work.
Turn gaps into controlled corrective work
For each gap, define the affected payment channel, the owner, the intended change, and a test that will show the result. A webpage update should be checked in the actual payment flow. A staff procedure should be rehearsed with a synthetic example.
Do not mark an action complete solely because a ticket was closed or a provider sent an email. Record what was tested, when, by whom, and what remains uncertain. Use the remediation-plan template for this follow-up.
Keep the assessment route and submission decision separate from the work tracker. Completing internal tasks does not authorize an employee to sign a compliance declaration on behalf of the business.
Frequently asked questions
Does using a payment processor remove PCI DSS responsibilities?
It can reduce or change the merchant's scope, depending on the implementation. It does not justify assuming there are no remaining responsibilities. Confirm the current flow, full eligibility criteria, and required submission with the accepting entity.
Is this article an SAQ?
No. It is an original preparation checklist. Obtain the appropriate current questionnaire from official sources and follow the accepting entity's instructions.
Should a small business use the shortest questionnaire?
Use the questionnaire appropriate to the actual environment and eligibility, not the one with the fewest questions. Uncertain or mixed channels require confirmation.
Does completing a checklist mean the business is certified?
No. A planning checklist is not a certification or an independent assessment. It helps gather facts, identify gaps, and prepare for the applicable validation process.
Sources and references
-
PCI Security Standards Council. SAQs for PCI DSS v4.0.1 Now Available (2024-10-15). Official bulletin says entities should confirm SAQ eligibility and submission requirements with their accepting entity. ↩ ↩2
-
PCI Security Standards Council. PCI DSS v4: What’s New with Self-Assessment Questionnaires (2024-03-27). Supports March 31, 2025 future-dated transition only; later FAQ is used for revised SAQ A eligibility. ↩
-
PCI Security Standards Council. FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?. February 2025 FAQ distinguishes embedded payment forms from redirect/fully outsourced flows; full eligibility still must be checked. ↩ ↩2