PCI DSS Requirements Explained: The Complete Compliance Checklist for Developers

A QSA just emailed your team: “Please provide evidence of PCI DSS compliance for your payment application.” You stare at the 300-page standard and think — where do I even start? Right here.

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. It was created by the five major card networks — Visa, Mastercard, American Express, Discover, and JCB — through the PCI Security Standards Council (PCI SSC).

PCI DSS isn’t a law, but it’s contractually enforced. If you accept card payments, your acquiring bank requires compliance. Non-compliance can result in fines of $5,000 to $100,000 per month, increased transaction fees, or — worst case — losing the ability to accept card payments entirely.

See it in action: Our PCI Sanitizer demonstrates Requirement 3.4 in practice — masking PANs and sensitive data before they hit your logs.

Also Known As…

PCI DSS goes by several names depending on the context:

The PCI DSS standard is currently on version 4.0.1 (released June 2024), which replaces version 3.2.1. Version 4.0 introduced significant changes, including a shift toward customized validation alongside the traditional defined approach.

The 12 PCI DSS Requirements at a Glance

PCI DSS is organized into 6 goals containing 12 requirements. This is your compliance checklist:

These 12 requirements break down into over 300 individual sub-requirements — but as a developer, you only need to focus on the ones that directly impact your code and architecture.

PCI DSS Compliance Levels

Not every merchant has the same compliance burden. The card networks assign compliance levels based on annual transaction volume:

Key terms: A QSA (Qualified Security Assessor) is a PCI-certified auditor. An ASV (Approved Scanning Vendor) performs external vulnerability scans. An ISA (Internal Security Assessor) is trained staff who can perform internal assessments.

SAQ Types: Which One Do You Need?

The Self-Assessment Questionnaire you complete depends on how you handle card data:

The golden rule: The less card data you touch, the fewer requirements apply to you.

Deep Dive: Requirements That Matter Most to Developers

Let’s break down the requirements where developers have the most impact.

Requirement 3: Protect Stored Account Data

This is where most developer mistakes happen. The rules are clear about what you can and cannot store:

PAN Masking and Truncation

When displaying PANs, PCI DSS allows showing at most the first 6 and last 4 digits (but not both at once unless there’s a business justification and proper access controls):

function maskPAN(pan) {
    const cleaned = pan.replace(/\D/g, '');
    
    if (cleaned.length < 13) return '****';
    
    // Show first 6 and last 4 (requires business justification per PCI DSS 4.0)
    // Default safe approach: show only last 4
    const lastFour = cleaned.slice(-4);
    const masked = '*'.repeat(cleaned.length - 4) + lastFour;
    
    return masked;
}

// Input:  4111111111111111
// Output: ************1111

Try it yourself: Paste a log file containing PANs into our PCI Sanitizer to see compliant masking applied automatically.

Encryption Requirements

If you store PANs, PCI DSS Requirement 3.5 mandates strong cryptography with proper key management:

Requirement 4: Protect Data in Transit

Every transmission of cardholder data across open, public networks must use strong cryptography:

// WRONG: HTTP for payment data
fetch('http://api.example.com/charge', {
    body: JSON.stringify({ pan: '4111111111111111' })
});

// CORRECT: TLS 1.2+ enforced
fetch('https://api.example.com/charge', {
    body: JSON.stringify({ pan: '4111111111111111' }),
    headers: { 'Content-Type': 'application/json' }
});

PCI DSS 4.0 explicitly requires TLS 1.2 or higher. Earlier versions (SSL, TLS 1.0, TLS 1.1) are prohibited.

Requirement 6: Secure Development Practices

PCI DSS 4.0 significantly expanded Requirement 6 for software development:

Secure Development Lifecycle

Requirement 6.4.2: Payment Page Script Management

This is brand new in PCI DSS 4.0 and catches many teams off guard. If you have a payment page, you must:

1. Inventory all scripts loaded on the payment page (including third-party)
2. Justify each script’s presence and business need
3. Verify script integrity using Subresource Integrity (SRI) or Content Security Policy (CSP)
4. Monitor for unauthorized changes to scripts

<!-- CORRECT: SRI hash ensures script integrity -->
<script src="https://js.stripe.com/v3/" 
        integrity="sha384-ABC123..."
        crossorigin="anonymous"></script>

<!-- CORRECT: CSP header restricts script sources -->
<!-- Content-Security-Policy: script-src 'self' https://js.stripe.com -->

Requirement 8: Strong Authentication

PCI DSS 4.0 raised the bar for authentication:

Requirement 10: Logging and Monitoring

Every access to cardholder data must be logged. But here’s the catch — your logs themselves must not contain cardholder data:

// WRONG: PAN in log output
logger.info(`Processing payment for card ${cardNumber}`);
// Output: "Processing payment for card 4111111111111111" ← PCI VIOLATION

// CORRECT: Masked PAN in logs
logger.info(`Processing payment for card ${maskPAN(cardNumber)}`);
// Output: "Processing payment for card ************1111" ✅

What must be logged (Requirement 10.2):

Clean your logs: Use our PCI Sanitizer to strip PANs, CVVs, and track data from log files before sharing them with support teams or storing them in log management systems.

What Changed in PCI DSS 4.0

