Pci Dss Specialist

PCI-DSS v4.0 Specialist

Implement, assess, and maintain compliance with the Payment Card Industry Data Security Standard version 4.0 — the global standard for protecting cardholder data in payment processing environments.

Table of Contents

• Trigger Phrases
• Quick Start
• Tools
• PCI DSS v4.0 Overview
• 12 Requirements Deep-Dive
• v4.0 Changes from v3.2.1
• CDE Scoping
• SAQ Types and Selection Guide
• Assessment Types
• Merchant and Service Provider Levels
• Infrastructure Controls
• PCI DSS Compliance Roadmap
• Reference Guides
• Validation Checkpoints

Trigger Phrases

Use this skill when you hear:

• "PCI DSS"
• "payment card security"
• "cardholder data"
• "PCI compliance"
• "payment security"
• "PCI assessment"
• "SAQ"
• "ROC"
• "QSA"
• "credit card security"
• "payment processing security"
• "tokenization"
• "CDE scoping"
• "merchant level compliance"

Quick Start

Check PCI Compliance Status

python scripts/pci_compliance_checker.py --input controls.json --output compliance_report.json

Determine SAQ Type

python scripts/pci_scope_analyzer.py --input business_model.json --output scope_report.json

Generate Compliance Gap Report (Markdown)

python scripts/pci_compliance_checker.py --input controls.json --format markdown --output gap_report.md

Analyze CDE Scope

python scripts/pci_scope_analyzer.py --input business_model.json --format markdown --output scope_analysis.md

Tools

pci_compliance_checker.py

Comprehensive PCI DSS v4.0 compliance assessment engine.

Capabilities:

• Checks against all 12 PCI DSS requirements
• Validates cardholder data environment scope
• Assesses technical controls (encryption, access, logging)
• Scores compliance per requirement (0-100)
• Identifies gaps with remediation priorities
• Generates JSON or Markdown output

Usage:

# Full compliance check
python scripts/pci_compliance_checker.py \
  --input controls.json \
  --output report.json

# Markdown report for stakeholders
python scripts/pci_compliance_checker.py \
  --input controls.json \
  --format markdown \
  --output compliance_report.md

# Check specific requirements only
python scripts/pci_compliance_checker.py \
  --input controls.json \
  --requirements 3,4,7,8 \
  --output data_security_report.json

Input Format (controls.json):

{
  "organization": "Acme Payments",
  "assessment_date": "2026-03-09",
  "merchant_level": 2,
  "requirements": {
    "1": {
      "network_segmentation": true,
      "firewall_rules_documented": true,
      "waf_deployed": true,
      "inbound_traffic_restricted": true,
      "outbound_traffic_restricted": false,
      "wireless_networks_segmented": true,
      "notes": "Outbound filtering planned for Q2"
    },
    "3": {
      "pan_storage_minimized": true,
      "pan_masked_when_displayed": true,
      "pan_encrypted_at_rest": true,
      "encryption_algorithm": "AES-256",
      "key_management_procedures": true,
      "tokenization_implemented": true,
      "sad_not_stored_after_auth": true,
      "notes": "Tokenization covers 95% of stored PANs"
    }
  }
}

pci_scope_analyzer.py

CDE scoping and SAQ type determination engine.

Capabilities:

• Determines appropriate SAQ type based on business model
• Maps cardholder data environment boundaries
• Identifies connected systems and security-impacting systems
• Generates scoping worksheet with system classifications
• Recommends scope reduction strategies

Usage:

# Determine SAQ type and CDE scope
python scripts/pci_scope_analyzer.py \
  --input business_model.json \
  --output scope_report.json

# Markdown scoping worksheet
python scripts/pci_scope_analyzer.py \
  --input business_model.json \
  --format markdown \
  --output scoping_worksheet.md

Input Format (business_model.json):

