PCI DSS compliance checklist: What businesses need to know

Setting up a payment form takes an afternoon. Securing the cardholder data behind it is the hard part.

The most common misconception is that PCI DSS compliance is a big-company problem. It isn’t. Any organization that stores, processes, or transmits payment card data must comply. The requirements scale, but the obligation doesn’t disappear.

This guide explains what PCI compliance means, who it applies to, and what steps get you there, starting with a practical checklist you can use to identify gaps.

What is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It’s a set of technical and operational security requirements created and maintained by the PCI Security Standards Council, founded jointly by Visa, Mastercard, American Express, Discover, and JCB.

The purpose is to reduce payment card fraud and protect cardholder data at every point it’s stored, processed, or transmitted. The standard currently sits at version 4.0, released in March 2022. Like all cybersecurity frameworks, PCI DSS evolves, and organizations are expected to maintain compliance, not just pass an assessment once.

What is PCI compliance?

PCI compliance means your environment and processes consistently meet the standard’s requirements, not just that a quarterly scan came back clean. A passing scan is a data point, not a compliance determination.

Formal validation is required annually, and external vulnerability scans must be conducted quarterly through an Approved Scanning Vendor (ASV).

Who needs to be PCI DSS compliant?

If your business handles payment card data in any capacity, you have PCI obligations. That includes:

• Retailers, both online and brick-and-mortar, running POS systems or accepting card payments through any channel.
• SaaS companies that bill customers via credit card, even when a processor handles the transaction.
• Healthcare, hospitality, professional services, and any other industry where card acceptance is incidental to the core business.
• Any organization using payment gateways, stored card data (even temporarily), or third-party integrations that interact with cardholder data.

Outsourcing payment processing reduces your scope, but it does not eliminate your compliance responsibility.

PCI DSS levels explained (Levels 1–4)

Your PCI compliance level is determined by annual transaction volume:

• Level 1: More than six million transactions per year, or any merchant that has experienced a breach. Requires an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans.
• Level 2: One million to six million transactions. Annual Self-Assessment Questionnaire (SAQ) and quarterly scans required.
• Level 3: 20,000 to one million e-commerce transactions. Annual SAQ is required.
• Level 4: Fewer than 20,000 e-commerce transactions or up to one million total transactions across all channels. Annual SAQ is required.

Transaction volume determines how you validate compliance, not how seriously you take security.

The 12 PCI DSS requirements: A high-level overview

PCI DSS is structured around 12 core requirements grouped into six themes: network security, cardholder data protection, vulnerability management, access control, monitoring and testing, and information security policy.  

The requirements are interdependent, meaning a gap in one area can undermine the rest.

PCI DSS compliance checklist

Use the following as a gap-analysis starting point.

Network and infrastructure security

• Firewalls are configured, documented, and reviewed at least every six months, not left on default settings.
• All vendor-supplied default passwords and security configurations have been changed on every system component before deployment.
• The cardholder data environment (CDE) is segmented from the rest of the network. Without segmentation, your entire infrastructure is in scope.
• Wireless access points within or connected to the CDE are inventoried, monitored, and secured.

Cardholder data protection

• Sensitive authentication data, such as full track data, CVV, and PIN blocks, are never stored after authorization. No exceptions.
• The primary account number (PAN) is masked wherever it appears. Only roles with a documented business need can view the full number.
• Stored PAN data is encrypted using accepted algorithms (AES-256 or equivalent). Data in transit is protected with TLS 1.2 or higher.
• Encryption key management follows documented procedures with separation of duties enforced. The same person doesn’t manage keys and the data they protect.

Vulnerability and patch management

• Anti-malware is deployed and actively maintained on all systems commonly targeted by malicious software—not just workstations.
• Critical security patches are applied within one month of release. Systems are reviewed for known vulnerabilities on a documented, recurring cycle.
• Quarterly vulnerability scans are conducted internally and externally. An ASV must perform external scans.
• Penetration testing is performed at least annually and after any significant infrastructure or application changes.

Access control and identity management

• Access to cardholder data is restricted to individuals with a documented business need.
• Every user has a unique ID. No shared accounts, no generic logins in systems that touch the CDE.
• Multi-factor authentication (MFA) is required for all administrative access into the CDE and for all remote network access.
• Access rights are reviewed at least every six months and revoked promptly when an employee changes roles or leaves.

Logging, monitoring, and testing

• Audit logs are enabled for all CDE system components and retained for at least 12 months, with the most recent three months immediately available for analysis.
• A centralized log management solution is in place. Logs are reviewed daily, not weekly, not when something looks wrong.
• File integrity monitoring (FIM) is deployed on critical system files, configurations, and application content.

Policies, training, and governance

