PCI DSS Compliance Checklist: All 12 Requirements (v4.0.1)

Photo: Unsplash

PCI DSS applies to every organization that stores, processes, or transmits cardholder data, or that can affect its security. Version 4.0.1 is the current standard, and the requirements that were future-dated in v4.0 became mandatory on March 31, 2025. This checklist walks through scoping, the 12 PCI DSS requirements, and the annual validation steps, with the v4 changes that most often catch teams out.

Key takeaways

• Scope first. Every later cost and control depends on how big your cardholder data environment (CDE) is.
• There are 12 requirements grouped into six goals, with several hundred sub-requirements beneath them.
• v4.0.1 added real work, including MFA for all access into the CDE, stronger passwords, payment page script controls, and targeted risk analyses.
• Validation is annual. You complete a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC), plus quarterly ASV scans and the attestation your acquirer asks for.
• Compliance is continuous. Many controls, such as log review, scanning, and access reviews, have daily, quarterly, or periodic frequencies.

Step 1: Scope your cardholder data environment

• List every payment channel: e-commerce, mobile, card-present, phone, and recurring billing
• Identify where cardholder data is stored, processed, or transmitted, including logs and backups
• Draw a data flow diagram showing how card data moves through your systems and third parties
• Draw a network diagram showing the CDE and every connection to it
• Identify systems connected to or able to affect the security of the CDE, which are also in scope
• Remove card data you do not need, and replace stored card numbers with processor tokens where possible
• Confirm segmentation controls that keep out-of-scope systems out, and plan to test them
• List third-party service providers that handle card data, and collect their PCI DSS attestations (AOCs)
• Confirm your merchant or service provider level with your acquirer, and which SAQ or ROC applies
• Document the scope and confirm it at least once every 12 months (every six months for service providers)

Step 2: Work through the 12 requirements

Build and maintain a secure network and systems

Requirement 1: Install and maintain network security controls

• Firewall, security group, and network ACL rules documented, justified, and reviewed at least every six months
• Inbound and outbound traffic to the CDE restricted to what is necessary
• Untrusted networks, including wireless, separated from the CDE

Requirement 2: Apply secure configurations to all system components

• Vendor default accounts and passwords changed or disabled
• Configuration standards defined for each system type, based on industry hardening guidance
• Only necessary services, protocols, and functions enabled

Protect account data

Requirement 3: Protect stored account data

• Data retention and disposal policy that keeps stored card data to the minimum
• Sensitive authentication data (full track, CVV, PIN) never stored after authorization
• Primary account numbers (PAN) masked when displayed and unreadable wherever stored
• Cryptographic keys protected and managed through their full life cycle

Requirement 4: Protect cardholder data with strong cryptography during transmission

• Strong cryptography for PAN sent over open, public networks
• Certificates valid and inventoried
• PAN never sent over end-user messaging such as email or chat without protection

Maintain a vulnerability management program

Requirement 5: Protect all systems and networks from malicious software

• Anti-malware deployed on systems at risk, kept current, and actively running
• Periodic evaluation of systems considered not at risk
• Anti-phishing mechanisms in place to protect personnel (new in v4)

Requirement 6: Develop and maintain secure systems and software

• Secure development practices and developer training for bespoke and custom software
• Vulnerabilities identified, ranked, and patched within defined timeframes
• Public-facing web applications protected by an automated technical solution such as a WAF
• Inventory, authorization, and integrity checks for all scripts on payment pages (new in v4)
• Change control for all changes to system components

Implement strong access control measures

Requirement 7: Restrict access by business need to know

• Access based on job role and least privilege
• User accounts and privileges reviewed at least every six months

Requirement 8: Identify users and authenticate access

• Unique IDs for every user, with shared accounts only by exception
• Passwords at least 12 characters (or 8 if the system cannot support 12)
• MFA for all non-console administrative access and for all access into the CDE (expanded in v4)
• MFA for all remote network access
• System and application accounts managed, with passwords not hardcoded

Requirement 9: Restrict physical access to cardholder data

• Physical access controls for facilities and media with card data
• Point-of-interaction devices inventoried and periodically inspected for tampering
• Media securely stored and destroyed when no longer needed