{
  "organization": "Acme Payments",
  "business_type": "e-commerce",
  "payment_channels": ["web", "mobile_app"],
  "card_present": false,
  "card_not_present": true,
  "stores_pan": false,
  "processes_pan": false,
  "transmits_pan": false,
  "payment_processor": "Stripe",
  "uses_iframe_redirect": true,
  "uses_p2pe": false,
  "annual_transactions": 500000,
  "card_brands": ["visa", "mastercard", "amex"],
  "systems": [
    {
      "name": "web-frontend",
      "type": "web_server",
      "handles_cardholder_data": false,
      "connected_to_cde": false,
      "security_impacting": true,
      "description": "Customer-facing e-commerce site with iframe payment"
    },
    {
      "name": "payment-api",
      "type": "application_server",
      "handles_cardholder_data": false,
      "connected_to_cde": true,
      "security_impacting": true,
      "description": "API server that communicates with Stripe"
    }
  ]
}

PCI DSS v4.0 Overview

What Is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard developed by the PCI Security Standards Council (PCI SSC), founded by American Express, Discover, JCB, Mastercard, and Visa. It applies to all entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD).

PCI DSS v4.0 Timeline

All organizations must now comply with the full PCI DSS v4.0 standard, including all previously future-dated requirements.

What Data Is Protected

Cardholder Data (CHD):

• Primary Account Number (PAN) — the credit/debit card number
• Cardholder Name (when stored with PAN)
• Service Code
• Expiration Date

Sensitive Authentication Data (SAD): Must NEVER be stored after authorization, even if encrypted.

• Full track data (magnetic stripe, chip)
• CVV/CVC/CAV2/CID (card verification codes)
• PIN and PIN block

12 Requirements Deep-Dive

Requirement 1: Install and Maintain Network Security Controls

Objective: Protect the cardholder data environment through network security controls.

Key Sub-Requirements:

• 1.2.1 — Network security controls (NSCs) are configured and maintained
• 1.2.5 — All services, protocols, and ports allowed are identified and approved
• 1.2.8 — NSC configuration files are secured and synchronized
• 1.3.1 — Inbound traffic to the CDE is restricted to only necessary traffic
• 1.3.2 — Outbound traffic from the CDE is restricted to only necessary traffic
• 1.4.1 — NSCs are implemented between trusted and untrusted networks
• 1.4.5 — Disclosure of internal IP addresses is prevented
• 1.5.1 — Security controls on all computing devices connecting via untrusted networks

Implementation Guidance:

• Deploy next-generation firewalls (NGFW) at CDE boundaries
• Implement Web Application Firewalls (WAF) for web-facing payment applications
• Use network segmentation to isolate CDE from corporate network
• Restrict inbound to CDE: only necessary ports/protocols from known sources
• Restrict outbound from CDE: only approved destinations (payment processor, updates)
• Document all firewall rules with business justification
• Review firewall rules at least every 6 months
• Implement micro-segmentation where possible

Requirement 2: Apply Secure Configurations to All System Components

Objective: Ensure all systems are configured securely with no unnecessary default settings.

Key Sub-Requirements:

• 2.2.1 — Configuration standards developed for all system components
• 2.2.2 — Vendor default accounts managed (changed, disabled, or removed)
• 2.2.3 — Primary functions requiring different security levels are managed (one primary function per server or use containerization)
• 2.2.4 — Only necessary services, protocols, daemons, and functions are enabled
• 2.2.5 — Insecure services are secured if present
• 2.2.6 — System security parameters are configured to prevent misuse
• 2.2.7 — Non-console administrative access is encrypted

Implementation Guidance:

• Apply CIS Benchmarks as baseline configurations
• Change ALL vendor default passwords before deployment
• Remove or disable unnecessary services, protocols, and daemon
• Harden operating systems using DISA STIGs or CIS Benchmarks
• Enforce encrypted administrative access (SSH, HTTPS, TLS 1.2+)
• Use configuration management tools for consistency (Ansible, Chef, Puppet)
• Deploy from hardened golden images

Requirement 3: Protect Stored Account Data

Objective: Minimize stored data and protect it with strong cryptography.

Key Sub-Requirements:

• 3.2.1 — Data retention and disposal policies implemented
• 3.3.1 — SAD not retained after authorization (even if encrypted)
• 3.3.2 — SAD that is stored before authorization is encrypted using strong cryptography
• 3.4.1 — PAN is masked when displayed (show only first 6 and last 4 digits max)
• 3.5.1 — PAN is rendered unreadable anywhere it is stored (encryption, tokenization, truncation, or hashing)
• 3.6.1 — Cryptographic key management procedures are defined and implemented
• 3.7.1-3.7.9 — Comprehensive key management lifecycle

Implementation Guidance:

• Minimize PAN storage — do not store unless absolutely necessary
• Use tokenization to replace PANs with non-reversible tokens
• Encrypt stored PAN with AES-256 (or equivalent)
• Never store SAD (CVV, track data, PIN) after authorization — period
• Mask PAN in all displays: show max first 6 / last 4 digits
• Implement HSM-based key management for encryption keys
• Rotate encryption keys at least annually
• Use split knowledge and dual control for key management
• Maintain key inventory with custodian assignments
• Use DUKPT or ANSI X9.24 for key management in POS environments

Tokenization vs Encryption Decision:

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Objective: Encrypt CHD whenever transmitted over open, public networks.

Key Sub-Requirements:

• 4.2.1 — Strong cryptography and security protocols protect CHD during transmission over open, public networks
• 4.2.1.1 — Trusted certificates for PAN transmission over open, public networks
• 4.2.1.2 — Wireless networks transmitting PAN use industry best practices for strong cryptography
• 4.2.2 — PAN is secured with strong cryptography whenever sent via end-user messaging technologies

Implementation Guidance:

• Use TLS 1.2 as minimum, prefer TLS 1.3
• Disable SSL, TLS 1.0, TLS 1.1 entirely
• Use strong cipher suites (ECDHE key exchange, AES-GCM)
• Implement certificate pinning for mobile payment apps
• Deploy HSTS (HTTP Strict Transport Security) on all payment pages
• Use mTLS (mutual TLS) between internal CDE components
• Monitor certificate expiration and automate renewal
• Never send PAN via email, chat, or SMS unencrypted

Requirement 5: Protect All Systems and Networks from Malicious Software

Objective: Defend all systems against malware.

Key Sub-Requirements:

• 5.2.1 — Anti-malware solution(s) deployed on all system components
• 5.2.2 — Anti-malware solution performs periodic and real-time scans
• 5.2.3 — For systems not commonly affected by malware, periodic evaluations performed
• 5.3.1 — Anti-malware mechanisms are kept current
• 5.3.2 — Anti-malware performs periodic and real-time scans
• 5.3.3 — For removable media, anti-malware scans automatically upon insertion
• 5.3.4 — Audit logs for anti-malware are enabled and retained
• 5.3.5 — Anti-malware cannot be disabled or altered by users (except case-by-case with management approval for limited time, logged)
• 5.4.1 — Mechanisms detect and protect against phishing attacks

Implementation Guidance:

• Deploy EDR/XDR on all endpoints (workstations, servers, POS terminals)
• Ensure real-time scanning with automatic definition updates
• Enable email-based anti-phishing controls (SPF, DKIM, DMARC, sandbox)
• Implement application allowlisting on POS and critical CDE systems
• Log all anti-malware events and integrate with SIEM
• For Linux/Unix systems: document risk evaluation and deploy appropriate controls

Requirement 6: Develop and Maintain Secure Systems and Software

Objective: Protect against vulnerabilities through secure development and timely patching.

Key Sub-Requirements:

• 6.2.1 — Custom software developed securely (OWASP, CERT, SANS)
• 6.2.2 — Developer training in secure coding at least annually
• 6.2.3 — Custom software reviewed before release to identify vulnerabilities
• 6.2.4 — Software engineering techniques prevent common vulnerabilities (OWASP Top 10)
• 6.3.1 — Security vulnerabilities identified and managed (vulnerability management process)
• 6.3.2 — Software inventory maintained to enable vulnerability management
• 6.3.3 — Critical and high vulnerabilities patched within defined timeframes
• 6.4.1 — Public-facing web apps protected against known attacks (WAF or code review)
• 6.4.2 — Public-facing web apps have automated technical solution to detect and prevent web-based attacks (WAF in blocking mode)
• 6.4.3 — All payment page scripts managed, authorized, and integrity-ensured
• 6.5.1-6.5.6 — Change management procedures for all CDE system changes