• A formal information security policy exists, is reviewed annually, and is acknowledged by all personnel.
• Security awareness training is completed at hire and at least once annually. Personnel who handle cardholder data receive role-appropriate training beyond the general curriculum.
• An incident response plan specific to payment card breaches is documented, tested at least annually, and has clearly assigned ownership.
• Third-party service providers with access to cardholder data are contractually required to maintain PCI DSS compliance and are monitored on an ongoing basis.

How to become PCI DSS compliant

1. Identify your cardholder data flows. Map every point where card data enters, moves through, and exits your environment.
2. Determine your PCI level and SAQ type. Transaction volume sets your level while your payment acceptance method determines which SAQ applies. Choosing the wrong one is a common early mistake.
3. Close technical gaps. Prioritize findings that most expand your attack surface: unsegmented networks, missing MFA, gaps in logging, unpatched systems.
4. Document policies and procedures. Controls need written backing. Auditors will ask for policies, review cycles, training records, and documentation of recurring activities like patch management and access reviews.
5. Complete validation. Submit your SAQ or engage a QSA for an on-site assessment.
6. Submit your Attestation of Compliance (AOC). Formal declaration submitted to your acquiring bank confirming that validation is complete.

Common PCI compliance mistakes

Assuming your payment processor handles everything

Using Stripe, PayPal, Square, or a similar processor reduces your scope but doesn’t eliminate it. The systems hosting your checkout page, redirect logic, and internal tools querying transaction data via API are all potentially in scope.  

Your CDE scope is not fixed; new integrations, cloud migrations, and third-party tools can pull systems back into scope. Re-evaluate at least annually and after any significant infrastructure changes.

Treating “temporary” storage as exempt

Cardholder data in a debug log for 24 hours is still cardholder data. PCI DSS does not carve out exceptions for short-duration storage. If it was stored, it was in scope.

Passing scans but failing audits

A passing ASV scan is a requirement, not a compliance determination. Auditors look at actual configurations, access logs, policy documentation, and evidence of recurring activities. Organizations that treat scan results as a green light routinely fail when a QSA asks for documentation.

PCI DSS vs. other compliance frameworks

PCI DSS is purpose-built for one thing: protecting payment card data. That makes it narrower than most other frameworks.

• PCI DSS vs. ISO 27001: ISO 27001 is a broad information security management framework applicable to any type of sensitive data. ISO certification does not satisfy PCI validation requirements, and vice versa.
• PCI DSS vs. SOC 2: SOC 2 evaluates security controls across five Trust Service Criteria and produces an attestation report rather than a pass/fail certificate. The two are complementary, not interchangeable.
• PCI DSS vs. NIST CSF: NIST CSF is a voluntary framework with no certification pathway. It maps cleanly to PCI control categories but satisfies none of PCI’s validation requirements on its own.

PCI DSS compliance is a strong technical baseline, but it was designed with a narrow scope. Organizations subject to additional frameworks will find areas where PCI alone is not enough.

Why PCI DSS compliance doesn’t guarantee security

You can be fully PCI DSS compliant and still get breached. PCI DSS is narrowly scoped to cardholder data and the systems that touch it; everything outside the CDE isn’t covered.  

Compliance is also periodic. Assessments happen annually and scans quarterly. Auditors validate that controls exist, not always that they’re enforced consistently. A signed policy saying “only authorized software may execute” checks the box, but whether that’s running on every device every day is a separate question.

This is why compliance should be paired with a Zero Trust security strategy.  

By implementing strict Allowlisting controls and restricting application behavior across your environment, you ensure that unauthorized code cannot execute. This shifts compliance from periodic validation toward continuous enforcement.

FAQs

What happens if you’re not PCI compliant?
Fines typically range from $5,000 to $100,000 per month, depending on transaction volume and how long the issue remains unresolved. Beyond fines, processors can raise per-transaction fees or terminate your merchant account entirely. If a breach occurs while you’re out of compliance, you may be fully liable for forensic investigation costs, card replacement fees, and regulatory penalties.

What is a PCI DSS SAQ?
A Self-Assessment Questionnaire is the primary validation tool for most merchants below Level 1. There are multiple SAQ types (A, B, C, D, and variants); the right one depends on how your business accepts payments. Choosing the wrong type either understates your scope or creates an unnecessary compliance burden.

How often do you need to renew your PCI compliance?
There’s no single renewal date because compliance is continuous. Formal validation (SAQ or QSA audit) is required annually. External vulnerability scans must be completed quarterly through an ASV.

What changed between PCI DSS v3.2.1 and v4.0?
PCI DSS v4.0 expanded MFA requirements beyond remote access to cover all administrative CDE access, introduced a “customized approach” option for meeting individual requirements, and made targeted risk analysis a formal requirement. The deadline for full v4.0 compliance has passed, and legacy v3.2.1 controls are no longer accepted.