PCI DSS 4.0 represents the biggest update to the standard in years. Here are the changes developers need to know:

Key Deadlines

All future-dated requirements are now mandatory — there’s no more grace period.

PCI DSS Compliance Checklist for Developers

Here’s a practical checklist you can use during code reviews and architecture decisions:

Data Handling

• Never store full track data, CVV2, or PIN post-authorization
• Encrypt stored PANs using AES-256 or stronger
• Implement key rotation for encryption keys
• Use tokenization where possible to reduce PCI scope
• Mask PANs in all display output (show last 4 only)
• Purge cardholder data when no longer needed

Network and Transmission

• Enforce TLS 1.2+ for all cardholder data transmissions
• Disable SSL and early TLS in all configurations
• Implement certificate pinning for mobile applications
• Segment the cardholder data environment (CDE) from other networks

Application Security

• Sanitize all user input (prevent SQL injection, XSS)
• Implement Content Security Policy headers on payment pages
• Inventory all scripts on payment pages (Requirement 6.4.2)
• Use SRI hashes for third-party scripts
• Conduct code reviews before each production release
• Keep all frameworks and libraries patched and up to date

Authentication and Access

• Enforce 12-character minimum passwords
• Implement MFA for all access to the CDE
• Assign unique IDs to every user (no shared accounts)
• Implement role-based access control (RBAC)
• Lock accounts after 10 failed login attempts
• Set 15-minute session idle timeout

Logging and Monitoring

• Log all access to cardholder data with user ID and timestamp
• Never log PANs, CVVs, or sensitive auth data in plaintext
• Protect audit logs from modification
• Review logs daily for suspicious activity
• Retain audit logs for at least 12 months (3 months readily accessible)
• Synchronize clocks across all systems using NTP

Scope Reduction: The Developer’s Best Friend

The single most impactful thing you can do for PCI compliance is reduce your scope. Less card data in your environment means fewer requirements apply:

Your Full Environment (without scope reduction):
┌─────────────────────────────────────────────┐
│  ┌─────┐ ┌────────┐ ┌──────┐ ┌───────────┐ │
│  │ Web │ │ App    │ │ DB   │ │ Log       │ │ ← ALL in PCI scope
│  │ Srv │ │ Server │ │ Srv  │ │ Server    │ │
│  └─────┘ └────────┘ └──────┘ └───────────┘ │
└─────────────────────────────────────────────┘

With Tokenization + Segmentation:
┌──────────────────┐    ┌──────────────────────┐
│  Non-CDE (out    │    │  CDE (in scope)      │
│  of scope)       │    │  ┌──────┐ ┌────────┐ │
│  ┌─────┐ ┌─────┐ │    │  │Token │ │ HSM    │ │
│  │ Web │ │ Log │ │    │  │Vault │ │        │ │
│  │ Srv │ │ Srv │ │    │  └──────┘ └────────┘ │
│  └─────┘ └─────┘ │    └──────────────────────┘
└──────────────────┘

Common PCI DSS Violations (and How to Fix Them)

These are the issues QSAs find most often during assessments:

Key Management for PCI DSS

Requirement 3.6 and 3.7 mandate a complete cryptographic key management lifecycle. This is where HSMs become essential:

Verify your keys: Use our KCV Calculator to compute Key Check Values — the PCI-approved method for verifying key integrity without exposing the key itself.

PCI DSS for Different Architectures

How PCI scope changes depending on your payment integration:

Direct API Integration

You handle raw card data directly. Heaviest PCI scope.

Customer → Your Server (PAN in memory) → Processor API

• SAQ D applicable
• Full 12 requirements apply
• Annual penetration testing required
• Quarterly ASV scans required

Hosted Payment Page (Redirect)

Customer is redirected to the processor’s page. Lightest scope.

Customer → Processor's hosted page → Processor
                ↓
        Your server (token only)

• SAQ A applicable
• ~30 questions
• No card data touches your systems

JavaScript/iFrame Integration

Processor’s JS collects card data within your page. Moderate scope.

Customer → Your page (with processor's iFrame/JS)
                ↓
        Card data → Processor directly
        Token → Your server

• SAQ A-EP applicable
• ~140 questions
• You must protect your payment page scripts (Req 6.4.2)

What PCI DSS Does NOT Cover

Understanding the boundaries prevents false confidence:

Quick Reference: PCI DSS Terminology

Next Steps

Now that you understand PCI DSS requirements and how they impact your payment applications:

1. Sanitize your logs with the PCI Sanitizer — see Requirement 3.4 and 10.3 in action
2. Verify your keys with the KCV Calculator — PCI-compliant key verification
3. Learn HSM fundamentals in our HSM Basics for Developers guide — the backbone of PCI key management
4. Understand ARQC/ARPC with the ARQC Calculator — the cryptographic operations behind chip card compliance
5. Parse payment messages with the ISO 8583 Studio — see where PAN data lives in Field 2
6. Look up response codes in the Reference Database when debugging PCI-scoped transaction flows
7. Understand track data in our Magnetic Stripe Track Data Guide — the Sensitive Authentication Data that must never be stored post-authorization
8. Compare 3DES vs AES in our 3DES vs AES in Payments guide — understand the encryption algorithms behind PCI Requirement 3.5

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.