Implementation Guidance:

• Implement SDLC with security gates (design review, code review, security testing)
• Train developers annually on secure coding (OWASP Top 10, CWE/SANS Top 25)
• Deploy WAF in blocking mode for all public-facing payment applications
• Patch critical vulnerabilities within 30 days, high within 60 days
• Implement Content Security Policy (CSP) and Subresource Integrity (SRI) for payment pages
• Monitor and authorize all JavaScript on payment pages (6.4.3 is critical for e-commerce)
• Conduct code reviews (manual or automated SAST) for all custom payment code
• Maintain complete software inventory with versions

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Objective: Limit access to CHD to only those with a legitimate business need.

Key Sub-Requirements:

• 7.2.1 — Access control model defined and includes all system components
• 7.2.2 — Access assigned based on job classification and function
• 7.2.3 — Required privileges approved by authorized personnel
• 7.2.4 — All user accounts and related access privileges reviewed at least every 6 months
• 7.2.5 — All application and system accounts assigned and managed based on least privilege
• 7.2.5.1 — Access for application and system accounts reviewed periodically
• 7.2.6 — All user access to query repositories of stored CHD is restricted

Implementation Guidance:

• Implement role-based access control (RBAC) for all CDE systems
• Document access control policy with defined roles and permissions
• Enforce least privilege — users get minimum access needed
• Review all CDE access every 6 months and recertify
• Restrict database query access to CHD (no ad hoc SELECT * from card_data)
• Separate duties — no single person should control all aspects of a transaction
• Use automated identity governance for access provisioning and reviews

Requirement 8: Identify Users and Authenticate Access to System Components

Objective: Ensure all access to CDE is identified and strongly authenticated.

Key Sub-Requirements:

• 8.2.1 — All users assigned a unique ID before access
• 8.2.2 — Group, shared, or generic accounts not used (exceptions must be documented)
• 8.3.1 — All user access to CDE authenticated with at least one factor
• 8.3.2 — Strong cryptography used for all authentication factors
• 8.3.4 — Invalid authentication attempts limited (lockout after max 10 attempts for min 30 minutes)
• 8.3.6 — New passwords/passphrases: minimum 12 characters (or 8 if system cannot support 12), containing both numeric and alphabetic
• 8.3.9 — Passwords/passphrases changed at least every 90 days (or continuous risk-based approach)
• 8.4.1 — MFA implemented for all non-console access into CDE for administrative access
• 8.4.2 — MFA implemented for all access into the CDE
• 8.4.3 — MFA for all remote network access originating from outside the entity's network
• 8.5.1 — MFA implementation not susceptible to replay attacks, cannot be bypassed
• 8.6.1 — Interactive login for system/service accounts managed, disabled when not needed
• 8.6.2 — Passwords/passphrases for system/service accounts not hard-coded in scripts
• 8.6.3 — Passwords/passphrases for system/service accounts changed periodically and upon suspicion of compromise

Implementation Guidance:

• MFA is mandatory for ALL access into the CDE (not just admin) — this is a v4.0 change
• Use phishing-resistant MFA (FIDO2/WebAuthn, hardware keys) where possible
• Minimum 12-character passwords with complexity requirements
• Implement account lockout after 10 failed attempts
• Never use shared accounts in the CDE
• Manage service accounts — no hard-coded passwords, rotate periodically
• Deploy PAM for administrative access to CDE systems
• Log all authentication events and integrate with SIEM

Requirement 9: Restrict Physical Access to Cardholder Data

Objective: Prevent unauthorized physical access to systems that store, process, or transmit CHD.

