PCI DSS

PCI DSS Compliance Checklist: All 12 Requirements Explained

Security Compliance Guide Editorial Team
Security Compliance Guide Editorial Team
·Updated: July 3, 2026 · 13 min read
PCI DSS Compliance Checklist: All 12 Requirements Explained

PCI DSS Compliance Checklist: All 12 Requirements Explained

Any organization that stores, processes, or transmits cardholder data must comply with the Payment Card Industry Data Security Standard (PCI DSS), regardless of size or transaction volume. The current version is PCI DSS v4.0.1, published by the PCI Security Standards Council (PCI SSC). Version 3.2.1 was retired on March 31, 2024; full compliance with v4.0 has been required since March 31, 2025.

This checklist breaks down all 12 requirements into actionable items. Use it alongside your formal gap assessment, not as a substitute for it.

TL;DR

  • PCI DSS v4.0.1 is the current version; compliance has been mandatory since March 31, 2025.
  • The standard's 12 requirements cover network security, access controls, encryption, monitoring, testing, and governance.
  • Your merchant level (1 through 4) determines whether you need a QSA on-site audit or can self-assess using a Self-Assessment Questionnaire (SAQ).
  • Level 1 merchants (over 6 million Visa or Mastercard transactions per year) require an annual on-site assessment by a Qualified Security Assessor (QSA).
  • Selecting the right SAQ type matters: using the wrong form can leave real gaps unassessed.

Who This Is For

Illustration related to Who This Is For
Photo by RDNE Stock project

This guide is written for IT and security teams at organizations that accept card payments, for compliance officers preparing for a PCI DSS assessment, and for service providers scoping their cardholder data environment. If you are a small e-commerce merchant completing your first SAQ, focus on requirements 3, 4, 6, and 8 first, they address the most common gaps in simpler environments.

In practice, organizations new to PCI DSS most often underestimate two areas: the breadth of their cardholder data environment (CDE) scope, and the documentation burden Requirement 12 imposes. Teams that run a scoping exercise before the gap assessment consistently find systems they did not know were in scope. Starting with a network diagram (Requirement 1) and a data flow map (Requirement 3) before touching any other checklist item tends to produce a more accurate scope and a shorter remediation list.

Merchant Levels and What They Require

Before working through the checklist, confirm your merchant level. Levels are set by individual card brands based on annual transaction volume and can differ between brands.

Visa merchant levels:

  • Level 1: More than 6 million Visa transactions per year, or any merchant that Visa determines should be Level 1 after a breach. Requires an annual on-site QSA assessment and a Report on Compliance (ROC).
  • Level 2: 1 million to 6 million transactions per year. Annual SAQ completed by a qualified internal security assessor; quarterly ASV scans.
  • Level 3: 20,000 to 1 million e-commerce transactions per year. Annual SAQ; quarterly ASV scans.
  • Level 4: Fewer than 20,000 e-commerce transactions or up to 1 million other transactions per year. Annual SAQ recommended; quarterly ASV scans.

Mastercard uses the same four-tier structure with equivalent thresholds. Always confirm your level with your acquiring bank, which is the enforcement point for compliance validation.

The 12 Requirements: Checklist

The PCI DSS v4.0.1 standard organizes its requirements into six goals. Each goal contains two requirements, for 12 total.

Goal 1: Build and Maintain a Secure Network

Requirement 1: Install and Maintain Network Security Controls

Network security controls (NSCs) form the boundary around your cardholder data environment (CDE). PCI DSS v4.0 expanded the scope of this requirement beyond traditional firewalls to include cloud security groups and software-defined networking.

  • Document all network connections into and out of the CDE
  • Create and maintain accurate network diagrams showing all cardholder data flows
  • Configure NSC rulesets to deny all traffic except what is explicitly required
  • Review NSC rulesets at least every six months (increased frequency from annually in v3.2.1)
  • Restrict inbound and outbound traffic at the individual system component level
  • Assign documented ownership and responsibilities for NSC management

Requirement 2: Apply Secure Configurations to All System Components

Default credentials and configurations are publicly known. Every system component entering the CDE must be hardened before deployment.

  • Remove or disable all vendor-supplied default accounts before connecting a system to the network
  • Change all default passwords prior to deployment
  • Develop and maintain configuration standards for each system type (servers, databases, network devices, applications)
  • Encrypt all non-console administrative access using strong cryptography
  • Maintain an inventory of all in-scope system components, updated when components change
  • Assign only one primary function per server where technically feasible

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data

The most effective way to reduce PCI DSS scope is to avoid storing cardholder data. If storage is necessary, the following controls apply.

  • Define and enforce data retention and disposal policies with specific retention periods
  • Do not store sensitive authentication data (SAD) after authorization, including full track data, CVV/CVC, and PINs
  • When displaying a primary account number (PAN), mask it to show no more than the first six and last four digits
  • Render stored PANs unreadable using strong one-way hashing, truncation, index tokens, or strong cryptography
  • Document key management procedures covering key generation, distribution, storage, retirement, and destruction
  • Rotate encryption keys at the end of their defined cryptoperiod or upon evidence that key integrity is compromised

Storing CVV/CVC codes after transaction authorization is a direct PCI DSS violation, regardless of how the data is encrypted. Any system retaining this data requires immediate remediation.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Card data sent over open or public networks is vulnerable to interception. Strong cryptographic protocols must be used for any transmission.

  • Use TLS 1.2 or higher for all transmissions of cardholder data over public networks (TLS 1.0 and 1.1 are prohibited)
  • Confirm that certificates used are valid, current, and issued by a trusted certificate authority
  • Verify that only trusted keys and certificates are accepted
  • Do not transmit unprotected PANs via end-user messaging technologies such as email, SMS, or chat
  • Maintain an inventory of all trusted keys and certificates, including expiration dates

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

Anti-malware controls must be applied to all systems that are commonly targeted by malicious software within the CDE.

  • Deploy anti-malware on all systems commonly affected by malware
  • Configure anti-malware mechanisms to update automatically
  • Enable real-time monitoring and perform periodic scans on covered systems
  • Retain anti-malware logs and protect them from unauthorized modification
  • Implement anti-phishing mechanisms to detect and protect against phishing attacks (added in PCI DSS v4.0)
  • Conduct periodic risk evaluations for systems not commonly affected by malware to confirm they remain low risk

Requirement 6: Develop and Maintain Secure Systems and Software

Software vulnerabilities are among the most common entry points for attackers. PCI DSS requires both a patching process and secure development practices.

  • Install critical security patches within one month of release
  • Establish a vulnerability management process that ranks vulnerabilities by risk
  • Develop all custom software following secure coding guidelines, referencing the OWASP Top 10
  • Protect public-facing web applications against known attacks through a web application firewall (WAF) or documented code review
  • Manage all scripts loaded in the consumer's browser on payment pages: maintain an authorized inventory, verify integrity via subresource integrity (SRI) hashes or equivalent, and justify each script's presence (Requirement 6.4.3, added in PCI DSS v4.0)
  • Maintain an inventory of all bespoke and third-party software components and their versions

Requirement 6.4.3 was one of the most operationally demanding additions in v4.0. Many organizations had never systematically inventoried JavaScript loaded on their checkout pages. Start by auditing every