Regularly monitor and test networks

Requirement 10: Log and monitor all access

• Audit logs enabled for all system components and access to card data
• Logs protected from modification and retained for at least 12 months, with three months immediately available
• Automated mechanisms to review logs (required in v4)
• Time synchronized across systems
• Failures of critical security controls detected and responded to promptly

Requirement 11: Test security of systems and networks regularly

• Internal and external vulnerability scans at least quarterly and after significant changes
• Internal scans authenticated (new in v4)
• External scans by a PCI SSC Approved Scanning Vendor (ASV) with passing results
• Penetration testing at least annually and after significant changes, including segmentation testing
• Intrusion detection or prevention on the CDE perimeter and critical points
• Change and tamper detection for payment pages (new in v4)

Maintain an information security policy

Requirement 12: Support information security with organizational policies and programs

• Information security policy reviewed at least annually
• Targeted risk analyses for requirements that allow flexible frequencies (new in v4)
• Security awareness training at hire and at least annually, including phishing and social engineering
• Personnel screening where appropriate
• Third-party service provider management, with written agreements and annual monitoring of their compliance
• Incident response plan tested at least annually

Step 3: Validate and report

• Complete the SAQ that matches your payment channels, or engage a QSA for a Report on Compliance
• Obtain four passing quarterly ASV scans
• Complete your penetration test and segmentation test
• Sign the Attestation of Compliance (AOC)
• Submit the SAQ or ROC, AOC, and scan reports as your acquirer or customers require
• Put ongoing tasks on a calendar: log review, quarterly scans, six-month rule and access reviews, annual training and risk analyses

Common PCI DSS mistakes

• Underestimating scope. Logs, backups, support tools, and connected systems are often missed.
• Choosing the wrong SAQ. Using SAQ A while your site still loads payment scripts you control can leave you non-compliant.
• Treating compliance as annual. Many controls have daily, quarterly, or six-month frequencies that assessors check.
• Skipping segmentation testing. Segmentation that is not tested does not reduce scope.
• Missing v4 requirements. Payment page script management and expanded MFA are common gaps.

To plan the budget, see PCI DSS certification cost.

How SecureSlate helps

SecureSlate's PCI DSS program combines compliance software with a dedicated compliance lead for one fixed price:

• Your compliance lead scopes your cardholder data environment and finds ways to reduce it.
• They prepare your SAQ or support your Report on Compliance, and close the gaps before the assessment.
• The platform maps controls to PCI DSS v4.0.1 and collects evidence continuously from your cloud, identity provider, code host, and devices.
• Security scanning evidences vulnerability management and secure development, and controls shared with SOC 2 or ISO 27001 are reused.

FAQ

What are the 12 requirements of PCI DSS?

They are: network security controls, secure configurations, protecting stored account data, protecting data in transmission, anti-malware, secure systems and software, need-to-know access, user identification and authentication, physical access, logging and monitoring, regular security testing, and organizational security policies and programs.

What changed in PCI DSS v4.0?

Key changes include MFA for all access into the cardholder data environment, 12-character minimum passwords, anti-phishing controls, management of scripts on payment pages, authenticated internal scanning, automated log review, and targeted risk analyses. Those future-dated requirements became mandatory on March 31, 2025.

Which PCI SAQ do I need?

It depends on how you accept payments. SAQ A applies to e-commerce merchants that fully outsource card capture, SAQ A-EP to e-commerce sites that affect the payment page, SAQ B and B-IP to standalone terminals, SAQ C and C-VT to payment applications and virtual terminals, SAQ P2PE to validated point-to-point encryption, and SAQ D to everyone else, including service providers.

How often is PCI DSS compliance validated?

Annually, through an SAQ or Report on Compliance and an Attestation of Compliance. External ASV scans are required quarterly, and penetration tests at least annually and after significant changes.

Is PCI DSS required by law?

No. PCI DSS is a contractual requirement from the card brands, enforced through your acquiring bank or payment processor. Some state laws reference it, and breaches involving card data can still trigger legal obligations.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. It summarizes PCI DSS and does not replace the standard. Refer to the official PCI DSS documentation and your acquirer for your specific obligations.