PCI DSS Compliance Checklist: All 12 Requirements Explained

Meeting PCI DSS compliance requirements is mandatory for any organization that handles credit card data. Whether you process ten transactions a month or ten million, the Payment Card Industry Data Security Standard applies to you. Failing to comply can result in fines ranging from $5,000 to $100,000 per month, increased transaction fees, and even losing your ability to accept card payments.

This PCI DSS compliance checklist breaks down all 12 requirements into actionable steps. Use it as a working document to track your progress toward compliance and prepare for your next assessment.

Who Needs PCI DSS Compliance?

Every organization that stores, processes, or transmits cardholder data must comply with PCI DSS. This includes:

• Merchants accepting card payments (online, in-store, or by phone)
• Service providers processing payments on behalf of merchants
• Payment processors and acquiring banks
• Any third party with access to cardholder data environments

Your compliance level depends on your annual transaction volume. Level 1 merchants (over 6 million Visa transactions annually) require an annual on-site assessment by a Qualified Security Assessor (QSA). Levels 2 through 4 can typically self-assess using the appropriate Self-Assessment Questionnaire (SAQ).

Requirement 1: Install and Maintain Network Security Controls

Network security controls (NSCs) form the first line of defense around your cardholder data environment (CDE). Under PCI DSS 4.0, this requirement expanded beyond traditional firewalls to include cloud security groups, software-defined networking, and other modern technologies.

Checklist items:

• Document all network connections into and out of the CDE
• Create network diagrams showing all cardholder data flows
• Configure NSC rulesets to restrict traffic to only what is necessary
• Review NSC rules every six months (changed from annually in PCI DSS 4.0)
• Restrict inbound traffic at the individual system level, not just the perimeter
• Assign specific roles and responsibilities for NSC management

Requirement 2: Apply Secure Configurations to All System Components

Default configurations on servers, network devices, and applications are well-known to attackers. PCI DSS requires you to harden every component before it enters your production environment.

Checklist items:

• Remove or disable all vendor-supplied default accounts
• Change all default passwords before deploying any system
• Develop configuration standards for all system types (servers, databases, network devices)
• Encrypt all non-console administrative access using strong cryptography
• Maintain an inventory of all system components in scope for PCI DSS
• Implement only one primary function per server to minimize attack surface

Requirement 3: Protect Stored Account Data

The simplest way to reduce PCI DSS scope is to avoid storing cardholder data entirely. If you must store it, strict controls apply.

Checklist items:

• Define and enforce data retention policies with specific timeframes
• Do not store sensitive authentication data after authorization (CVV, PIN, full track data)
• Mask the primary account number (PAN) when displayed, showing only the first six and last four digits
• Render PAN unreadable anywhere it is stored using tokenization, truncation, or strong encryption
• Document and implement key management procedures for encryption keys
• Rotate encryption keys at the end of their defined cryptoperiod or when key integrity is suspected compromised

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Cardholder data transmitted over open, public networks is vulnerable to interception. PCI DSS requires strong cryptographic protocols for any transmission of card data.

Checklist items:

• Use TLS 1.2 or higher for all transmissions of cardholder data over public networks
• Confirm that certificates are valid, not expired, and issued by a trusted CA
• Verify that only trusted keys and certificates are accepted
• Do not send unprotected PANs via end-user messaging technologies (email, SMS, chat)
• Document all trusted keys and certificates with expiration dates

Requirement 5: Protect All Systems and Networks from Malicious Software

Anti-malware protections must cover all systems commonly affected by malicious software within the CDE.

Checklist items:

• Deploy anti-malware solutions on all systems commonly affected by malware
• Keep anti-malware mechanisms current with automatic updates
• Perform periodic scans and enable real-time monitoring
• Generate and retain anti-malware logs
• Implement anti-phishing mechanisms to detect and protect against phishing attacks (new in PCI DSS 4.0)
• For systems not commonly affected by malware, perform periodic evaluations to confirm they remain low risk

Requirement 6: Develop and Maintain Secure Systems and Software

Vulnerabilities in applications and systems are a primary attack vector. PCI DSS requires both patching and secure development practices.

Checklist items:

• Install critical security patches within one month of release
• Establish a vulnerability management process to identify and rank vulnerabilities
• Develop software following secure coding guidelines (OWASP Top 10, SANS CWE Top 25)
• Protect public-facing web applications against known attacks using a web application firewall (WAF) or code review
• Manage all payment page scripts loaded in the consumer browser (new in PCI DSS 4.0, Requirement 6.4.3)
• Maintain an inventory of custom and third-party software components

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Access to cardholder data should follow the principle of least privilege. Only individuals whose job requires access should have it.

Checklist items:

• Define access needs for each role that interacts with cardholder data
• Restrict access to system components and data to only those individuals with a documented business need
• Default access control settings to "deny all" unless explicitly allowed
• Review all user accounts and access privileges at least every six months

Requirement 8: Identify Users and Authenticate Access to System Components

Every person with access to the CDE must be uniquely identified. Shared or generic accounts obscure accountability and make incident investigation nearly impossible.

Checklist items:

• Assign a unique ID to each person with computer access
• Require multi-factor authentication (MFA) for all access into the CDE (expanded in PCI DSS 4.0 beyond remote-only)
• Set minimum password length to 12 characters (increased from 7 in PCI DSS 4.0)
• Change passwords at least every 90 days, or implement dynamic security analysis of accounts
• Lock out accounts after no more than 10 failed login attempts
• Set session idle timeout to 15 minutes