Key Sub-Requirements:

• 9.2.1 — Appropriate facility entry controls for CDE
• 9.2.3 — Physical access to wireless access points, gateways, and networking devices restricted
• 9.2.4 — Console access to sensitive areas controlled
• 9.3.1 — Authorization for physical access reviewed at least every 6 months
• 9.3.2 — Procedures for visitor identification and management
• 9.3.3 — Visitor badges or identification surrendered upon departure
• 9.4.1 — Media with CHD physically secured
• 9.4.5 — Inventory of electronic media with CHD maintained
• 9.4.6 — Hard-copy materials with CHD destroyed when no longer needed (cross-cut shred, incinerate)
• 9.4.7 — Electronic media with CHD rendered unrecoverable (degauss, crypto-erase, destroy)
• 9.5.1 — POI (Point of Interaction) devices protected from tampering and substitution

Implementation Guidance:

• Implement badge access to server rooms and data centers housing CDE
• Deploy CCTV with 90-day retention for CDE physical locations
• Maintain visitor logs with escort requirements
• Inspect POS terminals regularly for skimming devices (daily/weekly)
• Cross-cut shred all paper containing CHD
• Cryptographically erase or physically destroy media before disposal
• Restrict access to network infrastructure components

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Objective: Create comprehensive audit trails for all access to CDE and CHD.

Key Sub-Requirements:

• 10.2.1 — Audit logs capture all individual user access to CHD
• 10.2.1.1 — Audit logs capture all individual access to CHD
• 10.2.1.2 — All actions by any individual with administrative access are logged
• 10.2.1.3 — Access to all audit logs
• 10.2.1.4 — Invalid logical access attempts
• 10.2.1.5 — Changes to identification and authentication mechanisms
• 10.2.1.6 — Initialization, stopping, or pausing of audit logs
• 10.2.1.7 — Creation and deletion of system-level objects
• 10.2.2 — Audit logs include required details (user ID, event type, date/time, success/failure, origin, data/component affected)
• 10.3.1 — Read access to audit logs is restricted
• 10.3.2 — Audit log files are protected from modification
• 10.3.3 — Audit log files are backed up to a central log server
• 10.3.4 — File integrity monitoring on audit logs
• 10.4.1 — Audit logs reviewed at least daily for security events
• 10.4.1.1 — Automated mechanisms perform audit log reviews
• 10.4.2 — Logs of all CDE components are reviewed periodically
• 10.5.1 — Retain audit log history for at least 12 months (3 months immediately available)
• 10.6.1 — System clocks synchronized using NTP
• 10.6.2 — Time data protected
• 10.6.3 — Time settings received from industry-accepted sources

Implementation Guidance:

• Deploy SIEM for centralized log collection and automated review
• Log all access to CHD, administrative actions, and security events
• Protect log integrity with WORM storage or blockchain-based logging
• Retain logs for 12 months minimum (3 months online, remainder archived)
• Synchronize all system clocks to NTP (stratum 2 or better)
• Review logs daily using automated correlation rules
• Alert on suspicious patterns (multiple failed logins, after-hours access, bulk data access)

Requirement 11: Test Security of Systems and Networks Regularly

Objective: Regularly test security controls, systems, and networks to verify they work.

Key Sub-Requirements:

• 11.2.1 — Authorized and unauthorized wireless access points managed
• 11.2.2 — Wireless analyzer scans at least quarterly
• 11.3.1 — Internal vulnerability scans at least quarterly
• 11.3.1.1 — All other applicable vulnerabilities (non-critical/high) addressed and rescanned
• 11.3.1.3 — Internal scans after significant changes
• 11.3.2 — External vulnerability scans by ASV at least quarterly
• 11.4.1 — External penetration testing at least annually and after significant changes
• 11.4.3 — Internal penetration testing at least annually and after significant changes
• 11.4.4 — Vulnerabilities found during penetration testing are corrected
• 11.4.5 — Network segmentation tested at least annually (every 6 months for service providers)
• 11.5.1 — IDS/IPS deployed to monitor traffic into and within CDE
• 11.5.1.1 — IDS/IPS alerts generated for suspected compromises
• 11.5.2 — Change-detection mechanism (file integrity monitoring) deployed on critical files
• 11.6.1 — A change and tamper-detection mechanism deployed for payment pages

