Skip to main content

PCI DSS Compliance

Prerequisites

Before diving into PCI DSS, understand:

TL;DR
  • PCI DSS is the Payment Card Industry Data Security Standard, the baseline security for anyone handling cardholder data
  • Four merchant levels based on annual transaction volume (Level 1: >6M, Level 2: 1–6M, Level 3: 20K–1M, Level 4: <20K)
  • SAQs range from ~22 controls (SAQ A) to 300+ controls (SAQ D)
  • Scope reduction techniques: tokenization, P2PE, network segmentation, outsourcing
  • Non-compliance fines: $5,000–$100,000/month

What Is PCI DSS?​

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment.

PCI DSS was created by the PCI Security Standards Council (PCI SSC), founded by Visa, Mastercard, American Express, Discover, and JCB. The council develops, maintains, and promotes the standard, while the card brands enforce compliance.

Important Version Update

PCI DSS 3.2.1 was retired on March 31, 2024. The current standard is PCI DSS 4.0.1. Future-dated requirements in 4.0 become mandatory on March 31, 2025.

Who Must Comply​

PCI DSS applies to any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD):

  • Merchants accepting payment cards
  • Service providers processing, storing, or transmitting CHD on behalf of merchants
  • Issuers and Acquirers
  • Any entity that could impact the security of CHD (even if they don't directly handle it)
Outsourcing Doesn't Eliminate Responsibility

Even if you outsource all payment processing, some PCI DSS requirements still apply. You must verify your service provider's compliance and manage that relationship appropriately.

The 12 PCI DSS Requirements​

PCI DSS is organized under six goals, each containing specific requirements:

Build and Maintain a Secure Network and Systems​

Requirement 1: Install and Maintain Network Security Controls

  • Implement firewalls and network security controls
  • Maintain configuration standards for all system components
  • Restrict traffic to and from the cardholder data environment (CDE)
  • Review firewall rules at least every six months

Requirement 2: Apply Secure Configurations to All System Components

  • Change all vendor-supplied default passwords and settings
  • Remove or disable unnecessary accounts and services
  • Implement only one primary function per server
  • Document security configuration standards

Protect Account Data​

Requirement 3: Protect Stored Account Data

  • Minimize data storage. Only store what's necessary.
  • Never store sensitive authentication data (SAD) after authorization
  • Mask PAN when displayed (show first 6 and/or last 4 only)
  • Render PAN unreadable wherever stored (encryption, hashing, tokenization, truncation)

Requirement 4: Protect Cardholder Data in Transit

  • Use strong cryptography when transmitting CHD over open networks
  • TLS 1.2 or higher required
  • Never send PAN via email, SMS, or chat

Maintain a Vulnerability Management Program​

Requirement 5: Protect All Systems and Networks from Malicious Software

  • Deploy anti-malware on all systems commonly affected
  • Keep anti-malware mechanisms current
  • Ensure anti-malware is actively running and cannot be disabled

Requirement 6: Develop and Maintain Secure Systems and Software

  • Identify and address vulnerabilities through a risk-based process
  • Apply risk-based patching (e.g., critical patches within one month)
  • Follow secure software development lifecycle (SDLC)
  • PCI DSS 4.0 adds Req 6.4.3: Manage all payment page scripts (JavaScript, etc.)

Implement Strong Access Control Measures​

Requirement 7: Restrict Access to System Components and CHD by Business Need-to-Know

  • Implement minimum privileges
  • Default deny: access only granted when explicitly needed
  • Document access control policies

Requirement 8: Identify Users and Authenticate Access

  • Assign unique IDs to all users
  • MFA required for all access into the CDE (expanded in 4.0)
  • 12-character passwords (or 8 characters if combined with MFA)
  • Lock accounts after 10 failed attempts

Requirement 9: Restrict Physical Access to Cardholder Data

  • Implement entry controls to sensitive areas
  • Protect media containing CHD
  • Control physical access to systems in the CDE

Regularly Monitor and Test Networks​

Requirement 10: Log and Monitor All Access to System Components and CHD

  • Implement audit trails for all access
  • Synchronize clocks across systems
  • Review logs daily
  • Retain audit logs for at least 12 months, with 3 months immediately available

Requirement 11: Test Security of Systems and Networks Regularly

  • Conduct quarterly wireless testing
  • Perform quarterly vulnerability scans by an Approved Scanning Vendor (ASV)
  • Conduct annual penetration testing
  • Deploy intrusion detection/prevention systems (IDS/IPS)
  • PCI DSS 4.0 adds Req 11.6.1: Detect unauthorized payment page changes

Maintain an Information Security Policy​

Requirement 12: Support Information Security with Organizational Policies and Programs

  • Conduct annual risk assessments
  • Maintain acceptable use policies
  • Implement security awareness training
  • Screen personnel before hiring
  • Maintain an incident response plan

Merchant Compliance Levels​

Card networks assign merchants to compliance levels based on annual transaction volume. Each level has different validation requirements.

Level 1​

Criteria:

  • More than 6 million transactions annually (Visa/Mastercard)
  • OR any merchant that has experienced a data breach
  • OR designated by a card network

Validation Requirements:

  • Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA)
  • Quarterly network scans by an ASV
  • Annual penetration test
  • Attestation of Compliance (AOC)