Requirement 9: Restrict Physical Access to Cardholder Data

Physical security controls prevent unauthorized individuals from accessing systems or paper records containing cardholder data.

Checklist items:

• Use entry controls (badges, biometrics, locks) to limit physical access to the CDE
• Distinguish between onsite personnel and visitors using visible identification
• Authorize and log visitor access, retain logs for at least three months
• Physically secure all media (paper, electronic) containing cardholder data
• Destroy media containing cardholder data when it is no longer needed using cross-cut shredding, incineration, or secure digital wiping
• Protect point-of-sale (POS) devices from tampering and substitution

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Logging and monitoring are essential for detecting and responding to security incidents. Without proper logs, you cannot investigate breaches or demonstrate compliance.

Checklist items:

• Implement audit trails linking all access to system components to individual users
• Log all actions taken by any individual with administrative privileges
• Record audit trail entries including user identification, event type, date/time, success/failure, origination, and affected resource
• Synchronize all critical system clocks using NTP
• Secure audit trails so they cannot be altered
• Review logs and security events daily to identify anomalies (automated log review tools recommended in PCI DSS 4.0)
• Retain audit trail history for at least 12 months, with the most recent 3 months immediately available

Requirement 11: Test Security of Systems and Networks Regularly

Regular testing validates that your security controls are actually working. PCI DSS requires both automated scanning and manual testing.

Checklist items:

• Run internal vulnerability scans quarterly, remediate high-risk and critical findings, and rescan
• Run external vulnerability scans quarterly through an Approved Scanning Vendor (ASV)
• Perform internal and external penetration testing at least annually and after significant changes
• Deploy intrusion detection/prevention systems (IDS/IPS) to monitor all traffic in the CDE
• Implement a change detection mechanism (file integrity monitoring) on critical files
• Perform targeted risk analysis to define the frequency of periodic log reviews (new flexibility in PCI DSS 4.0)

Requirement 12: Support Information Security with Organizational Policies and Procedures

PCI DSS compliance is not purely technical. Requirement 12 covers the governance framework that ties everything together.

Checklist items:

• Establish, publish, and maintain an information security policy reviewed annually
• Perform a formal risk assessment at least annually and upon significant changes
• Implement a security awareness program for all personnel, including phishing simulation training
• Screen potential personnel before hiring (background checks for positions with CDE access)
• Maintain an incident response plan, test it annually, and train designated staff
• Manage and monitor all third-party service providers with access to cardholder data, confirm their PCI DSS compliance status annually

PCI DSS Compliance Levels at a Glance

| Level | Annual Transactions | Assessment Type | Required By | |-------|-------------------|-----------------|-------------| | 1 | Over 6 million | On-site QSA audit | All card brands | | 2 | 1-6 million | SAQ + quarterly ASV scan | Visa, Mastercard | | 3 | 20,000-1 million (e-commerce) | SAQ + quarterly ASV scan | Visa, Mastercard | | 4 | Under 20,000 (e-commerce) or up to 1 million (other) | SAQ + quarterly ASV scan (may vary) | Varies by acquirer |

How PCI DSS Connects to Other Frameworks

If you are pursuing multiple compliance certifications, PCI DSS shares significant overlap with several frameworks:

• SOC 2: SOC 2 Trust Service Criteria for Security and Availability overlap with PCI DSS requirements 1, 2, 5, 6, and 10
• ISO 27001: Annex A controls in ISO 27001 map to most PCI DSS requirements, especially access control (Req 7-8) and cryptography (Req 3-4)
• NIST CSF: The NIST Cybersecurity Framework's five functions align naturally with PCI DSS's requirement structure
• HIPAA: Healthcare organizations handling payments need both HIPAA and PCI DSS, with overlap in access controls and encryption

Using a GRC platform to map controls across frameworks can reduce duplicate effort by 30-50%.

Frequently Asked Questions

What happens if my organization fails a PCI DSS assessment?

Failure to comply can result in monthly fines between $5,000 and $100,000 from card brands, increased transaction fees, and potential revocation of card processing privileges. Your acquiring bank may also impose additional requirements or terminate your merchant account.

How often do I need to validate PCI DSS compliance?

PCI DSS compliance validation is required annually. Level 1 merchants need an annual on-site assessment by a QSA. Levels 2-4 complete an annual SAQ. All levels must run quarterly external vulnerability scans through an ASV.

Can I outsource PCI DSS compliance to a payment processor?

Outsourcing payment processing reduces your PCI DSS scope but does not eliminate it. You are still responsible for confirming your service provider's compliance status, securing the handoff of data, and completing the appropriate SAQ. Using a PCI-compliant processor like Stripe or Braintree significantly simplifies compliance.

What is the difference between PCI DSS 3.2.1 and 4.0?

PCI DSS 4.0 introduced a customized approach for meeting requirements, expanded MFA to all CDE access (not just remote), increased minimum password length to 12 characters, added anti-phishing controls, and requires management of payment page scripts. All organizations must comply with 4.0 as of March 31, 2025. See our detailed PCI DSS 4.0 guide for a full comparison.

How long does it take to become PCI DSS compliant?

Timeline varies by organization size and current security posture. Small merchants completing an SAQ might achieve compliance in 1-3 months. Large Level 1 merchants typically need 6-12 months for initial compliance, including gap remediation, control implementation, and the formal QSA assessment.