Implementation Guidance:

• Quarterly internal vulnerability scans with all high/critical resolved before pass
• Quarterly external ASV scans (must achieve passing scan)
• Annual external and internal penetration tests (by qualified tester)
• Pen tests must test network layer and application layer
• Deploy IDS/IPS at CDE perimeter and critical internal points
• FIM on critical system files, configuration files, and content files
• Wireless scanning quarterly to detect rogue access points
• Test network segmentation annually to verify CDE isolation
• Deploy change/tamper detection on payment page scripts (ties to 6.4.3)

Requirement 12: Support Information Security with Organizational Policies and Programs

Objective: Maintain an information security policy that addresses all PCI DSS requirements.

Key Sub-Requirements:

• 12.1.1 — Information security policy established, published, maintained, disseminated
• 12.1.2 — Roles and responsibilities defined for all requirements
• 12.1.3 — Information security policy reviewed at least annually
• 12.2.1 — Acceptable use policies for end-user technologies
• 12.3.1 — Targeted risk analysis for each requirement with customized approach flexibility
• 12.3.2 — Targeted risk analysis for each requirement met with customized approach
• 12.4.1 — Executive management establishes responsibility for protection of CHD
• 12.4.2 — Reviews performed at least quarterly (service providers: operations compliance)
• 12.5.1 — PCI DSS scope documented and confirmed annually
• 12.5.2 — PCI DSS scope documented and confirmed upon significant changes
• 12.5.3 — Significant changes resulting in scope changes trigger assessment
• 12.6.1 — Security awareness program implemented
• 12.6.2 — Awareness program reviewed at least annually
• 12.6.3 — Personnel receive awareness training upon hire and at least annually
• 12.6.3.1 — Training includes awareness of threats (phishing, social engineering)
• 12.8.1-12.8.5 — TPSPs (Third-Party Service Providers) managed
• 12.9.1 — TPSPs acknowledge responsibility for CHD security
• 12.10.1 — Incident response plan created and ready for activation
• 12.10.2 — IRP reviewed and tested at least annually
• 12.10.4 — Personnel with incident response responsibilities are trained
• 12.10.5 — IRP includes monitoring and responding to alerts
• 12.10.6 — IRP is updated based on lessons learned and industry developments
• 12.10.7 — Incident response procedures are in place to respond to detection of stored PAN anywhere not expected

Implementation Guidance:

• Create comprehensive security policy covering all 12 requirements
• Conduct targeted risk analysis for any customized approach implementations
• Confirm PCI DSS scope annually and after any significant changes
• Deliver security awareness training at hire and annually
• Include phishing awareness, social engineering, and CHD handling in training
• Manage all third-party service providers (maintain list, require compliance attestation)
• Maintain and test incident response plan at least annually
• Include specific procedures for unauthorized PAN discovery

v4.0 Changes from v3.2.1

Major Changes

1. Customized Approach (NEW) Organizations can now meet PCI DSS requirements using a "customized approach" rather than the traditional "defined approach." This allows organizations to design their own security controls, provided they meet the security objective of each requirement. Requires targeted risk analysis documentation and validation by QSA.

2. Targeted Risk Analysis v4.0 requires organizations to perform documented, targeted risk analyses for certain requirements (e.g., frequency of activities, password/passphrase policies). This replaces the "one-size-fits-all" approach.

3. Enhanced Authentication Requirements

• MFA required for ALL access into the CDE (not just remote admin)
• Minimum password length increased to 12 characters (from 7)
• 90-day password rotation or continuous risk-based authentication

4. Payment Page Script Security (6.4.3) All scripts on payment pages must be managed, authorized, and monitored for integrity. This addresses Magecart-style attacks.

