PCI DSS — Payment Card Industry Data Security Standard

Effective overview last updated: January 2026

What Is PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to protect cardholder data. It was created by the PCI Security Standards Council (PCI SSC), founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa.

The current version is PCI DSS v4.0.1, released in June 2024. Version 4.0 represented a significant update from v3.2.1, introducing a "customized approach" alongside the traditional "defined approach" and adding new requirements that became mandatory on March 31, 2025.

PCI DSS is not a law — it's an industry standard enforced through contracts between merchants, payment processors, and card brands.

Who Must Comply

Any entity that stores, processes, or transmits cardholder data or sensitive authentication data must comply with PCI DSS. This includes:

• Merchants of any size that accept card payments (online, in-store, or by phone)
• Service providers that store, process, or transmit cardholder data on behalf of other entities (payment gateways, hosting providers, managed security services)
• Acquirers/processors that process payment transactions
• Issuers (banks that issue payment cards)

Compliance Levels

Card brands assign compliance levels based on annual transaction volume:

Merchants (Visa example):

• Level 1: Over 6 million transactions/year — requires annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans
• Level 2: 1–6 million transactions/year — requires annual Self-Assessment Questionnaire (SAQ) and quarterly scans
• Level 3: 20,000–1 million e-commerce transactions/year — requires annual SAQ and quarterly scans
• Level 4: Under 20,000 e-commerce or up to 1 million other transactions/year — requires annual SAQ and quarterly scans (recommended but often not enforced by acquirers)

Service Providers:

• Level 1: Over 300,000 transactions/year — requires annual on-site assessment by a QSA
• Level 2: Under 300,000 transactions/year — requires annual SAQ

What PCI DSS Protects

PCI DSS specifically protects two types of data:

Cardholder Data

• Primary Account Number (PAN) — the card number itself
• Cardholder name
• Expiration date
• Service code

Sensitive Authentication Data

• Full track data (magnetic stripe or chip)
• Card verification codes (CVV2/CVC2/CID)
• PINs and PIN blocks

Sensitive authentication data must never be stored after authorization, even if encrypted. This is an absolute requirement with no exceptions.

The 12 Requirements

PCI DSS is organized into 12 requirements under 6 goals:

Build and Maintain a Secure Network and Systems

Requirement 1 — Install and maintain network security controls: Firewalls (or equivalent), network segmentation, controls on traffic between trusted and untrusted networks.

Requirement 2 — Apply secure configurations to all system components: Change vendor defaults, eliminate unnecessary services, encrypt non-console administrative access.

Protect Account Data

Requirement 3 — Protect stored account data: Render PAN unreadable anywhere it is stored (encryption, truncation, hashing, tokenization). Define retention periods and purge data that exceeds them. Never store sensitive authentication data after authorization.

Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks: Use current, strong cryptographic protocols (TLS 1.2+) for all transmissions of cardholder data.

Maintain a Vulnerability Management Program

Requirement 5 — Protect all systems and networks from malicious software: Deploy anti-malware solutions, keep them current, perform periodic scans.

Requirement 6 — Develop and maintain secure systems and software: Establish secure development practices, manage vulnerabilities, deploy security patches promptly, protect public-facing web applications (WAF or code review).

Implement Strong Access Control Measures

Requirement 7 — Restrict access to system components and cardholder data by business need to know: Role-based access control, deny-all default, periodic access reviews.

Requirement 8 — Identify users and authenticate access to system components: Unique IDs for all users, strong authentication (MFA for all access to the cardholder data environment), secure credential management.

Requirement 9 — Restrict physical access to cardholder data: Physical access controls, visitor management, media destruction, point-of-interaction device security.

Regularly Monitor and Test Networks

Requirement 10 — Log and monitor all access to system components and cardholder data: Audit trails, time synchronization, log reviews, automated alerts, file integrity monitoring.

Requirement 11 — Test security of systems and networks regularly: Wireless access point detection, vulnerability scans (internal and external quarterly ASV scans), penetration testing (annual at minimum), intrusion detection/prevention, change detection mechanisms.

Maintain an Information Security Policy

