PCI DSS for small merchants and start-ups: the SAQ route done properly

Why the SAQ route is not a tick-box exercise

For most small merchants and start-ups, PCI DSS validation means completing a self-assessment questionnaire (SAQ) and signing the attestation of compliance (AOC) that goes with it, rather than hosting a Qualified Security Assessor (QSA) for a full Report on Compliance. It is simpler, but it does not lower the standard. Each question maps to a PCI DSS requirement, and the AOC your owner or director signs tells the acquirer that the controls exist and operate.

After a breach, investigators compare what was declared with what was actually in place. A questionnaire answered "yes" throughout, with nothing to show for it, is the classic failure. The aim is therefore specific: keep the environment small enough that the right SAQ is short, then make sure every answer can be shown to someone else. Which questionnaire you qualify for is its own subject, covered in Which SAQ applies to you: eligibility explained.

Choose payment channels that keep your scope small

The decision that matters most is where card numbers travel. Every system you control that receives a full card number, and whatever connects to it, falls into scope. Three choices keep that number close to none.

Online: a hosted payment page or a full redirect

When the customer enters card details on a page served by a PCI DSS compliant payment service provider, your web server never receives them. Your site still decides where customers are sent, which is why checkout page scripts matter. A checkout where your own code collects the card number usually means a longer questionnaire.

In person: validated point-to-point encryption terminals

A terminal belonging to a P2PE solution validated and listed by the PCI Security Standards Council encrypts card data at the tap or insert, and only the solution provider can decrypt it. Your till, Wi-Fi and back-office laptop then never see readable card data. The terminal itself still needs an inventory and regular tamper inspections.

Stored cards: tokenisation

For subscriptions and repeat customers, let the provider store the card and return a token that is useless outside its platform.

Segmentation for larger environments is covered in PCI DSS scoping and segmentation: shrinking the CDE.

The obligations that remain after you outsource

A smaller scope is not a zero scope. Four areas stay with the merchant, and they are where small businesses most often have nothing to show.

Scripts on e-commerce pages

Attackers inject code into checkout pages to skim card details or redirect customers. Since the PCI Security Standards Council's January 2025 update, merchants using SAQ A must confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce systems. In practice: know what third-party code runs on checkout-related pages, remove what you do not need, protect the shop's admin login with strong authentication and keep the platform and plug-ins patched.

Vendor due diligence

Requirement 12 expects you to manage the service providers that handle card data for you or could affect its security. Keep a short register covering the payment service provider, the terminal provider, the e-commerce platform and your web developer: each one's current AOC, who is responsible for what, and a date to check again.

Staff awareness

People who take payments need a handful of rules: never write down or repeat card numbers, never accept them by e-mail or chat, check terminals for tampering and report anything odd. A short session at induction and once a year, with an attendance record, is proportionate.

Incident response

One page is enough if it is real: who decides, how to reach the acquirer and provider, what not to switch off, where evidence is kept. Walk through it once a year.

ASV scans and the acquirer's role

Some SAQs require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) listed by the PCI Security Standards Council. The questionnaire itself states whether yours does; do not assume. Acquirers usually expect passing results, so allow time to fix what the first scan finds and rescan.

The acquirer, the bank or payment provider that processes your card transactions, assigns your merchant level under the card brands' criteria, tells you whether an SAQ is acceptable and which one it expects, sets the date for the AOC and scan reports, and may apply the conditions in your merchant agreement if you do not comply. Many small merchants deal with a payment service provider that acts for the acquirer, and its portal is often where the SAQ is completed. Who needs PCI DSS at all, and at which level, is answered in Do you need PCI DSS? Merchant levels, service providers and who decides.

Worked example: a small online shop with a café terminal

An eight-person business sells coffee beans online and runs a café at its roastery. At the start, its checkout plug-in collected card details on the shop's own page, the café terminal was a standard device on the café Wi-Fi, and phone orders were written on a pad and keyed in later. Card data touched its own systems or paper in all three channels.

Three decisions changed that. The checkout moved to the provider's hosted payment page, and the analytics and chat widgets came off the pages leading to it. The café terminal was replaced with one from a validated P2PE solution. Phone customers now receive a payment link, and the order pad lost its card number field. The business then confirmed with its acquirer which questionnaires applied and completed them.

The evidence it keeps is short: a data-flow sketch per channel, a provider register with three AOCs, the checkout script list with its review date, the terminal inventory and monthly inspection sheet, the awareness attendance list, the incident plan with its walk-through note, scan reports where required, and the signed AOC. One person coordinates, the owner signs and the café manager runs the terminal checks.

Mistakes small merchants make, and how to avoid them

• Ticking "yes" without evidence. If you cannot point to the record, the answer is not yet "yes". Fix the control, or say so and agree a plan with the acquirer.
• Choosing the wrong SAQ. Eligibility depends on how each channel actually works, not on how it was sold. A wrong choice undermines the AOC.
• No AOC from providers. "Our provider is compliant" is a claim; its current AOC for the service you use is the evidence. See How to verify a PCI DSS AOC and check a provider's compliance.
• Forgotten side channels. Card numbers in e-mails, chat logs or notebooks bring those systems into scope.
• Buying a "PCI certificate". There is none. What counts is the SAQ and its AOC, accepted by your acquirer.

PCI DSS for small merchants: questions buyers ask