PCI DSS compliance requires any business that stores, processes, or transmits payment card data to meet 12 security requirements across six control objectives, validated through either a Self-Assessment Questionnaire (SAQ) or a formal Report on Compliance (ROC) depending on your transaction volume. PCI DSS v4.0 became mandatory on March 31, 2024, when v3.2.1 was officially retired, and as of March 31, 2025, all 51 future-dated requirements introduced in v4.0 are now fully enforceable. The 12 requirements cover everything from firewall configuration and cardholder data encryption to multi-factor authentication, vulnerability scanning, and physical access controls.

Most businesses treat PCI DSS compliance like a box-ticking exercise. They get through the audit, file the paperwork, and go quiet for another year. That’s a mistake. PCI DSS compliance is a continuous security posture, not an annual event. This guide cuts through the noise and gives you the exact checklist you need to pass your next audit and actually protect the cardholder data you’re responsible for.

What Is PCI DSS Compliance and Who Does It Apply To?

PCI DSS compliance is a mandatory security standard that applies to every organization worldwide that accepts, processes, stores, or transmits payment card data, regardless of size or transaction volume.

The standard was created by the PCI Security Standards Council, a body founded by Visa, Mastercard, American Express, Discover, and JCB. No card brand exempts small businesses. If you take card payments, you’re in scope. Full stop.

The cardholder data environment, or CDE, is the heart of PCI DSS. The CDE includes all systems, people, and processes that store, process, or transmit cardholder data or sensitive authentication data. Getting your CDE scope right is the single most important step before you start any compliance work. Scope creep is one of the most common reasons businesses fail audits.

Cardholder data includes the primary account number (PAN), cardholder name, expiration date, and service code. Sensitive authentication data adds full magnetic stripe data, CVV/CVC codes, and PINs. You cannot store sensitive authentication data after authorization, under any circumstances.

Key definition: The cardholder data environment (CDE) is any system component, person, or process that stores, processes, or transmits cardholder data or sensitive authentication data, plus any connected or potentially impacting component.

According to the Verizon 2024 Payment Security Report, PCI DSS has seen 11 updates from 2004 to 2024. The standard keeps pace with how attackers operate. Your compliance program needs to do the same.

PCI DSS Compliance Levels: Which One Applies to Your Business?

PCI DSS compliance levels are determined by annual transaction volume, with Level 1 requiring the most rigorous validation and Level 4 applying to businesses processing fewer than 20,000 e-commerce transactions annually.

The level you fall into dictates what validation documentation you need. Get this wrong and you’ll either over-invest in compliance work you don’t need, or under-invest and fail your audit.

Level 1 merchants must work with a Qualified Security Assessor (QSA) who produces the ROC. Levels 2 through 4 typically complete a Self-Assessment Questionnaire. There are multiple SAQ types (SAQ A, B, C, D, and others) depending on your payment environment. Your acquiring bank can confirm which one applies to you.

Quarterly vulnerability scans from an Approved Scanning Vendor (ASV) are required across all levels that process card-not-present transactions. Don’t skip them. Failing an ASV scan is a compliance gap that auditors will flag immediately.

The PCI DSS Compliance Checklist: All 12 Requirements

The PCI DSS compliance checklist is built on 12 requirements organized across six control objectives, each addressing a distinct security domain from network security to information security policy.

According to Linford & Company’s PCI DSS v4.0 requirements guide, PCI DSS v4.0 introduced 64 new requirements compared to v3.2.1. That’s a significant expansion. Many of those additions target authentication controls, targeted risk analysis, and web-based attack protections. If you haven’t updated your internal PCI DSS compliance checklist since before 2024, you’re working from an outdated map.

The six control objectives and their associated requirements are:

1. Build and Maintain a Secure Network: Requirements 1 and 2
2. Protect Cardholder Data: Requirements 3 and 4
3. Maintain a Vulnerability Management Program: Requirements 5 and 6
4. Implement Strong Access Control Measures: Requirements 7, 8, and 9
5. Regularly Monitor and Test Networks: Requirements 10 and 11
6. Maintain an Information Security Policy: Requirement 12

Each requirement below includes the key PCI DSS compliance checklist actions you need to implement. Treat them as checkboxes, not suggestions.

Requirements 1 and 2: Build and Maintain a Secure Network

PCI DSS Requirements 1 and 2 demand that every organization install and maintain network security controls, and eliminate all vendor-supplied default passwords and unnecessary default settings before connecting any system to the cardholder data environment.

Requirement 1: Network Security Controls and Firewall Configuration

A properly configured firewall is your first line of defense for the CDE. Not a checkbox. A working, actively managed control.

Your PCI DSS compliance checklist for Requirement 1 should include:

• Document all network security controls, including firewalls, routers, and cloud-based equivalents
• Maintain a current network diagram showing all cardholder data flows and CDE boundaries
• Configure firewall rules to deny all traffic not explicitly required for business operations
• Restrict inbound and outbound traffic to only what is needed within the CDE
• Review firewall and router rule sets at least every six months
• Prohibit direct public access between the internet and any CDE system component

PCI DSS v4.0 expanded Requirement 1 to cover all “network security controls,” not just firewalls. Cloud environments, software-defined networking, and virtual firewalls all fall under this scope now.

Requirement 2: Default Password Changes and Secure Configurations

Default vendor passwords are a known attack vector. Credential abuse accounted for 22% of confirmed breaches according to Verizon’s 2025 Data Breach Investigations Report. Leaving default credentials in place is handing attackers the keys.

Your checklist for Requirement 2:

• Change all vendor-supplied default passwords before deploying any system into the CDE
• Develop and maintain a configuration standard for all system components based on industry-hardening guidelines
• Disable or remove all unnecessary services, protocols, and functions
• Document all system components in scope and maintain an up-to-date inventory
• Protect non-console administrative access with encryption

Requirements 3 and 4: Protect Cardholder Data

PCI DSS Requirements 3 and 4 require organizations to protect stored cardholder data using strong encryption and rendering techniques, and to encrypt all cardholder data transmitted across open, public networks using current security protocols.

Requirement 3: Stored Cardholder Data Protection

Most businesses shouldn’t be storing cardholder data at all. If you don’t need it, don’t keep it. If you do need it, encrypt it properly and limit retention to what’s operationally necessary.

PCI DSS compliance checklist actions for stored cardholder data:

• Define a data retention policy and delete cardholder data when no longer needed
• Never store sensitive authentication data (CVV, full magnetic stripe, PIN) after authorization
• Mask the PAN when displayed so only the last four digits are visible
• Render the PAN unreadable using strong one-way hashing, truncation, tokenization, or encryption
• Protect encryption keys with documented key management procedures
• Restrict access to cryptographic keys to the fewest number of custodians necessary

Tokenization is worth considering seriously. If your payment processor supports it, replacing the PAN with a token in your systems removes that data from your CDE scope entirely. Less scope means less compliance burden.

Requirement 4: Cardholder Data Encryption in Transit

Any cardholder data crossing an open, public network must be encrypted. Full stop. TLS 1.2 is the accepted minimum, and TLS 1.3 is the recommended standard for new implementations.

Your encryption in transit checklist:

• Use strong cryptography (TLS 1.2 or higher) for all cardholder data transmitted over open networks
• Reject any connection that does not use a trusted certificate or offer the correct encryption strength
• Never send unprotected PANs by email, messaging, or any end-user messaging technology
• Maintain an inventory of trusted keys and certificates

SSL and early TLS versions are not acceptable under PCI DSS v4.0. If any system in your CDE still uses them, that’s a finding your QSA will flag on day one.

Requirements 5 and 6: Vulnerability Management Program

PCI DSS Requirements 5 and 6 require organizations to protect all system components against malware using anti-malware solutions, and to develop and maintain secure systems and software by managing vulnerabilities and applying security patches within defined timeframes.

Requirement 5: Anti-Malware Protection

Anti-malware isn’t just antivirus software installed and forgotten. PCI DSS v4.0 requires active, up-to-date protection with regular scans and mechanisms to detect and respond to threats.

Requirement 5 checklist:

• Deploy anti-malware solutions on all system components at risk from malware, particularly Windows and Linux environments
• Ensure anti-malware solutions are kept current and perform scans at least periodically
• Enable anti-malware audit logging and retain logs per Requirement 10
• Conduct a targeted risk analysis for any system components assessed as not at risk from malware, and document the evaluation

Requirement 6: Secure Systems and Vulnerability Management

Exploitation of vulnerabilities accounted for 20% of confirmed breaches, per Verizon’s 2025 DBIR. Patching is not optional. Slow patching is a breach waiting to happen.

Requirement 6 checklist:

• Establish a process to identify, rank, and address security vulnerabilities in a timely manner
• Apply critical security patches within one month of release
• Develop all internal software using secure coding practices
• Address common vulnerabilities such as OWASP Top 10 in all web-facing applications
• Protect public-facing web applications against known attacks using a web application firewall (WAF) or automated vulnerability assessment tool
• PCI DSS v4.0 added a specific requirement (6.4.3) for managing all payment page scripts loaded in the browser, with authorization and integrity checking

