Which questionnaire you fill in is decided by how card data reaches you. Changing that is cheaper than complying with the long version.
If you take card payments, PCI DSS applies to you, and it applies regardless of size. What changes with size and with how you take payments is which self-assessment questionnaire you complete, and the difference between the shortest and the longest is roughly twenty questions against more than three hundred.
That gap is the single most valuable thing to understand, because it is largely under your control.
Scope is a choice
The standard applies to the people, processes and systems that store, process or transmit cardholder data, plus anything connected to them. Everything in that boundary has to meet the requirements and be evidenced.
So the most effective compliance strategy is not to comply harder. It is to shrink what is in scope until the remaining requirements are small.
The first step surprises people. Ask around, and you will find card numbers in places nobody mentioned: written on a pad at reception during a phone order, emailed by a customer who was not asked to, sitting in a spreadsheet somebody built to track refunds, captured on the call recording system.
Each of those pulls a system into scope. The email server, the recording platform, the file share. Finding them is the work; removing them is usually easy and immediately reduces both your obligation and your risk.
Which questionnaire
The one that catches people out is SAQ A-EP, and it catches them because the distinction is subtle.
If your checkout redirects the customer to the payment provider's own hosted page, so that your site plays no part in delivering the page that captures the number, you are generally in SAQ A territory. If your site serves a page that embeds the payment form, or loads the provider's JavaScript into a page you control, you are influencing how that form is delivered, and you are generally in A-EP. The questionnaire is several times longer and brings requirements about your web infrastructure with it.
This matters because the embedded option usually looks better to customers, and the decision gets made on user experience by somebody who has no idea it changes the compliance regime. Ask the question before the integration is built, not after.
Your acquirer determines your reporting obligations. Confirm your SAQ type with them rather than deducing it, because they are the ones who will accept or reject it.
What actually gets you compliant
For most small businesses who have reduced scope properly, the requirement set comes down to a manageable list.
Do not store card numbers. The simplest and most effective control. If you genuinely need to take repeat payments, use your provider's tokenisation so that you store a token, which is worthless if stolen, rather than a number.
Use a current, supported payment application or terminal. Point-to-point encrypted terminals keep the data out of your systems entirely, which is why they are worth the slightly higher cost.
Change the defaults. Default passwords on routers, terminals and network equipment remain a named requirement because they remain a real problem.
Segment. If anything still handles card data, it goes on its own network segment, separated from the general office network. This is the single control that keeps the rest of your business out of scope.
Restrict and log access. Unique logins for anyone who can reach cardholder data, with access logged.
Scan if you need to. Externally facing systems in scope require quarterly scans by an approved scanning vendor. If your scope reduction worked, you may not need these at all, which is a direct saving.
Train the people. Annual, and specifically about handling card data: what to do when a customer reads a number over the phone, why it does not get written down, what happens to the note if it is.
The phone problem
Taking card details over the phone is where small businesses most often undo their scope reduction.
If somebody reads a number aloud and a staff member types it into a terminal, the phone call, the call recording system and the person are all in scope. If the number is written on a pad first, the pad is in scope and it is also sitting on a desk.
Three fixes, cheapest first. Use pause-and-resume on call recording so the card segment is never recorded. Send a payment link by text or email so the customer pays themselves. Or use a provider feature that lets the customer key the number into their phone, with the digits never audible to the agent.
The second one is free with most providers and removes the problem completely.
The annual cycle
Compliance is annual, and the shape of the year is short.
Confirm your SAQ type with your acquirer, in case your payment arrangements changed. Walk the card data flows again, because they drift. Complete the questionnaire honestly, run the scans if they apply, and sign the attestation.
Then do the one thing that makes next year easier: write down, as you go, where every answer came from. Next year's exercise becomes a review rather than an investigation.
The uncomfortable fact about breaches
If card data is compromised and you were not compliant, the fines and the forensic investigation costs are generally passed to you by your acquirer, and they can be substantial relative to a small business's turnover.
That is the actual reason this matters, rather than the paperwork. And it is another argument for scope reduction: data you never hold cannot be taken from you.
