PCI DSS compliance checklist for small online stores (v4.0.1)
If your shop takes card payments, PCI DSS applies to you — even if a payment provider handles the card details. Here is what the standard asks of a small online store, which questionnaire you are likely to fill in, what changed in 2025, and a checklist you can work through this month.
PCI compliance means meeting the Payment Card Industry Data Security Standard (PCI DSS), currently version 4.0.1, which applies to every business that accepts, stores, processes or transmits payment card data. Small online stores usually prove it once a year with a Self-Assessment Questionnaire and Attestation of Compliance sent to their acquirer, plus quarterly external vulnerability scans where required.
This is general guidance, not a Qualified Security Assessor (QSA) assessment. Which requirements apply to you depends on how your checkout is built and on your merchant agreement — confirm your level, questionnaire and deadlines with your acquirer.
What is PCI compliance and who enforces it?
PCI DSS is a set of security requirements for protecting payment card data: the card number (PAN), cardholder name, expiry date and, above all, the sensitive authentication data such as the CVV and PIN. It applies to any entity that stores, processes or transmits that data, or that can affect its security. For an online store, the website that sends a customer to the payment page is in scope even if the card number never touches your server.
Three parties are involved, and it helps to keep them apart:
- PCI Security Standards Council (PCI SSC) — founded by the major card brands, it writes and maintains the standard, the Self-Assessment Questionnaires (SAQs) and the assessor programmes. It does not enforce anything or issue fines.
- Card brands (Visa, Mastercard, American Express, Discover, JCB) — each runs its own compliance programme, defines merchant levels and sets penalties for the acquirers it works with.
- Your acquirer (merchant bank or payment provider acting as one) — the party that actually asks you for evidence, decides which form you submit and when, and passes on any fees or penalties under your merchant agreement.
Current version: PCI DSS v4.0.1
The PCI SSC published PCI DSS v4.0 in March 2022 and a limited revision, v4.0.1, in June 2024. v4.0.1 corrected and clarified wording but added no new requirements. Version 3.2.1 was retired on 31 March 2024 and v4.0 was retired at the end of 2024, so v4.0.1 is the only active version.
v4.0 introduced 64 new requirements. Most of them — 51 — were “future-dated”: best practice until 31 March 2025, mandatory from that date. Any assessment you complete now is against the full set, including the new e-commerce controls on payment page scripts (6.4.3 and 11.6.1), targeted risk analyses and stronger authentication rules.
PCI compliance levels 1–4
Card brands sort merchants into levels by annual transaction volume. The level decides how you validate compliance, not which security requirements apply — the standard is the same for everyone. The thresholds below are Visa’s; Mastercard uses broadly similar ones, and other brands differ. Your acquirer assigns your level.
| Level | Visa transactions per year | Typical validation |
|---|---|---|
| Level 1 | Over 6 million across all channels, or any merchant the brand designates (for example after a breach) | Annual Report on Compliance (ROC) by a QSA or qualified internal assessor, plus quarterly ASV scans |
| Level 2 | 1 to 6 million across all channels | Annual SAQ (some acquirers and brands ask for more), plus scans where the SAQ requires them |
| Level 3 | 20,000 to 1 million ecommerce transactions | Annual SAQ and AOC, plus scans where required |
| Level 4 | Fewer than 20,000 ecommerce transactions, or up to 1 million in total | Annual SAQ and AOC as required by the acquirer, plus scans where required |
Most small online stores are Level 4, and many are Level 3. A merchant that suffers a card data compromise can be moved up to Level 1 regardless of volume — one more reason not to treat Level 4 as “PCI-lite”.
Which SAQ applies to an online store?
A Self-Assessment Questionnaire is a cut-down version of the standard for one way of taking payments. Picking the right one is the biggest decision in your PCI work. For ecommerce there are three main options:
| SAQ | When it applies | Typical checkout | Effort |
|---|---|---|---|
| SAQ A | All card data functions fully outsourced to PCI DSS compliant providers; you do not store, process or transmit card data on your systems | Full redirect to a hosted payment page, or a payment form served entirely by the provider in an iframe | Lowest |
| SAQ A-EP | Card data is passed to the provider, but your website controls how the payment page or form is delivered and could affect the transaction | Your page hosts the form fields and posts card data straight to the provider (“direct post”) or uses provider JavaScript on your own page | Medium |
| SAQ D | Anything else, including storing card data or card numbers passing through your server | Self-built or self-hosted gateway integration | Highest |
The 2025 change to SAQ A
When the future-dated requirements arrived, SAQ A briefly included the script controls 6.4.3 and 11.6.1. In January 2025 the PCI SSC published a revised SAQ A. It removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added a new eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
A PCI SSC FAQ published in February 2025 (FAQ 1588) explains how to meet that criterion: either by using techniques such as those in 6.4.3 and 11.6.1, or by getting confirmation from your PCI DSS compliant payment provider that its embedded payment form includes protection against script attacks when implemented as instructed. The criterion matters most where your page embeds the provider’s form in an iframe. The protection still has to exist; only the paperwork moved. If you cannot support the claim, you are not eligible for SAQ A.
The 12 PCI DSS requirements in plain English
PCI DSS is organised into six goals and twelve principal requirements. On SAQ A you will answer only a handful of sub-requirements from a few of them; on SAQ D you answer almost all. This table shows what each one means for a small online store.
| # | Requirement | What this means for a small online store |
|---|---|---|
| 1 | Install and maintain network security controls | Firewalls or cloud security groups around anything in scope; only the ports you need open. With hosted checkout this is mostly your provider’s job. |
| 2 | Apply secure configurations to all system components | No default passwords on your store admin, hosting panel or database; remove unused plugins, accounts and services. |
| 3 | Protect stored account data | Do not store card numbers at all. Never store CVV codes, even encrypted. Check that no card data sits in emails, support tickets or spreadsheets. |
| 4 | Protect cardholder data with strong cryptography during transmission | HTTPS with current TLS everywhere on the site; never ask customers to send card details by email or chat. |
| 5 | Protect all systems and networks from malicious software | Anti-malware on staff computers and servers you manage; awareness of phishing, which is how most store admin accounts are stolen. |
| 6 | Develop and maintain secure systems and software | Keep your platform, theme and plugins patched; manage scripts on payment pages (6.4.3); protect public web apps against common attacks. |
| 7 | Restrict access by business need to know | Staff, agencies and freelancers get only the admin rights they need; remove access when work ends. |
| 8 | Identify users and authenticate access | Named accounts, no shared logins, strong passwords and multi-factor authentication on admin and hosting accounts. |
| 9 | Restrict physical access to cardholder data | Usually minimal online. Do not write card numbers on paper; secure any card terminals if you also sell in person. |
| 10 | Log and monitor all access | Keep admin and server logs and someone actually looks at alerts. Mostly relevant on SAQ A-EP and D. |
| 11 | Test security of systems and networks regularly | Quarterly external ASV scans where your SAQ requires them; penetration tests on A-EP and D; payment page tamper detection (11.6.1). |
| 12 | Support information security with policies and programmes | A short security policy, an incident response plan, an annual check of your providers’ PCI status and a written list of who does what. |
Requirements 6.4.3 and 11.6.1: payment page scripts
These two requirements exist because of web skimming, often called Magecart after the groups that made it common. Attackers do not need to break into the payment provider. They inject a few lines of JavaScript into the merchant’s checkout — through a compromised plugin, an analytics tag, a chat widget or a stolen admin password — and the script copies card details as the customer types them. The payment still succeeds, so these breaches can run for months unnoticed.
- 6.4.3 — manage payment page scripts. Keep an inventory of every script that loads on the payment page, with a written reason why each is needed, a method to confirm each is authorised, and a method to check its integrity. In practice: strip unneeded scripts from checkout, set a Content Security Policy and use Subresource Integrity for static scripts.
- 11.6.1 — detect changes to the payment page. Run a mechanism that alerts you to unauthorised changes to the page’s HTTP headers and script contents as the browser receives them, at least weekly or at a frequency set by a targeted risk analysis.
On SAQ A, ask the eligibility question honestly: if a tag manager on your product pages were compromised tomorrow, could it reach your checkout? If “possibly”, record it as a risk and fix it.
PCI compliance checklist for a small online store
Work through these in order. Each unticked box is a gap to record with an owner and a target date (see below).
Scope and validation
- ☐ Draw a one-page diagram of how a card payment flows: customer, your site, payment provider, acquirer.
- ☐ List every channel that takes card payments: website, marketplace, phone orders, payment links, in-person terminals.
- ☐ Confirm your merchant level and required SAQ with your acquirer in writing.
- ☐ Check you meet every eligibility criterion of that SAQ — including the script criterion for SAQ A.
- ☐ Diarise the annual SAQ and Attestation of Compliance submission date.
Card data
- ☐ Confirm no card numbers or CVVs are stored anywhere: database, logs, email inboxes, help desk, call recordings, spreadsheets.
- ☐ Tell staff never to take card details by email, chat or social messages, and how to respond if a customer sends them.
- ☐ Check that order confirmations and invoices show at most a masked card number.
Website and checkout
- ☐ Use HTTPS with current TLS across the whole site, not just checkout.
- ☐ Keep an inventory of scripts on payment pages, with a reason for each.
- ☐ Remove non-essential tags (marketing, chat, heatmaps) from checkout pages.
- ☐ Set a Content Security Policy and use Subresource Integrity where possible.
- ☐ Set up alerts for unexpected changes to the payment page, or obtain your provider’s written confirmation of script-attack protection.
- ☐ Apply platform, theme and plugin security updates promptly; remove abandoned plugins.
Access
- ☐ Give everyone a named account on the store admin, hosting, DNS and payment dashboards — no shared logins.
- ☐ Turn on multi-factor authentication for all of those accounts.
- ☐ Change every default password and remove accounts of former staff, agencies and freelancers.
- ☐ Review who has admin rights every quarter.
Testing and monitoring
- ☐ Run quarterly external scans with an Approved Scanning Vendor if your SAQ requires them, and keep passing reports.
- ☐ Rescan after significant changes to your site or hosting.
- ☐ Arrange penetration testing if you are on SAQ A-EP or D.
- ☐ Make sure someone receives and reads security alerts from your host, platform and payment provider.
Providers and policy
- ☐ Collect current PCI DSS evidence (AOC or listing) from your payment provider, platform and host each year.
- ☐ Agree in writing which PCI requirements each provider covers and which stay with you.
- ☐ Write a short security policy and an incident response plan that says who calls the acquirer if card data may be compromised.
- ☐ Run a brief annual security awareness session for everyone with admin access.
ASV scans and penetration testing
An ASV scan is an external vulnerability scan run by an Approved Scanning Vendor listed by the PCI SSC. Requirement 11.3.2 asks for one at least every three months, and after significant changes, with a passing result. Since v4.0 this requirement appears in SAQ A as well as SAQ A-EP and SAQ D, so most online merchants need quarterly scans of their public-facing website. A failing scan means fixing the issues and rescanning. Some acquirers bundle scanning into their PCI programme — ask before buying separately.
PCI penetration testing (requirement 11.4) is a manual attempt to break in, done at least once a year and after significant changes. It is part of SAQ A-EP and SAQ D but not SAQ A. For the day-to-day work of finding and fixing weaknesses, see our guide to building a vulnerability management process.
Hosted checkouts: Stripe, Shopify Payments, PayPal
The fastest way to shrink PCI scope is to keep card numbers off your systems entirely. Hosted payment pages and provider-served payment fields do that, which is why most small stores using them qualify for SAQ A.
- Stripe PCI compliance. Stripe is itself validated as a PCI DSS Level 1 service provider. If you use Stripe Checkout or Stripe’s hosted payment fields (Elements), card data goes straight to Stripe and you typically qualify for SAQ A. If you collect card numbers yourself and send them to Stripe’s API, you are in SAQ D territory.
- Shopify and Shopify Payments. Shopify is responsible for the PCI compliance of its hosted checkout. You remain responsible for your own account security, the apps and scripts you add, and any other channels you run.
- PayPal. Redirecting to PayPal keeps card data off your site. Embedded PayPal card fields shift some scope back to the page that hosts them.
What these services do not do for you:
- Fill in your SAQ or submit it for you.
- Protect the page that sends customers to checkout. A compromised site can redirect customers to a fake payment page.
- Secure your admin, hosting and payment dashboard logins.
- Cover other channels, such as card numbers taken over the phone and keyed into a virtual terminal.
- Stop fraud and chargebacks, which are a separate risk — covered in our guide to ecommerce fraud and chargebacks.
What PCI compliance costs
There is no single price. For a small online store, the cost of PCI compliance is driven mainly by:
- Your checkout design. A redirect or fully hosted form on SAQ A keeps the work to a few hours a year. Direct post or self-hosted integrations push you onto SAQ A-EP or D, with penetration tests, logging and far more evidence.
- Scanning. Quarterly ASV scans are a recurring cost, sometimes included in an acquirer’s or provider’s PCI programme.
- Testing and outside help. Penetration tests, a QSA review if your acquirer requires one, or a consultant to help with the questionnaire.
- Tooling. Script monitoring for payment pages, multi-factor authentication, log retention.
- Staff time. Inventories, access reviews and evidence collection — often the largest hidden cost.
PCI non-compliance fees are separate. Many acquirers charge a monthly fee to merchants that have not submitted a valid SAQ and AOC, or pass on a PCI programme fee. The amounts are set in your merchant agreement and vary widely, so check your statements and contract rather than relying on published averages. After a breach the costs are of a different order: forensic investigation, card brand assessments, card reissue and fraud recovery charges, and possible loss of card acceptance.
Recording PCI gaps in your risk register
A checklist shows where you fall short today; a risk register makes sure the gaps get closed. Record each material gap as a risk with an owner, a target date and the evidence that will close it:
| Risk | Gap | Owner | Action and due date | Evidence |
|---|---|---|---|---|
| Card data skimmed from checkout by a malicious script | No inventory of checkout scripts; marketing tags load on payment page | Head of ecommerce | Remove non-essential tags, set CSP, enable change alerts — 30 days | Script inventory; CSP header; alert test |
| Store admin account taken over | MFA not enforced for agency accounts | Operations manager | Enforce MFA for all admin users; remove stale accounts — 14 days | Admin user export showing MFA status |
| Acquirer non-compliance fees and loss of SAQ A eligibility | Quarterly ASV scans missed twice | Finance lead | Schedule scans; fix findings — next quarter | Passing ASV reports |
Score each risk on your usual risk matrix, and track the residual score once controls are in place.
Common mistakes
- “Our provider is PCI compliant, so we are.” Their compliance covers their systems. You still validate yours.
- Choosing an SAQ by hope. Picking SAQ A because it is shortest, when the checkout actually uses direct post. The integration decides the SAQ, not the merchant’s preference.
- Ticking the script criterion without evidence. If you cannot show how you know your site is not susceptible to script attacks, you are not eligible for SAQ A.
- Forgetting other channels. Phone orders, payment links and pop-up terminals bring their own requirements.
- Card data in the inbox. Customers email card numbers; those messages are now stored cardholder data.
- Once-a-year compliance. Plugins, tags and staff change monthly; the SAQ is a snapshot.
Frequently asked questions
Do I need to be PCI compliant if I use Stripe, Shopify Payments or PayPal?
Yes. A compliant provider reduces your scope, often to SAQ A, but does not remove it. You still validate each year, secure your website and the page that loads the payment form, and submit what your acquirer asks for.
What are the PCI compliance levels?
Four levels based on annual transactions. Under Visa’s scheme: Level 1 over 6 million; Level 2 1–6 million; Level 3 20,000 to 1 million ecommerce; Level 4 fewer than 20,000 ecommerce or up to 1 million in total. Your acquirer confirms your level.
What is a PCI attestation of compliance?
The signed form declaring the result of your assessment. Smaller merchants complete it with their SAQ; larger ones receive it with a QSA’s Report on Compliance. You submit it to your acquirer and should ask your providers for theirs.
What happens if I am not PCI compliant?
Acquirers typically charge non-compliance fees set in your merchant agreement. After a breach you may face forensic costs, card brand assessments, fraud recovery charges, a higher validation level or loss of card acceptance.
Turn PCI gaps into tracked risks
In Risk Samurai each PCI gap becomes a risk with an owner, a deadline and the evidence that closes it — so the annual questionnaire is a summary of work already done, not a scramble. AI drafts the first version of your register.
Get early access