PCI DSS Compliance Checklist for Websites — 2026 Guide

Non-compliance is expensive. PCI DSS fines range from $5,000 to $100,000 per month until compliance is achieved. Beyond fines, a data breach involving payment card data can result in forensic investigation costs ($50,000+), card brand penalties, increased processing fees, and loss of the ability to accept credit cards entirely.

PCI DSS 4.0 is the current standard, with full enforcement since March 2025. This guide maps PCI DSS requirements to actionable website security checks with copy-paste configurations.

What Is PCI DSS 4.0?

PCI DSS (Payment Card Industry Data Security Standard) is maintained by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover, and JCB. It defines 12 requirements organized into 6 goals:

1. Build and Maintain a Secure Network — Firewalls, no default passwords
2. Protect Cardholder Data — Encryption at rest and in transit
3. Maintain a Vulnerability Management Program — Patching, antivirus, secure development
4. Implement Strong Access Control — Least privilege, unique IDs, MFA
5. Regularly Monitor and Test Networks — Logging, vulnerability scanning, penetration testing
6. Maintain an Information Security Policy — Documentation, training, incident response

Who Needs PCI DSS Compliance?

If your website accepts credit card payments in any form, you have PCI DSS obligations:

• Level 1: Over 6 million transactions/year — requires annual on-site audit
• Level 2: 1-6 million transactions/year — SAQ + quarterly ASV scans
• Level 3: 20,000-1 million e-commerce transactions/year — SAQ + quarterly ASV scans
• Level 4: Under 20,000 e-commerce transactions/year — SAQ + quarterly ASV scans (recommended)

Requirement 2: Secure Configurations

Do not use vendor-supplied defaults for system passwords and other security parameters.

# Checklist:
✅ Change all default passwords (database, admin panels, CMS)
✅ Remove or disable unnecessary services and ports
✅ Disable directory listing
✅ Remove default/sample pages and documentation
✅ Configure security headers (CSP, HSTS, X-Frame-Options)
✅ Remove server version information from headers

# Apache — Remove server info
ServerTokens Prod
ServerSignature Off
Header always unset X-Powered-By

# Nginx — Remove server info
server_tokens off;
more_clear_headers Server;

Requirement 4: Encrypt Transmissions (TLS) CRITICAL

PCI DSS 4.0 requires TLS 1.2 or higher. TLS 1.0 and 1.1 are explicitly prohibited.

# Apache — TLS 1.2+ only
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on

# Nginx — TLS 1.2+ only
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

# HSTS — Force HTTPS
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Redirect HTTP to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Requirement 6: Secure Development & WAF

Develop and maintain secure systems and applications.

# Checklist:
✅ Apply security patches within 30 days of release (critical within 15 days)
✅ Follow secure coding practices (OWASP Top 10)
✅ Deploy a Web Application Firewall (WAF)
✅ Protect against common vulnerabilities:
   - SQL injection (use parameterized queries)
   - XSS (output encoding + CSP)
   - CSRF (anti-CSRF tokens)
   - Insecure direct object references
   - Security misconfiguration

# WAF Options:
# - Cloudflare WAF (free tier available)
# - AWS WAF ($5/month + per-rule pricing)
# - ModSecurity (free, open-source)

