PCI DSS for Small Business: SAQ Types and IT Checklist

If your business accepts credit or debit cards, the Payment Card Industry Data Security Standard (PCI DSS) applies to you. It is a contractual standard, not a law, enforced through your agreement with the bank or processor that handles your card payments. Most small businesses validate once per year by completing a Self-Assessment Questionnaire (SAQ). How you take payments decides which SAQ you use, and that one choice sets how much IT work is involved: a couple dozen questions for a fully outsourced setup, or a few hundred if card data touches your own systems.

This is general information, not legal advice; your acquirer or processor decides what you must submit.

Does PCI DSS Apply to Your Business?

The PCI Security Standards Council (PCI SSC), the body founded by the major card brands to maintain the standard, says PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume.

Two details matter to a small business:

• The Council writes the standard. It does not enforce it. Whether and how you must validate is set by the card brands and carried out by your acquirer, the merchant bank behind your processor. The Council’s guidance is to ask your acquirer what it needs from you.
• Using a processor such as Square, Stripe, Clover, or a bank terminal does not remove your obligations. It can shrink them considerably, because the processor handles the card data on its own validated systems. You remain responsible for the devices, network, website, and people on your side.

The card brands sort merchants into levels by annual transaction volume. Small businesses are almost always in the lowest-volume level, which validates by SAQ instead of an on-site assessment. Your acquirer can tell you your level and its deadlines.

Which Version Is Current?

PCI DSS v4.0.1 was published on June 11, 2024. It is a limited revision with no new or deleted requirements. Version 4.0 was retired on December 31, 2024, so v4.0.1 is the only active version.

The bigger date was March 31, 2025. PCI DSS v4.0 introduced 64 new requirements, and 51 of them were future-dated: best practice until March 31, 2025, mandatory after. If your last careful look at PCI was before that date, your SAQ has changed.

Future-dated requirements a small merchant is most likely to meet:

Requirement	What it asks	Who sees it
8.3.6	Passwords at least 12 characters (8 only where a system cannot support 12), with letters and numbers	Anyone with logins to in-scope systems
8.4.2	Multi-factor authentication for all access into the cardholder data environment, not just administrators	Merchants whose own systems handle card data
5.4.1	Automated mechanisms that detect and protect staff against phishing	Merchants on the longer SAQs
12.6.3.1	Security awareness training that covers phishing and social engineering	Merchants on the longer SAQs
12.5.2	Confirm your PCI scope at least once every 12 months	Merchants on the longer SAQs
6.4.3 and 11.6.1	Inventory and authorize the scripts on payment pages, and detect unauthorized changes to those pages	E-commerce merchants whose site hosts or affects the payment page
11.3.2	External vulnerability scans every three months by an Approved Scanning Vendor (ASV)	Now includes many e-commerce merchants on SAQ A

The full text is in the PCI SSC document library.

Which SAQ Applies to You?

Each SAQ has eligibility criteria printed at the front of the form. You must meet every criterion to use it. If none fits, you use SAQ D, the longest. Your acquirer has the final say.

SAQ	Payment setup it fits	Relative effort
A	Card-not-present only (e-commerce or mail and telephone orders), with all card data functions fully outsourced to PCI DSS compliant providers. Your site redirects to, or embeds, the provider’s payment page. No electronic storage, processing, or transmission of card data on your systems.	Lowest
A-EP	E-commerce only. Payment is outsourced, but your website controls how customers or their card data reach the provider, so your site can affect payment security.	High
B	Imprint machines or standalone dial-out terminals only. No electronic card data storage.	Low
B-IP	Standalone, PCI-approved payment terminals connected by IP (your internet connection) straight to the processor. No electronic card data storage.	Low to moderate
C-VT	You type one transaction at a time into a processor-hosted virtual terminal, from an isolated computer.	Moderate
C	A point-of-sale system or payment application connected to the internet. No electronic card data storage.	Moderate to high
P2PE	Only hardware terminals that are part of a PCI-listed point-to-point encryption (P2PE) solution.	Low
SPoC	A phone or tablet with a secure card reader in a validated software-based PIN entry solution.	Low
D	Everything else, including any business that stores card data electronically.	Highest

A Change for Online Stores on SAQ A

In January 2025 the Council removed Requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A and added an eligibility criterion instead: the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce system. The revised SAQ A took effect on March 31, 2025.

A follow-up FAQ explains that the criterion applies to merchants that embed a provider’s payment form in their own page, for example in an iframe. It does not apply to merchants that redirect customers to the provider’s site. A merchant can meet it by using protections like those in 6.4.3 and 11.6.1, or by obtaining written confirmation from its PCI DSS compliant provider that the embedded solution, installed according to the provider’s instructions, includes protection against script attacks. Ask your provider for that confirmation and keep it with your SAQ.

How Can You Shrink Your PCI Scope?

Scope means the people, processes, and systems that store, process, or transmit card data, plus anything connected to them. Every system you remove from scope is one you no longer answer for on the SAQ.

1. Do not store card numbers. Not in a spreadsheet, a notes field, a scanned authorization form, an email, or a voicemail. Use your processor’s tokenized “card on file” feature, which keeps the number on the processor’s systems.
2. Use a validated P2PE terminal for in-person payments. The card data is encrypted inside the terminal and your network never sees it in readable form. Confirm the solution appears on the PCI SSC’s list before assuming you qualify for SAQ P2PE.
3. Use a hosted payment page or redirect for online payments, so your website never receives card data.
4. Stop taking card numbers by email or text. Send a payment link instead.
5. Put payment devices on their own network segment, separate from office computers, guest Wi-Fi, cameras, and smart devices. Our guide to network segmentation explains how this works with a business-grade firewall.

