Every online store that accepts card payments has to comply with PCI DSS, whether it processes cards directly or routes everything through a payment gateway. PCI DSS 4.0.1 is now fully in force, and the requirements that matter most for ecommerce — client-side script management and payment page monitoring — went from "recommended" to mandatory in 2025. This checklist is for the person who owns the storefront's security posture: a technical lead, a founder without a dedicated security team, or an agency scoping a new build.

Before you start: figure out which SAQ applies to you

Your PCI obligations depend entirely on how card data touches your systems. Confirm your SAQ (Self-Assessment Questionnaire) type with your acquiring bank or payment gateway before doing anything else — it determines everything downstream.

  • [ ] Confirm whether checkout is fully hosted/redirected to a PCI-compliant processor, embedded via iframe, or handled with your own form fields
  • [ ] If fully outsourced (hosted page, redirect, or iframe with no card data touching your server) → you likely qualify for SAQ A, the lightest tier
  • [ ] If you use a JavaScript-based payment form embedded directly on your page (not an iframe) → you're likely SAQ A-EP, which carries much heavier obligations
  • [ ] If you store, process, or transmit cardholder data on your own servers → you're SAQ D, the full standard
  • [ ] Get this confirmed in writing by your acquirer or payment gateway — don't self-diagnose on a guess

Client-side script management (mandatory since April 2025)

This is the requirement most ecommerce teams miss, because it applies even to merchants on the "easy" SAQ A tier.

  • [ ] Inventory every script that loads on your payment and checkout pages — analytics tags, chat widgets, A/B testing snippets, ad pixels, everything
  • [ ] Document a written business justification for each script that has a legitimate reason to be there
  • [ ] Remove any script you can't justify
  • [ ] Implement a mechanism to detect unauthorized changes to scripts on payment pages (Content Security Policy with reporting, subresource integrity, or a dedicated script-monitoring tool)
  • [ ] Set a review cadence — quarterly at minimum — to re-check the inventory as marketing and dev teams add new tags

Payment page tampering detection

  • [ ] Deploy a mechanism that detects unauthorized modification of HTTP headers and page contents on payment pages (this is distinct from script management — it covers the page itself, not just third-party scripts)
  • [ ] Confirm your payment gateway or CDN provider offers this natively before building something custom
  • [ ] Set up alerting so a detected change reaches a human within hours, not at the next audit

Access control and authentication

  • [ ] Multi-factor authentication enabled for every individual with access to the cardholder data environment — this now applies to internal staff and third-party vendors with access, no exceptions
  • [ ] No shared logins or default vendor passwords anywhere in the stack
  • [ ] Access to card data environment limited strictly to roles that need it — review this list quarterly, not just at onboarding
  • [ ] Offboarding process that revokes access same-day when someone leaves or changes roles

Ongoing scanning and testing

  • [ ] External vulnerability scans by an Approved Scanning Vendor (ASV) at least quarterly
  • [ ] Internal vulnerability scans at least every 90 days
  • [ ] Annual penetration test covering the full cardholder data environment perimeter
  • [ ] Remediation plan and timeline documented for anything scans turn up — an open finding with no plan is itself a compliance gap

Documentation you'll need on hand

  • [ ] Signed Attestation of Compliance (AOC) matching your confirmed SAQ type
  • [ ] Data flow diagram showing exactly where card data enters, moves, and exits your systems
  • [ ] 12 months of continuous evidence — scan reports, access logs, script inventory reviews — not a one-time snapshot taken right before an audit
  • [ ] Written incident response plan specific to a suspected card data breach

Red flags that mean you need outside help

  • Your checkout uses custom JavaScript to collect card fields directly (this pushes you into SAQ A-EP or D territory fast)
  • Nobody on the team can currently produce a script inventory for the checkout page
  • Your last PCI assessment predates April 2025 and hasn't been redone against v4.0.1
  • You're planning a replatform or checkout redesign and haven't looped in whoever owns compliance

How to use this

Work through the SAQ determination first — it changes which of the later sections actually apply to you. If you land on SAQ A, the script management and tampering detection items are still mandatory; don't assume the lighter tier means less work on those two specifically. Treat the "ongoing scanning" section as a recurring calendar item, not a one-time checklist — PCI DSS 4.0.1 explicitly frames compliance as continuous, and assessors will ask for a full year of evidence, not a snapshot.