The payment page script requirement under PCI DSS v4.0 caught many e-commerce businesses off guard. If your checkout page loads any third-party scripts, you need to inventory them, authorize each one, and verify their integrity. This was one of the most significant new additions in the updated standard.

Requirements 7, 8, and 9: Strong Access Control Measures

PCI DSS Requirements 7, 8, and 9 require organizations to restrict access to cardholder data by business need, assign a unique ID to every user with computer access, and control physical access to systems within the cardholder data environment.

Requirement 7: Least Privilege Access Control

The least privilege principle means users only get access to what they need to do their specific job. Not what’s convenient. Not what their predecessor had. What they need.

Requirement 7 checklist:

• Define access control policy based on business need to know
• Restrict access to system components and cardholder data to individuals whose job requires it
• Assign access based on job classification and function
• Review user access rights at least every six months and adjust based on role changes

Requirement 8: Unique User IDs and Multi-Factor Authentication

PCI DSS v4.0 mandated multi-factor authentication (MFA) under Requirement 8.4.2 for all non-console administrative access into the CDE, closing a significant gap that existed in earlier versions of the standard.

Requirement 8 is where a lot of businesses fall short. Shared accounts, weak passwords, no MFA. These aren’t edge cases. They’re common.

Requirement 8 checklist:

• Assign a unique user ID to every individual with access to the CDE. No shared accounts.
• Enforce strong password requirements: minimum 12 characters for new implementations, complexity requirements, no reuse of the last four passwords
• Implement MFA for all non-console access into the CDE
• Implement MFA for all remote network access originating from outside the entity’s network
• Disable or remove inactive user accounts within 90 days
• Immediately revoke access for terminated employees
• Lock out user accounts after a maximum of 10 failed authentication attempts
• Do not use group, shared, or generic IDs for system administration

MFA is one of the most impactful single controls you can implement. Phishing accounted for 16% of breach initial attack vectors according to IBM’s 2025 Cost of a Data Breach Report analysis. MFA doesn’t stop phishing, but it significantly limits what an attacker can do with stolen credentials.

Requirement 9: Physical Access Controls

Physical security is often overlooked in the rush to address technical controls. But physical access to a server is game over for any software-based protection.

Requirement 9 checklist:

• Restrict physical access to CDE systems using badge access, security cameras, or equivalent controls
• Maintain an audit log of physical access to sensitive areas
• Use a visitor management process for all individuals accessing areas where cardholder data is present
• Secure all media containing cardholder data and maintain strict control over its distribution
• Destroy media when no longer needed using methods that make cardholder data unrecoverable
• Protect point-of-interaction (POI) devices from tampering and substitution

Requirements 10 and 11: Monitor and Test Your Networks

PCI DSS Requirements 10 and 11 require organizations to log and monitor all access to network resources and cardholder data, and to regularly test the security of systems and networks through vulnerability scanning and penetration testing.

Requirement 10: Audit Logging and Network Monitoring

If you don’t have logs, you can’t detect a breach. And if you can’t detect a breach, you’ll find out about it when your bank calls you. That’s not a position you want to be in.

Requirement 10 checklist:

• Implement audit logging for all individual user access to cardholder data
• Log all actions taken by root or administrator accounts
• Log access to all audit trails
• Log invalid logical access attempts
• Log use of and changes to identification and authentication mechanisms
• Retain audit log history for at least 12 months, with at least three months immediately available for analysis
• Protect audit logs from modification and unauthorized deletion
• Use automated monitoring tools to review logs daily and alert on anomalies

A SIEM (Security Information and Event Management) tool is the practical way to meet the daily log review requirement without burying your team in manual work. Splunk and IBM QRadar are common enterprise choices. Smaller environments often use LogRhythm or cloud-native options.

Requirement 11: Vulnerability Scanning and Penetration Testing

Vulnerability scanning and penetration testing serve different purposes. Scanning finds known weaknesses. Penetration testing proves whether a skilled attacker can actually exploit them. You need both.

Requirement 11 checklist:

• Run quarterly internal vulnerability scans and remediate identified vulnerabilities
• Run quarterly external vulnerability scans through an Approved Scanning Vendor (ASV) and achieve passing status
• Conduct internal penetration testing at least annually and after any significant infrastructure change
• Conduct external penetration testing at least annually
• Verify network segmentation controls through penetration testing at least annually and after changes
• Use a penetration testing methodology that covers the OWASP Top 10 and CDE-specific attack scenarios
• Remediate penetration testing findings and verify remediation through retesting

Quarterly ASV scans are non-negotiable for external-facing systems. Failing a scan and not addressing findings before your compliance window closes is one of the most avoidable audit failures. Book your scans early. Don’t leave them to the last month of your compliance year.

Requirement 12: Information Security Policy and Staff Training