5. Anti-Phishing Mechanisms (5.4.1) Organizations must implement automated anti-phishing mechanisms (e.g., DMARC, email sandbox).

6. Encryption of PAN Over Trusted Internal Networks (4.2.1) PAN must now be encrypted during transmission over ALL networks, not just public networks. Internal network encryption required.

7. Automated Log Review (10.4.1.1) Automated mechanisms must perform audit log reviews — manual-only review no longer sufficient.

Summary of Future-Dated Requirements (Now Mandatory)

All of the following became mandatory as of March 31, 2025:

Cardholder Data Environment Scoping

CDE Definition

The Cardholder Data Environment (CDE) includes:

1. System components that store, process, or transmit CHD/SAD — These are directly in scope
2. System components on the same network segment — These are in scope unless segmented
3. System components that connect to or provide security services — Connected-to and security-impacting systems

System Classification

Scope Reduction Strategies

1. Tokenization: Replace PAN with non-reversible tokens. Systems that only handle tokens are out of scope.

2. P2PE (Point-to-Point Encryption): Validated P2PE solutions encrypt cardholder data at the point of interaction. Merchants using validated P2PE can use SAQ P2PE (reduced scope).

3. Network Segmentation: Isolate CDE on a separate network segment with firewalls and strict access controls. Non-CDE segments are out of scope.

4. Outsource Processing: Use third-party payment processors (Stripe, Braintree, Adyen) to handle all CHD. The merchant never touches cardholder data.

5. iFrame/Redirect: For e-commerce, use the payment processor's hosted payment page (iFrame or redirect). The merchant's systems never receive cardholder data.

SAQ Types and Selection Guide

Self-Assessment Questionnaires (SAQs) are validation tools for merchants and service providers not required to undergo a full on-site assessment (ROC).

SAQ Selection Decision Tree

Does your organization store, process, or transmit CHD?
├── No → Not subject to PCI DSS
└── Yes → Continue
    │
    Are you a Service Provider?
    ├── Yes → SAQ D (Service Provider) or ROC
    └── No (Merchant) → Continue
        │
        Do you store CHD electronically?
        ├── Yes → SAQ D (Merchant)
        └── No → Continue
            │
            E-commerce only?
            ├── Yes → Do you fully outsource all payment processing?
            │   ├── Yes (iFrame/redirect, no scripts on payment page) → SAQ A
            │   └── No (payment page on your server or scripts affecting payment) → SAQ A-EP
            ├── Card-present (POS)?
            │   ├── Using validated P2PE? → SAQ P2PE
            │   ├── Standalone dial-out terminal? → SAQ B
            │   ├── Standalone IP-connected terminal? → SAQ B-IP
            │   └── Payment application system? → SAQ C
            └── Virtual terminal only? → SAQ C-VT

Assessment Types

Self-Assessment Questionnaire (SAQ)

Who: Level 2-4 merchants (unless acquirer requires ROC) What: Self-assessment using applicable SAQ type Frequency: Annual Output: Completed SAQ + Attestation of Compliance (AOC)

Report on Compliance (ROC)

Who: Level 1 merchants, all Level 1 service providers What: On-site assessment by Qualified Security Assessor (QSA) Frequency: Annual Output: ROC document + AOC

Attestation of Compliance (AOC)

Who: All entities, accompanies SAQ or ROC What: Executive summary confirming compliance status Frequency: Annual, accompanies assessment Output: Signed AOC form

Merchant and Service Provider Levels

Merchant Levels

Note: Card brands and acquirers may have different thresholds. Check with your acquirer.

Service Provider Levels

Infrastructure Controls

Network Segmentation Validation

Purpose: Verify CDE is properly isolated from non-CDE networks.

Testing Methods:

• Firewall rule review — verify only approved traffic can cross CDE boundary
• Penetration testing from non-CDE segments attempting to reach CDE
• Traffic analysis confirming no unintended data flows
• VLAN hopping tests
• ARP spoofing tests

Frequency: Annually (every 6 months for service providers)

DNS Security for Payment Systems

