PCI DSS 4.0.1 · Merchant guide

PCI DSS for small shops: the honest checklist

PCI DSS 4.0.1 compliance for a small online shop means three concrete things: filling out the right Self-Assessment Questionnaire for your SAQ type, keeping evidence on file for every control you claim, and re-validating on the schedule your acquirer sets — usually once a year. Hosting can carry the infrastructure half of that list — TLS, patching, logging, segmentation — but it cannot complete your SAQ, because the other half lives in your code, your staff, and your payment page. This is the honest version of what real compliance requires, split by who actually does the work.

What "PCI compliant" really means for a small shop

PCI DSS is a contractual security standard set by the payment card networks, not a government law. You agreed to follow it the moment you signed your merchant or acquiring agreement to accept cards. Nobody hands you a single, universal "PCI compliant" badge for your business — each merchant completes their own Self-Assessment Questionnaire (or a full assessment, for SAQ D) and files it with their acquirer, and that filing is specific to how your business actually takes payments today.

A hosting provider, a payment processor, or a plugin vendor can each be validated as compliant for the piece of infrastructure they control. None of that status transfers to you automatically. If a vendor tells you their product alone "makes you PCI compliant," that claim doesn't hold up — which is exactly why the rest of this checklist is organised by who does what.

What each SAQ actually requires you to do

If you're SAQ A

• Confirm your payment processor is PCI DSS validated (ask for their Attestation of Compliance).
• Make sure nothing on your site can rewrite, intercept, or otherwise influence the redirect or iframe URL.
• Complete your own SAQ A and resubmit it to your acquirer annually.
• Ask your acquirer whether an ASV scan applies to you — many pure-redirect merchants are exempt, but not all.
• Keep a written, current list of who has admin access to your website and hosting account.

If you're SAQ A-EP

• Inventory every script that loads on your payment page, including third-party tags.
• Apply change- and tamper-detection to that page — PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 make this mandatory.
• Patch your CMS, plugins, and theme on a strict, documented schedule.
• Segment your web application from any other systems you run.
• Commission quarterly ASV scans.
• Work through the roughly 139-question SAQ A-EP with your acquirer or a QSA — it's long enough that this pays off.

If you're SAQ D

• Treat this as an ongoing program, not a form — it covers all 12 PCI DSS requirements.
• Encrypt card data at rest and document your key-management process.
• Commission quarterly ASV scans and an annual penetration test.
• Test your network segmentation; don't just assume it holds.
• Work with a QSA, or use an internal assessor if you have genuine in-house expertise.
• Consider whether you can stop storing card data and move to a validated processor instead — it's usually the fastest way out of SAQ D.

Not sure which of the three is yours? Which SAQ do I need? walks through the decision in three questions.

What evidence you actually need to keep

• Your signed Attestation of Compliance (AOC), renewed on your acquirer's schedule — usually annually.
• ASV scan reports or attestation letters, for every quarter they were required.
• Patch and change logs for your CMS, plugins, and theme.
• A current, reviewed access-control list of who holds admin rights to your site and hosting account.
• Retained system and access logs — PCI DSS expects roughly a year of history, with the most recent period readily available.
• A copy of your payment processor's own compliance attestation, since your SAQ A eligibility depends on it.
• Records of any security-awareness training for staff who touch the checkout or admin panel.
• Documented results if you ever test your incident-response plan.

None of this needs to be elaborate. A dated folder with these eight items, updated whenever something changes, is what most small merchants are actually asked to produce — not a binder written for an enterprise audit.

What actually happens if you ignore it

PCI DSS compliance is a contractual obligation you accepted when you signed your merchant or acquiring agreement, not a government law, so nothing about ignoring it "activates" automatically the way a legal fine would. In practice, the risk shows up in three places.

First, your acquirer or payment processor can raise your transaction fees, restrict your account, or terminate it outright when non-compliance surfaces during a review. Second, if a breach happens while you're non-compliant, you typically carry the fraud losses and forensic investigation costs yourself, instead of sharing them with your processor. Third, a confirmed breach involving EU customers' payment data usually triggers separate GDPR breach-notification duties on top of whatever your card-brand agreement already requires.

None of that needs a "PCI police" to show up at your door. The exposure sits quietly inside contracts you've already signed, until the day something goes wrong — which is the whole argument for doing the small, dated-folder version of compliance now, rather than the enterprise-audit version later, under pressure.

Frequently asked

Guidance, not a QSA opinion. Your acquirer has the final word — still unsure? Talk to us.