PCI DSS Compliance Checklist

Payment environments do not fail PCI DSS because teams missed a single checkbox. They fail because cardholder data spread farther than expected, legacy settings stayed in place too long, and security controls were documented annually but managed inconsistently in practice.

That is why a PCI DSS compliance checklist still matters. For organizations that store, process, or transmit payment card data, PCI DSS is one of the most operationally demanding security standards in common use. It is also one of the clearest. The standard gives organizations a defined structure for protecting account data, reducing attack paths, and proving that required controls are actually working. The current framework, PCI DSS v4.0.1, remains organized around 12 principal requirements and a more continuous approach to security validation than older point-in-time models encouraged. The older PCI DSS v3.2.1 retired on March 31, 2024, making v4.0 the mandatory baseline, with v4.0.1 serving as the current minor revision of the standard. PCI DSS v4 also introduced a Customized Approach option that allows organizations to meet certain security objectives through alternative controls when supported by documented risk analysis, testing, and evidence that the objective is achieved. A PCI Security Standards Council overview and Verizon’s 2024 Payment Security Report both reflect that shift toward ongoing effectiveness and measurable control performance.

Contents

• What is PCI DSS?
• PCI DSS Compliance Levels
• The 12 PCI DSS Requirements
• PCI DSS Compliance Checklist
• Common PCI DSS Failure Points
• PCI DSS and Prescient Security
• Conclusion

What is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It applies to any entity that stores, processes, or transmits cardholder data, as well as organizations whose systems can impact the security of that data environment. In plain terms, if your business touches payment card data directly or operates infrastructure that supports those transactions, PCI DSS is in scope.

The standard was developed by the major payment card brands through the PCI Security Standards Council to create a common security baseline for payment environments. Its purpose is straightforward: protect cardholder data and reduce the likelihood that weak systems, poor segmentation, exposed credentials, or unpatched software turn into payment data compromise.

That scope point matters more than many teams realize. PCI DSS is not limited to a payment application or a checkout page. It extends to the broader cardholder data environment, often shortened to CDE, including connected systems that can affect its security. That is one reason scoping errors remain one of the most common sources of compliance pain.

PCI DSS Compliance Levels

PCI DSS validation obligations are commonly grouped into merchant and service provider levels, though the exact reporting requirements are set by payment brands and acquiring banks rather than by the PCI SSC alone.

For merchants, Level 1 generally applies to entities processing more than 6 million Visa or Mastercard transactions annually, or to organizations designated Level 1 because of elevated risk. These organizations generally require an annual assessment by a Qualified Security Assessor and a formal Report on Compliance.

Levels 2 through 4 usually cover lower transaction volumes. Depending on the card brand and acquirer, those organizations may be allowed to validate through a Self-Assessment Questionnaire, commonly called an SAQ, plus quarterly external vulnerability scans by an Approved Scanning Vendor where applicable. The PCI SSC notes that SAQs are only for SAQ-eligible environments, and merchants must meet all eligibility criteria for the specific SAQ they use. The Council’s SAQ guidance and FAQs make that explicit.

Service providers follow a similar tiered structure, but with stricter expectations. The PCI SSC also makes clear that service providers cannot use merchant SAQs to reduce applicable requirements. For service providers, SAQ D for Service Providers is the relevant self-assessment path where self-assessment is permitted, and many larger providers undergo formal assessor-led validation instead.

The 12 PCI DSS Requirements

PCI DSS is built around six broader control objectives that are supported by 12 principal requirements. Below are the six broader control objectives.

1. Build and maintain a secure network and systems

This section includes installing and maintaining network security controls, along with applying secure configurations to all system components. In practice, this covers firewalls, router rules, segmentation controls, hardened baselines, and elimination of insecure defaults.

2. Protect account data

Organizations must protect stored account data and encrypt cardholder data during transmission over open, public networks. This includes data retention discipline, key management, masking, truncation, and strong cryptography.

3. Maintain a vulnerability management program

Systems handling or affecting cardholder data must be protected from malware and kept secure through timely patching and secure software development practices. The requirement is broader than antivirus alone. It also includes identifying vulnerabilities, remediating them, and addressing insecure code and exploitable flaws in applications.

4. Maintain a vulnerability management program

Access to system components and cardholder data must be restricted by business need to know. Users need unique IDs, strong authentication, and controlled physical access to sensitive systems and media.

5. Regularly monitor and test networks 

Logs, audit trails, file integrity mechanisms where applicable, vulnerability scans, penetration testing, and continuous validation all sit here. This is where organizations prove that controls are not merely designed, but operating effectively.

6. Maintain an information security policy

PCI DSS requires security governance, documented policies, risk awareness, incident response planning, and role-based accountability. Security has to be formalized, communicated, and maintained.

PCI DSS Compliance Checklist