Level 2​

Criteria:

  • 1–6 million transactions annually

Validation Requirements:

  • Annual Self-Assessment Questionnaire (SAQ)
  • May need QSA assessment for SAQ A, A-EP, or D (Mastercard requirement)
  • Quarterly ASV scans
  • AOC

Level 3​

Criteria:

  • 20,000–1 million e-commerce transactions annually

Validation Requirements:

  • Annual SAQ
  • Quarterly ASV scans (if applicable)
  • AOC

Level 4​

Criteria:

  • Fewer than 20,000 e-commerce transactions annually
  • OR up to 1 million total transactions annually

Validation Requirements:

  • SAQ recommended (not always enforced)
  • Quarterly ASV scans (if applicable)
  • Direct Mastercard validation may not be required
Network-Specific Rules

Mastercard's Site Data Protection (SDP) program and Visa's Account Information Security (AIS) program have specific requirements. Your acquiring bank may impose additional requirements regardless of your level. Always verify with your acquirer.

Service Provider Compliance Levels​

Level 1​

Criteria:

  • More than 300,000 transactions annually
  • OR designated by a card network

Validation Requirements:

  • Annual ROC by QSA
  • Quarterly ASV scans
  • Annual penetration test
  • AOC

Level 2​

Criteria:

  • Fewer than 300,000 transactions annually

Validation Requirements:

  • Annual SAQ D (Service Provider version)
  • Quarterly ASV scans
  • AOC

Designated Entities Supplemental Validation (DESV)​

Large or high-risk service providers may be required to complete DESV, additional controls beyond standard PCI DSS requirements. This includes:

  • More frequent penetration testing
  • Enhanced logging and monitoring
  • Additional governance requirements

Self-Assessment Questionnaires (SAQs)​

SAQs are validation tools for merchants and service providers to assess their own compliance. The appropriate SAQ depends on how you handle cardholder data.

SAQDescriptionApprox. ControlsTypical Use Case
ACard-not-present, all CHD outsourced~22Hosted payment pages, MOTO outsourced
A-EPE-commerce affecting payment page~140Iframes, JS affecting checkout
BImprint-only or dial-out terminals~41Small retail dial-out
B-IPStandalone IP-connected PTS~82IP terminals, no CHD storage
C-VTVirtual terminal only~79Call centers, browser-based
CPayment apps connected to internet~160Small merchant POS
DAll other / complex environments300+CHD storage, doesn't fit above
P2PEValidated P2PE terminals~33PCI-validated P2PE solution

Note: Exact question counts change by version; these are ballpark figures.

Choosing Your SAQ​

Use this decision tree:

  1. Do you store cardholder data? → SAQ D
  2. Is all processing outsourced? → SAQ A or A-EP
  3. Do you use validated P2PE? → SAQ P2PE
  4. Do you have IP-connected terminals? → SAQ B-IP or C

Goal: Use redirect/hosted payment pages + tokenization to qualify for SAQ A instead of SAQ D. This dramatically reduces your compliance burden.

SAQ A Eligibility (v4.0 Updates)

Under PCI DSS 4.0, SAQ A eligibility for iframe integrations requires either:

  • Compliance with Req 6.4.3 and 11.6.1 for payment page script management, OR
  • Confirmation from your processor that they manage these requirements

Redirect integrations (where the customer leaves your site entirely) provide an easier compliance path.

Scope Reduction Strategies​

The most effective approach to PCI DSS compliance is reducing your scope: minimizing the systems and processes subject to requirements.

1. Tokenization​

What it does: Replaces cardholder data with a non-sensitive token that has no exploitable value.

Benefits:

  • Tokens are not cardholder data (out of scope)
  • Removes stored PAN from your environment
  • Enables card-on-file without storing actual cards
  • Can move from SAQ D to SAQ A

Implementation:

  • Use your processor's tokenization service
  • Ensure tokens are non-reversible
  • The token vault is your provider's responsibility

Deep Dive: How Tokenization Works​