PCI DSS Requirement 12 requires organizations to maintain an information security policy for all personnel and to support it with ongoing security awareness training, third-party vendor management, and a documented incident response plan.

Policies without enforcement are theatre. Requirement 12 is the governance layer that makes all the other 11 requirements stick.

Requirement 12 checklist:

• Establish, publish, and maintain a formal information security policy covering all PCI DSS requirements
• Review the security policy at least annually and update when the environment changes
• Conduct security awareness training for all personnel upon hire and at least annually thereafter
• Train staff to recognize social engineering, phishing, and other common attack techniques
• Maintain a list of all third-party service providers with access to cardholder data or the CDE
• Obtain written acknowledgment from service providers that they are responsible for cardholder data security within their scope
• Develop and maintain an incident response plan covering roles, responsibilities, communication procedures, and containment steps
• Test the incident response plan at least annually
• Conduct a targeted risk analysis for all requirements that allow entity-defined frequency under PCI DSS v4.0’s customized approach

Vendor management is a gap that auditors probe hard. If a third-party service provider handles cardholder data on your behalf and they’re not PCI DSS compliant, that’s your problem too. Verify their compliance status annually. Get it in writing.

PCI DSS v4.0 Updates You Cannot Afford to Miss

PCI DSS v4.0, released in March 2022 and made mandatory in March 2024, introduced 64 new requirements and a significant shift toward continuous compliance over point-in-time validation.

The update was the most significant revision to the standard in over a decade, according to the PCI Security Standards Council’s v4.0.1 blog post. PCI DSS v4.0.1, a clarifying revision, was then published on June 11, 2024, per Fortra’s v4.0.1 readiness guide.

The most impactful v4.0 changes for most businesses:

• MFA expanded: Required for all non-console CDE access, not just remote access
• Password length increased: Minimum 12 characters for new implementations
• Payment page scripts: All scripts on checkout pages must be inventoried, authorized, and integrity-checked (Requirement 6.4.3)
• Targeted risk analysis: Entities must perform documented risk analysis to justify the frequency of many controls
• Customized approach: Entities can now design their own controls to meet security objectives, subject to QSA validation
• E-commerce protections: New requirements for detecting and preventing e-skimming attacks on payment pages

The 51 future-dated requirements that were optional during the transition period became fully mandatory on March 31, 2025, per SecureTrust’s PCI DSS v4.0 requirements overview. If your compliance program was deferred to “future-dated” status on any of those controls, that grace period is gone.

The financial stakes are real. The IBM Cost of a Data Breach Report puts the global average cost of a data breach at $4.44 million. For U.S. organizations, that figure climbs to $10.22 million according to CNIC Solutions’ breach cost analysis. Non-compliance fines, card brand penalties, and breach remediation costs on top of that make a strong PCI DSS compliance program one of the highest-return investments a business can make.

Want to build a stronger security foundation alongside your PCI DSS compliance work? Understanding your overall cyber risk profile is the right place to start. PCI DSS covers cardholder data, but your broader attack surface needs attention too.

Maintaining PCI DSS Compliance After Your Audit

PCI DSS compliance is not a one-time project, it is a continuous operational discipline requiring quarterly scans, annual assessments, ongoing monitoring, and documented evidence of every control operating as designed.

Plenty of businesses pass their initial audit and then let things drift. New systems get added to the CDE without going through change control. Firewall rules accumulate without review. User accounts for former employees stay active. These aren’t hypothetical scenarios. They’re the findings that show up in breach post-mortems.

Build these activities into your operational calendar:

• Quarterly: ASV external vulnerability scans, internal vulnerability scans, user access reviews for privileged accounts, firewall rule review
• Annually: Full PCI DSS compliance assessment (SAQ or ROC), penetration testing (internal and external), security awareness training for all staff, incident response plan test, third-party service provider review, security policy review
• Ongoing: Daily log review, patch management within defined SLAs, change control for any CDE modification, cardholder data discovery scans

Document everything. Auditors don’t just want to see controls in place. They want evidence those controls have been operating throughout the assessment period. A firewall policy that was configured last week doesn’t satisfy an annual control requirement. Evidence gaps are compliance gaps.

If you’re unsure where your current PCI DSS compliance program has gaps, a PCI DSS gap assessment gives you a clear picture before your QSA does. It’s far cheaper to fix gaps proactively than to remediate them under audit pressure.

PCI DSS compliance protects your customers, your business, and your reputation. Treat it that way. Secure your systems. Train your people. And don’t wait for the auditor to tell you what you already know needs fixing.

Need help building a PCI DSS compliance program that actually works for your business? Get in touch with the RiskAware team and we’ll give you a straight assessment of where you stand.