PCI DSS Website Compliance Guide: Checklist for E-Commerce Sites

PCI DSS Website Compliance Guide: Checklist for E-Commerce Sites

PCI DSS compliance is the baseline standard every e-commerce website must meet before processing a single card transaction. The Payment Card Industry Data Security Standard (PCI DSS) — now at version 4.0 — defines 12 requirements across six goals, and failing any one of them can result in fines, chargebacks, or outright card network suspension.

This guide translates those 12 requirements into concrete, website-level actions: the TLS configuration, security headers, access controls, and logging practices that auditors check.

Check your compliance posture: Free ZeriFlow security scan →

Why PCI DSS Matters for Your Website (Not Just Your Payment Processor)

A common misconception: "We use Stripe/Braintree/Adyen — PCI doesn't apply to us." Wrong. While outsourcing payment processing reduces your scope, it does not eliminate it. Your website is still in scope if it:

• Hosts a checkout page that loads a payment form (even an iframe)
• Stores, processes, or transmits cardholder data in any form
• Influences the security of the payment environment through redirects, scripts, or cookies

The 2024 Verizon Payment Security Report found that only 43% of organizations maintained full PCI DSS compliance at interim assessment. The gap is almost always on the web layer: misconfigured TLS, missing headers, uncontrolled third-party scripts.

PCI DSS 4.0 introduced Requirement 6.4.3 and 11.6.1 specifically targeting client-side script integrity and change detection — a direct response to Magecart-style skimming attacks that compromised British Airways, Ticketmaster, and thousands of smaller merchants.

The 12 PCI DSS Requirements: A Simplified Checklist

PCI DSS organizes its 12 requirements into six control objectives. Here is what each one means at the website level.

Goal 1 — Build and Maintain a Secure Network

• Requirement 1: Install and maintain network security controls (firewalls, WAF, network segmentation separating the cardholder data environment from the rest of your infrastructure).
• Requirement 2: Apply secure configurations to all system components (no default credentials, disable unnecessary services, document your baseline configs).

Goal 2 — Protect Account Data

• Requirement 3: Protect stored account data. If you store PANs (Primary Account Numbers), they must be masked or encrypted with strong keys. Most websites should store nothing — use tokenization.
• Requirement 4: Protect cardholder data with strong cryptography during transmission. TLS 1.2 minimum, TLS 1.3 preferred. SSL and TLS 1.0/1.1 are explicitly prohibited. Weak cipher suites (RC4, DES, 3DES) are banned.

Goal 3 — Maintain a Vulnerability Management Program

• Requirement 5: Protect all systems and networks from malicious software. Anti-malware, regular scanning, integrity monitoring on payment pages.
• Requirement 6: Develop and maintain secure systems and software. This is where web security lives: patch management, secure coding standards, code review, WAF deployment, and — per v4.0 — an inventory of all scripts on your payment pages with justification for each.

Goal 4 — Implement Strong Access Control Measures

• Requirement 7: Restrict access to system components and cardholder data by business need to know.
• Requirement 8: Identify users and authenticate access to system components. MFA is now mandatory for all access into the cardholder data environment.
• Requirement 9: Restrict physical access to cardholder data.

Goal 5 — Regularly Monitor and Test Networks

• Requirement 10: Log and monitor all access to system components and cardholder data. Logs must be tamper-evident, retained for 12 months, and reviewed.
• Requirement 11: Test security of systems and networks regularly. Quarterly vulnerability scans (ASV-approved), annual penetration tests, and per v4.0, continuous monitoring for unauthorized script changes on payment pages (Requirement 11.6.1).

Goal 6 — Maintain an Information Security Policy

• Requirement 12: Support information security with organizational policies and programs. Annual risk assessment, vendor management, incident response plan.

TLS Configuration: The Technical Baseline

Requirement 4 is the most technically specific and the most commonly misconfigured. Your website must:

1. 1Enforce HTTPS on every page — not just checkout. A valid HSTS header (Strict-Transport-Security: max-age=31536000; includeSubDomains) prevents protocol downgrade.
2. 2Disable TLS 1.0 and 1.1 — both are formally deprecated and banned under PCI DSS 4.0.
3. 3Disable SSL 2.0 and 3.0 entirely.
4. 4Use strong cipher suites only — prefer ECDHE for forward secrecy. Remove CBC-mode ciphers if possible (BEAST/POODLE risk).
5. 5Renew certificates before expiry — expired certificates trigger browser warnings that push customers away from checkout and signal poor security hygiene to auditors.

ZeriFlow scans your TLS configuration end-to-end: protocol versions, cipher suite ordering, certificate validity, HSTS presence, and HTTP-to-HTTPS redirect behavior — surfacing PCI-relevant findings in seconds.

Security Headers for PCI DSS: What Auditors Look For

PCI DSS 6.3.3 and the v4.0 client-side script requirements point directly to HTTP security headers as a technical control. The headers most relevant to compliance:

Content-Security-Policy (CSP) — Arguably the single most important header for e-commerce. A strict CSP restricts which scripts can execute on your checkout page, directly mitigating Magecart and formjacking attacks. PCI DSS 4.0 Requirement 6.4.3 requires an inventory and integrity mechanism for all scripts — CSP with 'sha256-...' or nonce- values satisfies this.

X-Frame-Options / frame-ancestors — Prevents clickjacking attacks that could overlay a fake payment form on top of your legitimate checkout.

X-Content-Type-Options: nosniff — Prevents MIME-type sniffing that could cause browsers to execute uploaded files as scripts.

Referrer-Policy — Reduces the risk of leaking cardholder-adjacent data (session tokens, order IDs) to third-party analytics via the Referer header.

Permissions-Policy — Restricts access to browser APIs (camera, microphone, geolocation) that have no business being active on a payment page.

PCI DSS 4.0: What Changed and What Your Website Must Do Now

PCI DSS 4.0 became the sole active version on March 31, 2024. The two web-facing requirements with the longest implementation runway (marked "future-dated" in v4.0) became mandatory on March 31, 2025:

Requirement 6.4.3 — Script inventory and integrity on payment pages. You must maintain a documented inventory of all scripts on pages that capture payment data. Each script must have a business justification, and there must be a method to confirm integrity (CSP hashes, Subresource Integrity, or a runtime script monitoring solution).

Requirement 11.6.1 — Unauthorized change detection. A mechanism must be in place to detect unauthorized modifications to HTTP headers and script contents on payment pages. This typically means a script monitoring service that alerts when new scripts are injected or existing ones are modified.

If your site is still running third-party tag managers with unbounded permissions on checkout pages, you are out of compliance with v4.0 today.

Common PCI DSS Failures on the Web Layer

Audit findings cluster around a predictable set of web-layer failures:

• Mixed content: A checkout page served over HTTPS loading resources (images, scripts, fonts) over HTTP. Browsers block these; PCI auditors flag them.
• Expired or weak TLS certificates: Often caused by automation gaps in certificate renewal.
• Missing HSTS: Without HSTS, a user who types yourstore.com (without HTTPS) can be intercepted before the redirect.
• Overly permissive CSP: A CSP that includes unsafe-inline or * as script sources provides no protection against script injection.
• Uncontrolled third-party scripts: Google Tag Manager, live chat widgets, and affiliate trackers loaded on checkout without integrity checks.
• No cookie security attributes: Session cookies without Secure and HttpOnly flags can be accessed over HTTP or via JavaScript — both violate the principle of protecting data in transit.

FAQ

Q: Do I need PCI DSS compliance if I only use an embedded payment widget like Stripe.js?

A: Yes, but your scope is significantly reduced. If you use a fully hosted payment page (redirect to Stripe Checkout, for example), you may qualify for SAQ A, the simplest self-assessment questionnaire — roughly 22 requirements focused on your website's general security posture. If you embed a JavaScript widget (Stripe Elements), you typically fall under SAQ A-EP, which includes Requirement 6.4.3 and the script integrity controls. Always confirm your SAQ level with a Qualified Security Assessor (QSA).

Q: What is the difference between PCI DSS and PA-DSS?

A: PCI DSS applies to merchants and service providers that store, process, or transmit cardholder data. PA-DSS (now replaced by the Software Security Standard, PCI SSF) applies to payment application vendors — the companies building payment software. If you buy a shopping cart platform, you want to confirm it is PCI SSF validated. If you operate a store using that platform, PCI DSS applies to you.

Q: How often do I need to scan for vulnerabilities under PCI DSS?

A: Requirement 11.3.2 mandates ASV (Approved Scanning Vendor) external vulnerability scans at least quarterly and after any significant infrastructure change. Requirement 11.4.1 mandates an internal and external penetration test at least annually. These are minimums — high-risk environments should scan more frequently.

Q: Can failing a security header cause a PCI DSS audit failure?

A: Not directly — PCI DSS does not enumerate a specific list of required headers. However, missing headers can be cited as evidence of failing Requirement 6.3.3 (protection against known vulnerabilities) or 6.4.3 (script integrity). A QSA conducting a penetration test will flag absent security headers as findings that need remediation before passing.

Q: What are the fines for PCI DSS non-compliance?

A: Card networks (Visa, Mastercard) can fine acquiring banks $5,000–$100,000 per month for non-compliant merchants, and those fines are typically passed downstream to the merchant. After a breach, non-compliant merchants bear full liability for fraud losses and forensic investigation costs. The reputational damage — and the loss of card acceptance privileges — is often more damaging than the fines themselves.

Conclusion

PCI DSS compliance on the web layer comes down to a handful of verifiable technical controls: enforced HTTPS with valid TLS 1.2+, a restrictive Content-Security-Policy on checkout pages, documented script inventory, HSTS, secure cookie attributes, and tamper-detection for payment page scripts. These are not abstract policy requirements — they are configuration choices you can audit today.

The fastest way to identify gaps before your QSA does is to run an automated scan against your live environment.

Run a free compliance-focused scan on ZeriFlow →