• Implement DNSSEC for all CDE domain names
• Use internal DNS servers for CDE (not public resolvers)
• Monitor DNS queries from CDE for data exfiltration indicators
• Restrict CDE DNS queries to approved destinations only
• Implement DNS sinkholing for known malicious domains

TLS Configuration for Payment Channels

• Minimum TLS 1.2, prefer TLS 1.3 for all payment communications
• Strong cipher suites only: ECDHE key exchange, AES-GCM
• HSTS with long max-age on all payment-related web pages
• Certificate transparency monitoring for payment domains
• Automated certificate renewal (Let's Encrypt, ACME protocol)
• mTLS between CDE microservices
• Certificate pinning for mobile payment applications

Endpoint Security for POS Systems

• Harden POS operating systems (application allowlisting)
• Deploy endpoint protection with anti-tamper capabilities
• Implement POS-specific network segmentation
• Regular POS terminal inspection for skimming devices
• Remote POS management via encrypted channels only
• Disable USB ports and external interfaces on POS terminals
• Monitor POS terminal integrity

Cloud Security for Payment Processing

AWS:

• Use VPC with private subnets for CDE workloads
• AWS KMS or CloudHSM for encryption key management
• GuardDuty for threat detection in CDE
• Config rules for CDE compliance monitoring
• S3 bucket policies preventing public access to CHD
• Restrict IAM roles accessing CDE resources

Azure:

• Azure Virtual Network with NSGs for CDE isolation
• Azure Key Vault (HSM-backed) for key management
• Microsoft Defender for Cloud for CDE monitoring
• Azure Policy for CDE compliance enforcement
• Storage Service Encryption with customer-managed keys

GCP:

• VPC Service Controls for CDE isolation
• Cloud KMS or Cloud HSM for key management
• Security Command Center for CDE visibility
• Organization policies restricting CDE resource configuration
• BigQuery with column-level encryption for analytics on payment data

Container/Kubernetes Security in CDE

• Scan container images for vulnerabilities before deployment
• Use private container registries with signed images
• Implement Kubernetes RBAC with CDE-specific namespaces
• Pod Security Standards (Restricted) for CDE pods
• Network policies isolating CDE pods
• No privileged containers in CDE
• Secrets management via external vault (not Kubernetes secrets)
• Service mesh (Istio, Linkerd) with mTLS for CDE pod-to-pod traffic
• Runtime security monitoring (Falco, Sysdig)

API Security for Payment APIs

• OAuth 2.0 / OpenID Connect for API authentication
• API rate limiting and throttling
• Input validation and output encoding for all API parameters
• API gateway with WAF protection
• API versioning with deprecated version retirement
• Mutual TLS for server-to-server API calls
• PCI-compliant API logging (mask PAN in logs)
• API security testing (DAST) in CI/CD pipeline

Tokenization Architecture

┌───────────────┐     ┌──────────────────┐     ┌────────────────┐
│   Customer     │────▶│   Payment Page    │────▶│ Token Service  │
│   (Browser)    │     │   (Merchant)      │     │ (Processor)    │
└───────────────┘     └──────────────────┘     └──────┬─────────┘
                                                       │
                                              ┌────────▼────────┐
                                              │   Token Vault    │
                                              │   (PAN → Token)  │
                                              └────────┬────────┘
                                                       │
                                              ┌────────▼────────┐
                                              │  Card Network    │
                                              │  (Detokenize)    │
                                              └─────────────────┘

Key Points:

• Token format should be indistinguishable from PAN (same length, passes Luhn check is optional)
• Token vault must be PCI DSS compliant
• Tokens should be non-reversible without access to the vault
• Use format-preserving tokens when legacy systems require card-like values

Encryption Key Management

DUKPT (Derived Unique Key Per Transaction):

• Used in POS environments
• Each transaction uses a unique encryption key
• Derived from a Base Derivation Key (BDK)
• Protects against mass compromise from single key exposure

P2PE (Point-to-Point Encryption):

• Encrypts at the terminal (point of

…(truncated)