Checklist · PCI DSS v4.0.1
PCI Compliance Checklist for Small Business
The tasks that actually apply to a small merchant, in the order you should do them — plus the evidence to keep, and the parts you can safely skip.
Work top to bottom. Step 1 decides everything else — if you get your scope wrong, the rest of this checklist is wasted effort. Do not skip it.
Not sure which questionnaire applies to you? Start with which SAQ is yours, then come back here.
This is a practical working checklist for small merchants, not a substitute for the official SAQ or for advice from your acquirer or a QSA. Requirement lists differ by SAQ type and change over time — always confirm against the current SAQ document for your business.
Confirm which SAQ you file
Your SAQ is decided by how card data reaches you. This single decision determines how much work the rest of this list represents.
- Confirm your checkout type. Hosted checkout or redirect, embedded or iframe fields on your own site, or card data reaching your own server.
- Confirm your merchant level. Driven by annual transaction volume. Most small businesses are Level 4.
- Write down which SAQ you believe applies and why, in one sentence.
- Confirm it with your acquirer if anything is ambiguous. Do not guess on this one.
- If you are on a custom checkout, price a move to hosted now — before you price the compliance work.
The core tasks — everyone do these
These apply to essentially every card-accepting small business, regardless of SAQ. Most take minutes; a couple need a developer.
- Map where card data lives. Every system that stores, processes or transmits it is in scope. Aim for "nowhere we do not need it".
- Never store CVV, and never store full card numbers unless you have to. There is almost never a good reason for a small merchant to hold card data.
- Keep everything patched. CMS core, plugins, server OS, libraries. This is the number one real-world risk.
- Turn on automatic updates where you can, and subscribe to security notices for your platform.
- Use TLS 1.2 or later for every page that handles card data, and force HTTPS site-wide.
- Give every person their own login. No shared admin accounts. Then remove access the day someone leaves.
- Turn on multi-factor authentication for admin and remote access to anything in scope.
- Change default passwords on routers, terminals, and admin panels.
- Run anti-malware protection on systems that touch card data.
- Keep a written information security policy. Even a short one. Many SAQs ask for it.
- Train anyone who handles cards, at least annually, and keep a record.
- Physically protect terminals. Serial numbers recorded, tamper checks, staff trained to spot skimmers.
Then, only what your SAQ adds
- SAQ A — keep the eligibility true. Your payment page must remain fully hosted and you must not add scripts that can affect it. If that stops being true, your SAQ type changes.
- SAQ A-EP — you own your page’s security. Inventory every script on the payment page, justify each one, and monitor for changes.
- SAQ D — the full programme. Hundreds of controls. Genuinely reconsider the architecture before committing to this.
The evidence to keep
If you are ever asked to demonstrate compliance — by your acquirer, or after an incident — these are the documents that matter. Keep them together.
- Your completed SAQ for the current year.
- Your information security policy, dated and signed off.
- A network or data-flow diagram showing where card data goes. A whiteboard photo is better than nothing.
- A list of in-scope systems and who has access to each.
- Records of patching and of any security incidents.
- Staff training records.
- ASV scan reports, if they apply to you.
- Your processors’ compliance documentation. Your providers should be able to give you their current AOC.
The recurring calendar
| When | Task |
|---|---|
| Once | Confirm scope, file your first SAQ, write the policy |
| Quarterly | ASV scans — only if your SAQ requires them; review admin access |
| Annually | Re-file the SAQ, re-train staff, review policies and access lists |
| Continuously | Patch, monitor, and remove access for leavers |
| On change | Any checkout, payment-page or provider change re-opens scope. Re-check it. |
The cost worksheet
Fill this in before you accept any quote. Typical 2026 figures — see the full cost breakdown for sources.
| Line item | Typical range | Applies to me? |
|---|---|---|
| SAQ self-assessment | $0 | Yes |
| ASV scans (per IP, per year) | ~$80–$800 | SAQ A-EP / D, most Level 3+ |
| Penetration test | ~$5,000–$30,000 | SAQ D, Level 1 |
| QSA assessment | ~$5,000–$50,000+ | Level 1 |
| Compliance software | ~$5,000–$50,000 / year | Rarely needed at small scale |
| Processor PCI fee | ~$79–$120 / year | Most merchants |
| Processor non-compliance fee | ~$20–$100 / month | Only while the SAQ is unfiled |
The mistakes that cost people the most
- Guessing your SAQ. Getting this wrong means doing work that does not apply — or missing work that does.
- Buying tools before fixing scope. A $5,000 platform does not fix a custom checkout that should have been hosted.
- Treating the annual fee as compliance. Paying it does not file your SAQ, and the monthly penalty stays until you do.
- Forgetting the payment page. Anything that loads on it — analytics, chat widgets, A/B testing tools — can pull you out of SAQ A eligibility.
- Letting stale plugins sit. In practice, this is what actually gets small merchants breached.
Take the printable version
The same checklist as a printable page, plus the cost worksheet as a spreadsheet you can fill in.
No spam. Unsubscribe anytime.No spam. Unsubscribe anytime.FAQ
How long does PCI compliance take for a small business?
On a hosted checkout (SAQ A), most owners finish in a few hours spread over a week — mostly reading, then answering the questionnaire. On a custom checkout, plan for weeks, because remediation moves into your engineering backlog.
Do I have to redo this every year?
The SAQ is annual. A few tasks are quarterly (ASV scans, if they apply to you). Everything else is ongoing — keeping systems patched and access reviewed is the part that actually keeps you compliant.
What if my processor says I am already compliant?
Some processors mark merchants as compliant on their side. That does not remove your own obligation to attest, and it does not cover systems you control. Read what they actually do and do not cover.
Can I just buy a compliance tool and be done?
No. Tools collect evidence and track tasks; they do not patch your CMS or remove card data from your servers. For a small merchant on a hosted checkout, the tool is usually unnecessary overhead.
Do I need an ASV scan?
It depends on your SAQ. SAQ A generally does not require ASV scans. SAQ A-EP, and most Level 3 merchants, do. Check the current SAQ document for your type before buying scans.
Reviewed October 2026. This is general information, not legal or compliance advice. Confirm requirements against the current PCI DSS SAQ document for your business. Corrections welcome.