Requirement 12 — Support information security with organizational policies and programs: Information security policy, acceptable use policies, risk assessments, security awareness training, incident response plan, service provider management.

PCI DSS v4.0 Changes

Version 4.0 introduced significant changes:

• Customized approach: Organizations can now design their own controls to meet each requirement's security objective, rather than following the prescribed "defined approach." The customized approach requires more documentation and a rigorous validation process.
• Targeted risk analysis: Many requirements now allow organizations to define frequencies (e.g., for log reviews, password changes) based on their own targeted risk analysis.
• Enhanced authentication: MFA is now required for all access to the cardholder data environment, not just remote access.
• E-commerce and scripts: New requirements for managing payment page scripts and preventing e-skimming attacks.
• Encryption everywhere: Strong cryptography required for all PAN storage, eliminating some previous alternatives.
• Service provider-specific requirements: Additional requirements for service providers, including stricter change management and intrusion detection.

Where Privacy Policies Fit

Honesty note: PCI DSS is a data security standard, not a privacy framework. It does not require a customer-facing privacy policy, and your privacy policy is not an artifact that a QSA will audit against PCI DSS requirements.

PCI DSS focuses on the security of cardholder data — how you protect it technically and operationally — not on how you communicate your data practices to consumers. Privacy policies are transparency documents; PCI DSS is about security controls.

Where There Is Overlap

That said, your privacy policy can create PCI DSS-relevant concerns in a few ways:

Consistency with actual practices: If your privacy policy describes how you handle payment data (e.g., "we do not store your credit card number"), your actual practices must match. A privacy policy claiming you don't store cardholder data while your systems retain PANs would indicate a broader compliance problem — not a PCI DSS violation per se, but a governance issue any assessor would note.

Requirement 12 — Information Security Policy: PCI DSS Requirement 12 mandates an information security policy, but this is an internal policy governing your security program, not a customer-facing privacy policy. However, some organizations reference their security commitments in their public privacy policy, which then creates obligations they must fulfill.

Data retention disclosures: If your privacy policy states specific retention periods for payment-related data, these should align with Requirement 3's data retention and disposal requirements.

Third-party disclosures: If your privacy policy names payment processors or describes how cardholder data flows through third parties, this should be consistent with your Requirement 12.8 service provider management program.

When Privacy Policies Become More Relevant

If you're subject to both PCI DSS and a privacy law (CCPA, GDPR, etc.), your privacy policy must satisfy the privacy law's requirements for how you disclose your handling of payment-related personal information. In this case, reviewing your privacy policy makes sense — but the driver is the privacy law, not PCI DSS itself.

Reducing PCI DSS Scope

One of the most impactful decisions an organization makes is how to minimize its PCI DSS scope. Common strategies:

• Tokenization: Replace cardholder data with tokens that have no exploitable value. The payment processor stores the actual card data, not you.
• Hosted payment pages: Use your payment processor's hosted payment page (Stripe Checkout, PayPal hosted buttons, etc.) so cardholder data never touches your servers.
• Point-to-point encryption (P2PE): Use validated P2PE solutions for in-person payments, significantly reducing the scope of physical and network controls.
• Network segmentation: Isolate the cardholder data environment from the rest of your network to limit which systems are in scope.

Many modern businesses, especially e-commerce companies using Stripe, PayPal, or similar services, can achieve SAQ A or SAQ A-EP compliance levels by ensuring cardholder data never enters their systems.

How Privacy Policy Review Helps

We want to be straightforward: PCI DSS doesn't require or audit your privacy policy. If PCI DSS compliance is your only concern, a privacy policy review isn't what you need — you need a QSA or ISA assessment.

However, if you're reviewing your privacy policy against other frameworks (CCPA, GDPR, SOC 2) and you handle payment data, our review can check that your privacy policy's statements about payment data handling are accurate and consistent. Inconsistencies between what you tell customers and what you actually do create risk regardless of which regulation catches it.

If you select PCI DSS as a framework in our review, we analyze your privacy policy for accuracy in its payment data disclosures — verifying that your public statements about cardholder data storage, processing, sharing, and retention are specific and don't create contradictions with PCI DSS requirements.