PCI DSS enters the conversation the moment a website touches cardholder data – even indirectly, through a hosted checkout iframe or a redirect to a payment processor. For any business running an online store or accepting card payments through a booking form, understanding where PCI DSS obligations actually start (and where they end) is the difference between a clean annual attestation and a scramble after an acquiring bank flags a violation.
What PCI DSS actually covers
The Payment Card Industry Data Security Standard is a contractual requirement, not a law – but functionally it behaves like one, since Visa, Mastercard, American Express, Discover, and JCB all require compliance as a condition of accepting their cards. Version 4.0 became mandatory for most requirements on 31 March 2024, with a subset of “future-dated” requirements (things like automated log review and targeted risk analyses) becoming enforceable on 31 March 2025.
The standard applies to anyone who stores, processes, or transmits cardholder data, or who could impact the security of a payment environment. That last clause catches a lot of websites that don’t think of themselves as payment processors. A marketing site with a “Buy Now” button that redirects to Stripe Checkout is still in scope – at a reduced level – because a compromised redirect script could send customers to a fake payment page.
The four merchant levels and what they mean for a website
Card brands classify merchants by annual transaction volume, and the level determines how compliance gets validated:
Level 1 merchants process over 6 million transactions a year and need an annual on-site audit by a Qualified Security Assessor (QSA). Level 2 (1–6 million transactions) and Level 3 (20,000–1 million e-commerce transactions) typically self-assess using a Self-Assessment Questionnaire (SAQ), though some acquirers require a QSA regardless of volume if there’s been a prior breach. Level 4 covers everyone else – the vast majority of small and mid-sized online sellers – and usually just needs an SAQ plus a passing ASV (Approved Scanning Vendor) network scan.
Most small e-commerce sites fall under SAQ A or SAQ A-EP. SAQ A applies when card data entry is fully outsourced to a third-party iframe or redirect (think Stripe Elements, PayPal Checkout, or a Shopify-hosted payment page) and the merchant’s own server never touches card data. SAQ A-EP applies when the site controls the payment page itself, even if the actual card number transmission goes straight to the processor – this is common with custom-styled checkout forms that use a processor’s JavaScript SDK inline rather than an iframe.
Where sites get this wrong
A common misconception: “We use Stripe, so we’re PCI compliant automatically.” Stripe being Level 1 PCI DSS certified covers Stripe’s infrastructure – it does not automatically cover the merchant’s website. If a script injected into a checkout page (through a compromised npm package, a rogue Magento extension, or a malicious tag manager entry) skims card data before it reaches Stripe’s iframe, that’s a merchant-side failure, not Stripe’s. This exact pattern is what Magecart-style attacks exploit, and it’s precisely why PCI DSS 4.0 introduced Requirement 6.4.3 (authorizing and inventorying all payment page scripts) and 11.6.1 (deploying a change-detection mechanism to alert on unauthorized modifications to payment pages), both enforceable since March 2025.
Another mistake practitioners make repeatedly: treating the SAQ as a one-time form filled out at signup and never revisited. Payment integrations change – a developer swaps in a new analytics pixel, a marketing team adds a chat widget to the checkout page, a plugin update silently changes how form fields post data. Each of those can shift a site from SAQ A eligibility into SAQ A-EP territory without anyone noticing until the next audit cycle or, worse, until a breach investigation.
A third recurring gap: assuming the accessibility of legal pages and payment security are unrelated concerns handled by different teams. In practice, PCI scope reviews and broader website compliance checklists overlap more than most teams realize – both require knowing exactly what third-party scripts are running on checkout-adjacent pages.
Steps to establish and maintain PCI scope
A GRC lead handling this for the first time typically works through it in this order:
First, map every place card data could theoretically appear – checkout page, order confirmation email templates, customer service tools, backup exports, log files. It’s common to find PANs (primary account numbers) sitting in application logs because a developer left verbose logging on during a debugging session months earlier.
Second, determine which SAQ type applies based on how payment fields are rendered. An iframe-only integration (SAQ A) is materially less burdensome than a JavaScript SDK inline integration (SAQ A-EP), so if the site currently uses the latter without a strong reason, migrating to a hosted iframe often cuts the audit workload by more than half.
Third, run quarterly ASV scans against all public-facing IPs handling payment traffic – this is mandatory for nearly every SAQ type except the most restricted outsourced-only scenarios. A failed scan (an expired TLS cert, a deprecated cipher suite, an exposed admin panel) blocks the compliance attestation until remediated and rescanned.
Fourth, inventory and authorize every script running on payment pages per Requirement 6.4.3, and put a monitoring mechanism in place per 11.6.1. Tag managers are the usual blind spot here – Google Tag Manager containers get edited by marketing without security review, and a single unreviewed tag addition can silently pull in third-party code with checkout-page access. This overlaps closely with the concerns covered in tracking hidden data leaks from third-party scripts.
Fifth, verify TLS configuration continuously rather than just at audit time – PCI DSS requires TLS 1.2 minimum (1.3 recommended) on any page transmitting cardholder data, and certificate expiration or misconfiguration between audit cycles is a real, recurring cause of scope drift. This is covered in more depth in the discussion of SSL compliance monitoring.
Frequently asked questions
Does a small business with under 100 card transactions a month still need to worry about PCI DSS?
Yes. There’s no minimum transaction threshold below which PCI DSS stops applying – Level 4 status just means self-assessment rather than a mandatory external audit, but the underlying security requirements (encrypted transmission, script inventory, no storage of full card numbers or CVV) still apply from transaction one.
If a site only uses a payment processor’s hosted checkout page and never sees card numbers, is any PCI paperwork still required?
Yes – typically SAQ A, which is the shortest questionnaire (about 22 questions in v4.0) but still needs to be completed and attested to annually, usually through the acquiring bank or payment processor’s dashboard.
How long does a card number or CVV need to be retained for chargebacks or disputes?
The CVV/CVC should never be stored after authorization, period – no exceptions, regardless of dispute handling needs. Full PANs, if retained at all for legitimate business reasons, must be encrypted and access-restricted, with retention limited to what’s documented in a formal data retention policy.
PCI DSS scope isn’t static – it moves every time a checkout page changes, a new script gets added, or a payment integration gets swapped. Treating the SAQ as a living document tied to actual site monitoring, rather than an annual paperwork exercise, is what keeps a merchant out of the post-breach conversation with their acquiring bank.