Tokenization is your most powerful scope reduction tool. Understanding it helps you implement correctly.

Token Types​
Token TypeDescriptionUse Case
Payment tokenReplaces PAN for processingCard-on-file, subscriptions
Network tokenIssued by card networksEnhanced auth rates, lifecycle updates
Merchant tokenProcessor-specificSingle processor environments
Multi-use tokenSame token across transactionsRepeat customers
Single-use tokenOne transaction onlyOne-time payments, checkout
Network Tokenization Benefits​

Network tokens (Visa Token Service, Mastercard Digital Enablement Service) provide additional benefits beyond PCI scope reduction:

BenefitWhy It Matters
Card lifecycle updatesAutomatic reissue when card expires
Higher auth ratesIssuers trust tokenized transactions
Domain-specificToken only works for your merchant
Reduced false declinesBetter fraud signal for issuers
Tokenization Implementation Checklist​
StepWhat to Do
1. Select token providerProcessor's native tokenization or third-party
2. Determine token typeNetwork tokens preferred if supported
3. Implement token creationAt card capture point (checkout, add card)
4. Store tokens, not PANsUpdate database schema
5. Display handlingShow last 4 for customer reference
6. Migration planConvert existing stored cards to tokens
Token Security Considerations​
DoDon't
Store tokens in your databaseStore PANs alongside tokens "just in case"
Use processor's token vaultBuild your own reversible tokenization
Implement token rotation for high-value accountsUse tokens that are mathematically reversible to PANs
Log token usageLog actual card numbers
Token Format Examples​
Original PAN:      4111 1111 1111 1111
Processor token:   tok_1234567890abcdef
Network token:     4000 0012 3456 7899 (looks like a card but isn't)
Display format:    •••• •••• •••• 1111

Note: Network tokens intentionally look like card numbers to work with existing payment infrastructure. They're domain-restricted and useless outside your integration.

2. Point-to-Point Encryption (P2PE)​

What it does: Encrypts cardholder data from the point of interaction (terminal) to the decryption environment.

Benefits:

  • Qualifies for SAQ P2PE (~33 controls)
  • Encrypted data is out of scope
  • Dramatically reduces CDE

P2PE vs E2EE:

  • P2PE: PCI SSC-validated solution with immediate scope reduction
  • E2EE: Encryption at rest and in transit, but requires acquirer approval for scope reduction

3. Network Segmentation​

What it does: Isolates the cardholder data environment from other network segments.

Benefits:

  • Fewer in-scope systems
  • Limits attack surface
  • Faster assessments
  • Reduced compliance costs

Implementation:

  • Use firewalls, VLANs, or physical separation
  • Implement role-based access control
  • Conduct segmentation testing (Req 11.4.5)
  • Document CDE boundaries clearly

4. Outsourcing Payment Functions​

Approaches:

  • Hosted payment pages (redirect to processor)
  • Secure iframes (processor-controlled)
  • Gateway API with tokenization (never touch raw card data)
  • Managed payment services

Important: Even when outsourcing:

  • Verify provider's AOC
  • Include provider in your service provider management program
  • Understand your residual responsibilities

Network-Specific Requirements​

Visa Requirements​

  • Account Information Security (AIS): Primary compliance program
  • Compromise Investigation: Must engage a PCI Forensic Investigator (PFI) after suspected breach
  • Fraud Monitoring: Report fraud through required channels
  • Terminated Merchant File (TMF): Also known as MATCH, the list of terminated merchants

Mastercard Requirements​

  • Site Data Protection (SDP): Primary compliance program
  • Level 1/2 service providers may require DESV
  • Validation documents submitted to acquiring bank
  • Information Security Program: Required under Mastercard Rules Section 2.2.7
  • Third Party Processor (TPP) registration requirements

Cardholder Data Defined​

Understanding what constitutes cardholder data is essential for scoping.

Cardholder Data (CHD)​

ElementDescriptionNotes
PANPrimary Account Number (15-19 digits)The defining element: if PAN is present, it's CHD
Cardholder NameName on cardOnly CHD when stored with PAN
Expiration DateCard validity periodOnly CHD when stored with PAN
Service Code3-digit code on magnetic stripeOnly CHD when stored with PAN

Note on truncation: Truncated PAN (first 6 + last 4 digits) is still considered CHD, but permanently deleting the middle digits means you're not storing the full PAN.

Sensitive Authentication Data (SAD)​

NEVER store SAD after authorization, even encrypted:

ElementDescription
Full track dataTrack 1 and Track 2 from magnetic stripe
CVV/CVC/CVV2/CIDCard verification codes
PIN/PIN blockPersonal identification numbers

Data Rendering Methods​

When you must store PAN, render it unreadable using:

MethodDescription
TruncationPermanently remove middle digits (keep first 6 and/or last 4)
TokenizationReplace with non-reversible token
Strong hashingOne-way cryptographic hash with salt
EncryptionStrong encryption with proper key management (AES-256)

Compliance Validation and Assessment​

Quarterly ASV Scans​

  • External vulnerability scans performed by an Approved Scanning Vendor
  • Required for any internet-facing systems
  • Must pass (no high or critical vulnerabilities)
  • Submit passing scan reports with your SAQ or ROC

Annual Penetration Testing​

  • Required for Level 1 and Level 2 merchants
  • Test both internal and external networks
  • Validate network segmentation effectiveness
  • PCI DSS 4.0 requires a defined methodology

Attestation of Compliance (AOC)​

  • Formal attestation of PCI DSS compliance status
  • Signed by QSA (for ROC) or merchant officer (for SAQ)
  • Required to be submitted to acquirer
  • Often requested by business partners

Consequences of Non-Compliance​

ConsequenceDetails
Monthly fines$5,000–$100,000/month depending on severity and duration
Increased transaction feesHigher interchange and assessment fees
Liability shiftMerchant bears full liability for breach costs
MATCH listingAdded to Mastercard terminated merchant file
Loss of card acceptanceProcessing privileges revoked
Brand damageBreach notification requirements, reputational harm

Common Compliance Pitfalls​

Underestimating Scope​

  • Payment applications often store data in unexpected places (logs, temp files, databases)
  • Systems connected to the CDE are in scope
  • Third-party integrations may pull CHD into scope
  • Cloud environments have shared responsibility models

Scope Creep Over Time​

  • New sales channels added without security review
  • New devices connected to payment network
  • Test environments using production data
  • Acquired companies with different security postures

Documentation Gaps​

  • Outdated network diagrams
  • Missing or incomplete policies
  • Incomplete service provider inventory
  • No business justification for enabled protocols/ports

Key Management Weaknesses​

  • Using weak or default encryption keys
  • No key rotation schedule
  • Storing keys with encrypted data
  • No split knowledge or dual control for key operations

Misunderstanding Compensating Controls​

  • Compensating controls are only used when the original requirement cannot be met
  • Insufficient documentation of why original requirement isn't achievable
  • Not demonstrating equivalent protection
  • Failing to re-evaluate annually

PCI DSS 4.0 Key Changes​

Customized Approach​

  • Design your own controls to meet requirement objectives
  • Document and test effectiveness
  • Requires QSA validation
  • More flexibility but more documentation burden

Targeted Risk Analysis​

  • For certain requirements, determine frequency via targeted risk analysis (TRA) instead of fixed schedules
  • Can apply to some log reviews, vulnerability scanning, and other periodic activities where 4.0 explicitly allows
  • Must document methodology and defend conclusions

Enhanced Authentication​

  • MFA required for all CDE access (not just remote access)
  • 12-character passwords (8 characters only if system limitations + MFA)
  • Service account password/key protection requirements

Payment Page Security (Future-Dated to March 2025)​

Requirement 6.4.3: Authorize, document, and monitor all scripts (JavaScript, etc.) on payment pages

Requirement 11.6.1: Implement mechanisms to detect unauthorized changes to payment page content

These requirements address Magecart-style attacks where attackers inject malicious scripts into payment pages to steal card data.

Getting Started with Compliance​

  1. Understand your data flows – Map where CHD enters, moves through, and exits your environment
  2. Determine your merchant level – Based on annual transaction volume
  3. Identify scope reduction opportunities – Tokenization, P2PE, outsourcing
  4. Select appropriate SAQ – After implementing scope reduction
  5. Implement required controls – Gap analysis against applicable requirements
  6. Engage qualified assessors – QSA for Level 1, or self-assessment
  7. Establish ongoing processes – Quarterly scans, annual assessments, continuous monitoring

Next Steps​

Just learning about PCI?

  1. Map your cardholder data environment → Where does card data flow?
  2. Determine your merchant level → Based on annual transaction volume
  3. Identify scope reduction opportunities → Tokenization eliminates most PCI burden

Ready to reduce scope?

  1. Evaluate tokenization providers → Let them handle card data, not you
  2. Consider hosted payment pages → Remove your systems from scope entirely
  3. Ask your processor about P2PE terminals → Reduce in-store PCI requirements

Preparing for assessment?

  1. Gap analysis against your SAQ type → Know what's required
  2. Engage a QSA early (Level 1) → Don't wait until assessment time
  3. Establish quarterly ASV scanning → Required for all merchants

See Also​