IT Controls Checklist

PCI DSS has twelve requirement families. Here is what each one means for a small merchant. Shorter SAQs include only some of them.

1. Network security controls. A business firewall between the internet and your payment devices, with payment traffic segmented from everything else. See choosing a network firewall.
2. Secure configurations. Change every vendor default password on routers, access points, terminals, and point-of-sale software. Turn off services you do not use.
3. Protect stored account data. The best answer is to store none. Never keep the three or four digit security code or full magnetic stripe data after authorization under any circumstances.
4. Encrypt transmission. Card data crossing public networks must use strong cryptography. Never send card numbers through email, chat, or text.
5. Malware protection. Managed endpoint protection on in-scope computers, plus phishing defenses on email.
6. Secure systems and software. Apply security patches promptly and run only supported operating systems. Windows 10 reached end of support on October 14, 2025, so a point-of-sale computer still running it needs an upgrade or paid extended security updates. E-commerce merchants also need control over the scripts on payment pages.
7. Restrict access by business need. Only staff who need the payment dashboard or point-of-sale administration get it.
8. Identify and authenticate users. Individual logins, no shared accounts, passwords of 12 or more characters, and multi-factor authentication. Turn on MFA for your processor’s web dashboard even if your SAQ does not ask, because a stolen dashboard login can redirect your deposits.
9. Physical security. Keep a list of payment terminals with serial numbers, inspect them periodically for tampering or substitution, and train staff to question unexpected “technicians”. Shred paper containing card numbers.
10. Log and monitor. Keep logs for in-scope systems and review them. On the short SAQs the processor covers most of this.
11. Test security. Quarterly external scans by an Approved Scanning Vendor when your SAQ requires them, and internal scans on the longer SAQs. Our vulnerability scanning guide explains the difference.
12. Policies and programs. A short written security policy, staff training at hire and annually, a list of your payment service providers with proof of their PCI DSS compliance, and an incident response plan that includes your acquirer’s contact details.

What Happens If You Do Not Comply?

Because PCI DSS is contractual, the consequences come from your merchant agreement and the card brand rules behind it. Depending on the agreement, a processor may charge a non-compliance fee when no current SAQ is on file. After a breach involving card data, a merchant can face a mandated forensic investigation, assessments passed down from the card brands, and in serious cases the loss of the ability to accept cards. The amounts and terms differ by processor and are written in your agreement, so read that section or ask your processor to point you to it.

Insurance is a related question. Policies differ on whether card brand assessments are covered, so ask your broker directly. Our overview of cybersecurity insurance lists questions to bring.

When Is This Mostly Handled for You?

Picture a shop that takes cards only through a processor-supplied terminal from a PCI-listed P2PE solution, or only through a redirect to a hosted checkout, and never writes card numbers down. Its annual work is modest: confirm the setup still matches the SAQ criteria, complete the short SAQ, keep terminals physically secure, train staff, and keep a list of providers. It does not need a security consultant for that. The work grows when card data touches your own computers, your own website, or your own network.

Common Mistakes

• Choosing an SAQ by length instead of by its eligibility criteria. Attesting to criteria you do not meet is a false attestation.
• Answering yes to controls that are not in place. The SAQ is a signed statement.
• Payment terminals on the same flat network as office computers and guest Wi-Fi.
• Card numbers kept “temporarily” on paper forms, in email, or in a customer notes field.
• Assuming the web developer or processor covers the website. For embedded payment forms, the merchant must confirm script protections or get the provider’s written confirmation.
• Letting the annual date pass because nobody owns the task.

Common Questions

Is PCI DSS a law?

No. It is an industry standard created by the card brands and maintained by the PCI Security Standards Council. It binds you through your merchant agreement with your acquirer or processor. Separate laws, such as California’s data security and breach notification statutes, can also apply to the same card data.

We use Square or Stripe. Are we automatically compliant?

Not automatically. A validated processor greatly reduces your scope because it handles the card data. You are still responsible for your side: devices, network, website, staff practices, and completing whatever validation your processor or acquirer requires. Some processors build a simplified process into their dashboard, so check there first.

Which SAQ do most small businesses use?

It depends on how payments are taken. Fully outsourced online checkout points to SAQ A. Standalone terminals point to B or B-IP. A listed P2PE solution points to SAQ P2PE. A hosted virtual terminal points to C-VT. An internet-connected point-of-sale system points to C. Anything that stores card data electronically points to D.

Do we need quarterly vulnerability scans?

Only if your SAQ includes Requirement 11.3.2. SAQs for internet-facing setups generally do, and since March 31, 2025 that includes many e-commerce merchants on SAQ A. Scans must be run by a PCI SSC Approved Scanning Vendor and show a passing result. Merchants using only standalone dial-out or P2PE terminals typically do not have this requirement.

What changed on March 31, 2025?

The 51 future-dated requirements introduced in PCI DSS v4.0 became mandatory. For small merchants the visible changes are 12-character passwords, wider multi-factor authentication, anti-phishing protections and training, annual scope confirmation, payment page script controls for e-commerce sites, and the revised SAQ A eligibility criteria.

How Coastal Growth Co. Can Help

We handle the network and device side of PCI DSS: separating payment devices onto their own network segment, replacing default passwords, enforcing MFA and password length, patching or replacing out-of-support point-of-sale computers, and arranging ASV scans. We can also walk through your SAQ’s technical questions with you so the answers reflect your real setup. Your acquirer decides what you must submit. See networks and security or IT for retail businesses, and contact us to describe your payment setup.