A useful checklist is a great way to test whether your environment is actually ready for assessment.

Install and maintain network security controls

Review all firewalls, security groups, ACLs, and segmentation rules that separate the CDE from the rest of the environment. Document every inbound and outbound connection. Remove obsolete rules. Validate that segmentation works in practice, not just on a network diagram.

Change default vendor settings

Default passwords, default SNMP strings, unnecessary services, and out-of-box system configurations remain low-effort attack paths. Every in-scope system should be hardened against a documented secure baseline.

Protect stored cardholder data

Map where account data is stored, even temporarily. Then reduce it. Many organizations discover that old databases, logs, support tools, or exports have expanded the CDE more than intended. If storage is necessary, apply masking, truncation, retention limits, and cryptographic protection.

Encrypt cardholder data in transit

Any transmission of account data over open or public networks must use strong encryption. Confirm TLS configurations, certificate management, and middleware paths. This includes APIs, payment integrations, back-end connections, and third-party handoffs.

Apply malware protection

Deploy anti-malware or equivalent protections on systems commonly affected by malicious software. Just as important, verify centralized management, signature or detection updates, alert handling, and response procedures.

Maintain system and application security

Run authenticated vulnerability scans, remediate findings by priority, and keep operating systems, applications, containers, and dependencies patched. Secure development practices matter here too. PCI DSS v4.x puts sharper emphasis on ongoing vulnerability identification and code security.

Restrict access to cardholder data

Review all roles with access to the CDE. Remove dormant accounts, limit privileged access, and enforce least privilege. Access sprawl is one of the fastest ways for a small payment environment to become a large audit problem.

Assign a unique ID to each user

Shared accounts make accountability weak and forensic analysis harder. Every user must have a unique identity, and administrative access should be strongly authenticated. Multi-factor authentication is now central to PCI DSS v4.x expectations across administrative and remote access use cases.

Restrict physical access

Physical security is often ignored in cloud-heavy environments, but it still matters for office locations, paper records, payment terminals, backup media, and data center access. Track who can physically reach systems or media containing account data.

Track and monitor access

Logging should capture user activity, privileged actions, administrative events, and security-relevant changes. Just as important, logs must be reviewed and retained appropriately. Verizon’s 2024 Payment Security Report found that full compliance among assessed organizations rose to 82.9 percent in 2023, but control gaps still persisted across key requirements, especially in operational areas where consistency breaks down over time.

Test security systems regularly

Quarterly external scans, internal vulnerability assessments, penetration testing, segmentation testing, and validation of detection controls should all be scheduled and evidenced. Testing is where many organizations discover that their documented scope and their real environment no longer match.

Maintain an information security policy

Policies should define responsibilities, acceptable use, risk management expectations, incident response, and security awareness obligations. They should also reflect how the environment actually operates. Generic policy libraries tend to create assessment friction because auditors test operational reality, not template language.

Common PCI DSS Failure Points

Most PCI DSS projects become difficult for the same reasons.

Poor scoping 

The first is poor scoping. If your team cannot clearly identify where account data resides, how it flows, and which connected systems can affect its security, the rest of the assessment becomes harder and more expensive.

Weak evidence discipline

The second is weak evidence discipline. Logs may exist, reviews may happen, and access checks may be performed, but if evidence is inconsistent, the assessment will expose that quickly.

Treating PCI as an annual event

The third is treating PCI as an annual event. Payment environments change continuously. New cloud assets, application releases, vendor integrations, and support workflows can all alter scope between assessment cycles. That is one reason Verizon’s payment security research continues to emphasize program maturity and ongoing control evaluation rather than one-time validation.

PCI DSS and Prescient Security

For organizations preparing for PCI DSS, assessor experience matters. Prescient Security’s PCI DSS assessment services cover Level 1 through Level 4 assessments, facilitated SAQs, penetration testing, PCI DSS 4.0 workshops, scope definition, and remediation support. Scoping, cardholder data environment analysis, and evidence-backed assessment are core parts of the engagement, which is exactly where many PCI programs either stabilize or start to break down.

That is especially relevant for cloud-heavy environments on AWS, Google Cloud Platform, and Microsoft Azure, where payment scope can expand through shared services, logging pipelines, CI/CD workflows, and administrative access paths faster than many teams expect.

Conclusion

PCI DSS compliance is difficult because payment environments are rarely as simple as organizations assume. A workable PCI DSS checklist starts with scope, then moves to hardening, encryption, access control, logging, testing, and policy discipline. The organizations that perform well are usually the ones that reduce stored cardholder data, define their CDE tightly, collect evidence continuously, and treat PCI DSS as an operating model instead of a yearly paperwork exercise. That approach does more than support an audit. It makes payment security materially stronger.

Learn how you can leverage PCI DSS for your organization today