PCI-DSS applies to any business that accepts, processes, stores or transmits payment card data. There is no small business exemption — a sole trader taking one card payment a month is in scope.
What varies enormously is how much of the standard applies to you, and that depends almost entirely on how you take payments. Getting that architecture right is worth more than any amount of effort spent on the questionnaire afterwards.
It is a contractual obligation, not a law
PCI-DSS is a standard maintained by the card brands, and you agree to it in your merchant services contract. It is not government regulation, which has two practical consequences.
Enforcement comes from your acquiring bank rather than a regulator, typically through monthly non-compliance fees, and escalating to increased transaction rates or termination of your ability to accept cards.
The larger exposure appears after a breach. A compromised merchant found non-compliant can face card brand fines, the cost of forensic investigation by an approved investigator, card reissuance costs, and liability for fraudulent transactions. These have ended small businesses.
Merchant levels
Your level determines how you validate compliance, based on annual transaction volume. Each card brand sets its own thresholds; these are Visa's:
- Level 4 — fewer than 20,000 e-commerce transactions annually, or up to 1 million total. This covers the great majority of small businesses.
- Level 3 — 20,000 to 1 million e-commerce transactions.
- Level 2 — 1 to 6 million transactions.
- Level 1 — over 6 million transactions. A merchant that has suffered a breach may also be escalated to a higher level. Requires an annual on-site audit by a Qualified Security Assessor.
Most small merchants are Level 4 and validate by self-assessment rather than external audit. Note the exception: after a breach you may be escalated to a higher validation level regardless of volume, which is one more reason the architecture matters.
| Level | Annual transactions (Visa) | How you validate |
|---|---|---|
| Level 1 | Over 6 million | Annual Report on Compliance by a QSA, quarterly ASV scans, attestation |
| Level 2 | 1 to 6 million | Annual SAQ, quarterly ASV scans, attestation |
| Level 3 | 20,000 to 1 million e-commerce | Annual SAQ, quarterly ASV scans, attestation |
| Level 4 | Under 20,000 e-commerce, or up to 1 million total | SAQ; requirements set by your acquiring bank |
Reducing scope is the whole game
The single most valuable decision a small merchant makes is minimising how much card data touches their own systems. Every system that stores, processes or transmits cardholder data falls within scope, and everything in scope must meet the standard.
The self-assessment questionnaire you complete follows directly from this:
- SAQ A — the smallest. E-commerce merchants who fully outsource payment handling to a compliant third party, with no card data touching their systems at all. Far shorter than any other questionnaire.
- SAQ A-EP — e-commerce where your site affects how payment is taken but does not receive card data directly.
- SAQ B — imprint machines or standalone dial-out terminals, no electronic storage.
- SAQ B-IP — standalone IP-connected terminals.
- SAQ C-VT — web-based virtual terminal, manual entry, one transaction at a time.
- SAQ C — payment application connected to the internet, no card data storage.
- SAQ D — everything else, including any merchant storing card data. Several hundred questions.
The difference between SAQ A and SAQ D is a short questionnaire against several hundred questions. Choosing a payment architecture that qualifies for SAQ A is the most consequential compliance decision a small merchant can make, and it is far easier to choose at the start than to retrofit.
In practice that means using a hosted payment page or an iframe from your payment provider rather than accepting card details on your own page, and using point-to-point encrypted terminals in person.
| SAQ | Who it is for |
|---|---|
| SAQ A | E-commerce fully outsourced to a compliant provider; no card data touches your systems |
| SAQ A-EP | E-commerce where your site affects how payment is taken but does not receive card data |
| SAQ B | Imprint machines or standalone dial-out terminals, no electronic storage |
| SAQ B-IP | Standalone IP-connected terminals |
| SAQ C-VT | Web-based virtual terminal, manual entry, one transaction at a time |
| SAQ C | Payment application connected to the internet, no card data storage |
| SAQ D | Everything else, including any merchant storing card data |
The rule that saves the most trouble
Do not store cardholder data. Almost no small business genuinely needs to.
Specifically, sensitive authentication data — the full magnetic stripe, the CVV, the PIN — must never be stored after authorisation, under any circumstances. This is absolute.
Where card numbers must be retained for recurring billing, use tokenisation through your payment provider so you hold a token rather than a number. The token is useless if stolen and removes the storage requirement entirely.
Also worth auditing: card data arriving where nobody intended it. Customers email card numbers. Staff write them on notepads during phone orders. Call recordings capture them. Each of these pulls systems into scope that were never designed for it, and this is one of the most common findings in small merchant assessments.
What compliance involves in practice
For a typical Level 4 merchant on SAQ A, the annual cycle is:
- Complete the self-assessment questionnaire honestly
- Run an external vulnerability scan by an Approved Scanning Vendor, quarterly, if your SAQ requires it
- Complete an attestation of compliance
- Submit both to your acquiring bank
Alongside that, the underlying requirements still apply throughout the year: unique credentials for anyone with access, MFA for administrative and remote access, patching, restricted physical access to terminals, staff training, and an incident response plan.
One frequently missed control is terminal inspection. Physical tampering with card readers is a real attack, and the standard expects periodic documented checks that devices have not been substituted or modified.
The current version
PCI-DSS v4.0 (now v4.0.1) replaced v3.2.1, with the remaining future-dated requirements becoming mandatory in March 2025. The changes most likely to affect a small merchant are expanded MFA expectations, stronger password requirements, and additional controls around e-commerce scripts on payment pages.
If your payment architecture keeps you on SAQ A, most of this lands on your payment provider rather than on you — which is the recurring theme of small merchant compliance. The effort belongs in choosing the architecture, not in managing the questionnaire.