# ModSecurity with OWASP Core Rule Set
SecRuleEngine On
Include /etc/modsecurity/owasp-crs/crs-setup.conf
Include /etc/modsecurity/owasp-crs/rules/*.conf

Requirement 8: Strong Authentication

Identify users and authenticate access to system components.

# Checklist:
✅ Unique user IDs for all users (no shared accounts)
✅ Multi-factor authentication (MFA) for all admin access
✅ Password policy: minimum 12 characters (PCI DSS 4.0 increased from 7)
✅ Account lockout after 10 failed attempts
✅ Session timeout after 15 minutes of inactivity
✅ Change passwords every 90 days (or use MFA)

# PHP — Session timeout
ini_set('session.gc_maxlifetime', 900); // 15 minutes
session_set_cookie_params(900);

# Apache — Basic auth for admin areas
<Location /admin>
  AuthType Basic
  AuthName "Admin Access"
  AuthUserFile /etc/apache2/.htpasswd
  Require valid-user
</Location>

Requirement 10: Logging & Monitoring

Track and monitor all access to network resources and cardholder data.

# Checklist:
✅ Log all access to cardholder data
✅ Log all admin actions
✅ Log all authentication attempts (success and failure)
✅ Log all changes to system configurations
✅ Synchronize clocks with NTP
✅ Retain logs for at least 1 year (3 months immediately available)
✅ Review logs daily

# Apache — Enable detailed access logging
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /var/log/apache2/access.log combined
ErrorLog /var/log/apache2/error.log

# Nginx — Detailed logging
access_log /var/log/nginx/access.log combined;
error_log /var/log/nginx/error.log warn;

Requirement 11: Vulnerability Scanning HIGH

Regularly test security systems and processes.

# Checklist:
✅ Quarterly external vulnerability scans by an ASV (Approved Scanning Vendor)
✅ Internal vulnerability scans after any significant change
✅ Annual penetration testing
✅ Wireless access point detection (quarterly)
✅ File integrity monitoring on critical files

# Use AI QA Monkey for continuous external scanning:
# - SSL/TLS configuration validation
# - Open port detection
# - Security header analysis
# - Sensitive file exposure
# - CORS misconfiguration
# - Compliance mapping (PCI DSS, ISO 27001, OWASP)

Quick Compliance Checklist

PCI DSS 4.0: new requirements teams must act on now

PCI DSS 4.0 introduced several requirements with no equivalent in v3.2.1. Organizations that have not reviewed their implementation against these specific controls risk non-compliance and failed ASV scans.

• Requirement 6.4.3 — Payment page script management: All JavaScript on payment pages must be inventoried with business justification, authorized, and integrity-verified. Implement Subresource Integrity (SRI) hashes on all externally-hosted scripts: <script src="https://cdn.example.com/script.js" integrity="sha256-..." crossorigin="anonymous"></script>.
• Requirement 6.4.2 — Automated detection and prevention for web applications: WAF is now mandatory with active blocking (not just detection mode) for payment pages. Log review must be automated, not manual.
• Requirement 11.6.1 — Change and tamper detection: An automated mechanism must alert on unauthorized changes to HTTP response headers and payment page content. Implement Content Security Policy violation reporting (report-uri) and file integrity monitoring.
• Requirement 8.4.2 — MFA for all access into the CDE: Multi-factor authentication is now required for all access to the cardholder data environment — including internal access from trusted networks, not just external access.
• Requirement 12.3.2 — Targeted risk analysis: For requirements with flexible implementation timelines, organizations must document a targeted risk analysis justifying their approach. This applies to 13 specific requirements in v4.0.

SAQ type selection: which self-assessment applies to your site

Most e-commerce websites use hosted payment pages and do not directly handle card data. The correct SAQ type determines your compliance scope — choosing the wrong one creates unnecessary work or insufficient coverage.

• SAQ A: For merchants that fully outsource all payment processing to a PCI DSS-compliant third party (Stripe, PayPal, Square) with no electronic storage, processing, or transmission of card data. Your website must not be susceptible to attacks that could affect the payment processor. This is the most common type for e-commerce sites using hosted payment fields.
• SAQ A-EP: For merchants with a payment page hosted on their own server that redirects or submits to a third-party payment processor. More controls required than SAQ A — includes vulnerability scanning and web application firewall requirements.
• SAQ D: For merchants who store, process, or transmit cardholder data — or those who cannot qualify for a simpler SAQ. All 12 requirements apply. Very few e-commerce websites should be in this category in 2026.

Scope reduction: how to minimize your PCI DSS footprint

The most effective PCI DSS strategy is to minimize your scope — reduce the number of systems that are in scope for PCI DSS by ensuring as little cardholder data as possible touches your infrastructure.

• Use hosted payment fields (iframes): Stripe Elements, PayPal hosted buttons, and Braintree Drop-in UI render payment form fields in an iframe from the processor's domain. Card data never touches your server — removing your web server from scope for card data handling.
• Tokenization: Replace card data with tokens immediately at point of capture. Your system stores a token, not a card number. Tokens are worthless to attackers without access to the tokenization system.
• Point-to-Point Encryption (P2PE): Encrypts card data at the point of interaction (card reader or payment terminal) before it enters any network you control. Validated P2PE solutions significantly reduce PCI scope for physical payment environments.
• Network segmentation: Isolate systems that touch cardholder data from the rest of your network. Systems outside the cardholder data environment (CDE) are out of scope for PCI DSS. Proper segmentation verified by a qualified assessor reduces audit scope and cost significantly.

Frequently Asked Questions

What is PCI DSS?

PCI DSS is a security standard for companies that handle credit card data. Version 4.0 is current, with full enforcement since March 2025.

Does my website need PCI DSS compliance?

If your website accepts credit card payments in any form — even through Stripe or PayPal — you have some level of PCI DSS responsibility.

What PCI DSS requirements apply to websites?

Key requirements include secure configurations (Req 2), TLS 1.2+ encryption (Req 4), secure development and WAF (Req 6), strong authentication (Req 8), logging (Req 10), and vulnerability scanning (Req 11).