PCI-DSS v4.0 Requirements Reference

---

name: pci-dss-v4 description: PCI-DSS v4.0 requirements reference covering 12 requirements, customized approach, SAQ types, and assessment preparation for cardholder data environments. tags: [compliance, security]

PCI-DSS v4.0 Requirements Reference

Overview

The Payment Card Industry Data Security Standard (PCI-DSS) version 4.0 is a set of security requirements designed to protect cardholder data and sensitive authentication data wherever it is processed, stored, or transmitted. Released in March 2022 by the PCI Security Standards Council (PCI SSC), v4.0 replaces v3.2.1 with a transition deadline of March 31, 2025 for mandatory adoption.

PCI-DSS v4.0 introduces significant changes:

• Customized Approach: Organizations can meet requirement objectives using alternative controls, validated through a risk-based methodology.
• Targeted Risk Analysis: Several requirements now allow organizations to define frequencies based on their own risk analysis rather than fixed intervals.
• Enhanced Authentication: Expanded MFA requirements beyond just remote access.
• Future-Dated Requirements: 51 new requirements that become mandatory on March 31, 2025.
• Evolved Requirements: Existing requirements updated for clarity and modern threats.

The standard applies to all entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), and to entities that can affect the security of the cardholder data environment (CDE).

When to Use This Skill

• Determining PCI-DSS scope for a new payment processing implementation.
• Transitioning from PCI-DSS v3.2.1 to v4.0.
• Selecting the appropriate Self-Assessment Questionnaire (SAQ) type.
• Implementing the customized approach for specific requirements.
• Preparing for a Qualified Security Assessor (QSA) on-site assessment.
• Evaluating third-party service provider PCI compliance (AOCs and responsibility matrices).
• Building or reviewing network segmentation for CDE isolation.

How It Works

Step 1: Determine Scope

Identify all system components, people, and processes that are in scope:

• Cardholder Data Environment (CDE): Systems that store, process, or transmit CHD/SAD.
• Connected-to systems: Systems with direct connectivity to the CDE.
• Security-impacting systems: Systems that could affect CDE security (DNS, NTP, logging).
• Segmentation controls: Firewalls, routers, and VLANs that isolate the CDE.
• Scope reduction: Use tokenization, P2PE, and network segmentation to minimize scope.

Step 2: Select SAQ Type

Choose the appropriate Self-Assessment Questionnaire based on your processing method:

SAQ Type	Description	Applicability
SAQ A	Card-not-present, fully outsourced	E-commerce with redirect (Stripe Checkout, PayPal)
SAQ A-EP	E-commerce with partial outsourcing	Website controls payment page elements
SAQ B	Imprint machines or standalone terminals	No electronic CHD storage
SAQ B-IP	Standalone PTS terminals with IP connection	PIN entry devices, no CHD storage
SAQ C	Payment application systems	Internet-connected payment applications
SAQ C-VT	Virtual terminal, manual entry	Web-based virtual terminal, one transaction at a time
SAQ D	All others	Merchants/service providers not qualifying for other SAQs
SAQ P2PE	Hardware P2PE terminal	Validated P2PE solution, no electronic CHD storage

Step 3: Map Requirements to Controls

For each of the 12 PCI-DSS requirements, map your existing controls and identify gaps. Use either the Defined Approach (prescriptive controls) or Customized Approach (objective-based).

Step 4: Implement Controls

Deploy technical and operational controls to meet each requirement:

• Prioritize based on risk and gap severity.
• Address future-dated requirements proactively.
• Document all controls with implementation evidence.
• Implement continuous monitoring where required.

Step 5: Complete Assessment

Execute the assessment process:

• SAQ: Complete the self-assessment questionnaire with supporting evidence.
• ROC: For Level 1 merchants/service providers, engage a QSA for Report on Compliance.
• AOC: Sign and submit the Attestation of Compliance.
• ASV scans: Ensure quarterly external vulnerability scans pass (performed by Approved Scanning Vendor).
• Penetration test: Annual internal and external penetration test of the CDE.

The 12 PCI-DSS Requirements by Goal

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

• Define and enforce network security controls (firewalls, cloud security groups).
• Document all connections to and from the CDE.
• Restrict inbound and outbound traffic to that which is necessary.
• Review firewall/router rule sets every six months.
• v4.0 change: "Firewalls" generalized to "network security controls" for cloud environments.

Requirement 2: Apply Secure Configurations to All System Components

• Change vendor defaults (passwords, accounts, configurations).
• Develop configuration standards for all system components.
• Encrypt non-console administrative access.
• Maintain an inventory of system components in scope.
• v4.0 change: Expanded to explicitly cover all system components, not just vendor defaults.

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data

• Keep cardholder data storage to a minimum; implement retention and disposal policies.
• Do not store sensitive authentication data (SAD) after authorization.
• Mask PAN when displayed (first 6, last 4 maximum).
• Render PAN unreadable anywhere it is stored (encryption, truncation, tokenization, hashing).
• Document and manage all encryption keys with defined cryptoperiods.
• v4.0 change: Disk-level encryption no longer acceptable as sole encryption mechanism for PAN.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

• Use strong cryptography (TLS 1.2+) for transmission over open, public networks.
• Do not send unencrypted PAN via end-user messaging technologies.
• Document all trusted keys and certificates.
• v4.0 change: Requirement now covers all networks, not just "public" networks; clarified that TLS 1.0/1.1 are no longer acceptable.

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

• Deploy anti-malware on all systems commonly affected by malware.
• Ensure anti-malware is current, performs periodic scans, and generates audit logs.
• Protect against phishing attacks.
• v4.0 change: Added phishing protection (anti-phishing mechanisms); anti-malware applies to all system types, with targeted risk analysis for those not commonly affected.

Requirement 6: Develop and Maintain Secure Systems and Software

• Establish a patch management process; install critical patches within one month.
• Identify and manage vulnerabilities through a defined process.
• Develop software securely (secure coding guidelines, code reviews, SAST/DAST).
• Protect web-facing applications (WAF or automated vulnerability assessment).
• v4.0 change: Added requirements for managing bespoke and custom software vulnerabilities; automated WAF inspection now an option; inventory of bespoke software required.

Goal 4: Implement Strong Access Control Measures

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

• Define access control policies based on job function and least privilege.
• Restrict access to system components and CHD based on business need.
• Review all user access every six months.
• v4.0 change: Requirement applies to all system components, not just cardholder data.

Requirement 8: Identify Users and Authenticate Access to System Components

• Assign unique IDs to all users; no shared or generic accounts.
• Implement MFA for all access into the CDE (expanded from just remote access in v3.2.1).
• Enforce password/passphrase minimum of 12 characters (increased from 7).
• Manage system and application accounts with controlled privileges.
• v4.0 change: MFA required for all CDE access; password minimum increased to 12; MFA for all non-console admin access; service accounts must be managed and inventoried.

Requirement 9: Restrict Physical Access to Cardholder Data

• Use physical access controls to limit access to the CDE.
• Identify and distinguish between onsite personnel and visitors.
• Secure all media containing cardholder data.
• Destroy media when it is no longer needed.

Goal 5: Regularly Monitor and Test Networks

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

• Implement audit trails for all access to CDE components.
• Record auditable events (user access, actions, failures, privilege changes).
• Synchronize all system clocks using NTP.
• Secure audit trails so they cannot be altered.
• Review logs daily using automated mechanisms.
• Retain audit trail history for at least 12 months (3 months immediately available).
• v4.0 change: Automated log review mechanisms required; targeted risk analysis to define review frequency for other logs.

Requirement 11: Test Security of Systems and Networks Regularly

• Perform quarterly ASV scans and rescan until passing.
• Conduct internal and external penetration testing annually and after significant changes.
• Deploy intrusion detection/prevention (IDS/IPS) to monitor CDE traffic.
• Implement a change detection mechanism (file integrity monitoring).
• v4.0 change: Added authenticated internal vulnerability scanning; IDS/IPS or equivalent required; penetration testing methodology must cover entire CDE perimeter.

Goal 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs

• Establish and publish an information security policy reviewed annually.
• Implement a risk assessment process performed annually and upon significant changes.
• Define security awareness training for all personnel.
• Screen personnel prior to hire.
• Manage service providers with contracts and compliance monitoring.
• Implement an incident response plan and test it annually.
• v4.0 change: Targeted risk analysis documented for requirements with flexible frequency; senior management accountability for PCI-DSS compliance program.

Key Changes from v3.2.1 to v4.0

Area	v3.2.1	v4.0
Approach	Defined Approach only	Defined Approach + Customized Approach
MFA scope	Remote access only	All access into the CDE
Password length	7 characters minimum	12 characters minimum
Disk encryption	Acceptable for PAN	No longer sole mechanism
Log review	Daily manual review	Automated mechanisms required
Risk analysis	Limited use	Targeted risk analysis for flexible frequencies
WAF	Required for web apps	WAF or automated vulnerability solution
Phishing	Not explicitly addressed	Anti-phishing mechanisms required
Service accounts	Limited coverage	Full inventory and management required

Examples

Example 1: Network Segmentation Validation

cde_segmentation:
  description: "Network segmentation controls isolating the CDE"
  last_validated: "2026-02-15"
  validation_method: "Penetration test + firewall rule review"

  cde_network:
    subnet: "10.100.0.0/24"
    vlan: 100
    components:
      - name: "payment-api"
        ip: "10.100.0.10"
        function: "Processes card transactions via Stripe API"
        stores_chd: false
        transmits_chd: true
      - name: "tokenization-service"
        ip: "10.100.0.20"
        function: "Tokenizes PAN before storage"
        stores_chd: false  # Only tokens stored
        transmits_chd: true

  segmentation_controls:
    - control: "Firewall between CDE (VLAN 100) and corporate (VLAN 200)"
      type: "network_security_control"
      rules:
        - direction: inbound
          source: "10.200.0.0/24"
          destination: "10.100.0.0/24"
          action: deny_all
          exceptions:
            - port: 443
              source: "10.200.0.50"  # Admin jump box only
              protocol: tcp
              justification: "Administrative access with MFA"
        - direction: outbound
          source: "10.100.0.0/24"
          destination: "0.0.0.0/0"
          action: deny_all
          exceptions:
            - port: 443
              destination: "api.stripe.com"
              protocol: tcp
              justification: "Payment processor API"
            - port: 443
              destination: "10.200.0.30"  # Log collector
              protocol: tcp
              justification: "Centralized audit logging"

    - control: "Cloud security groups (AWS)"
      type: "network_security_control"
      rules:
        - sg_name: "cde-payment-api-sg"
          inbound:
            - port: 443
              source: "sg-alb-internal"
              justification: "Internal ALB for payment traffic"
          outbound:
            - port: 443
              destination: "pl-stripe-api"  # AWS prefix list
              justification: "Stripe API calls"

  validation_results:
    penetration_test_date: "2026-02-10"
    assessor: "External QSA firm"
    findings:
      - severity: "pass"
        description: "No unauthorized connectivity from corporate to CDE"
      - severity: "pass"
        description: "CDE egress restricted to documented destinations only"
      - severity: "info"
        description: "Recommend adding network flow logging for CDE subnets"

Example 2: Encryption Requirements for Cardholder Data

encryption_requirements:
  standard: "PCI-DSS v4.0"
  last_reviewed: "2026-02-20"

  data_at_rest:
    requirement: "Req 3.5 -- PAN rendered unreadable anywhere stored"
    current_implementation:
      method: "Application-level encryption"
      algorithm: "AES-256-GCM"
      key_management:
        kms: "AWS KMS"
        key_type: "Customer-managed CMK"
        rotation: "Annual automatic rotation"
        split_knowledge: true
        dual_control: true
      note: >
        Disk-level encryption (e.g., EBS encryption) is used as defense-in-depth
        but is NOT the sole mechanism per PCI-DSS v4.0 Req 3.5.1.2.

    tokenization:
      provider: "Stripe"
      method: "Payment method tokenization"
      pan_stored: false
      token_format: "tok_xxxxxxxxxxxx"
      note: "PAN never enters our systems; only tokens stored in application DB"

  data_in_transit:
    requirement: "Req 4.2 -- Strong cryptography during transmission"
    current_implementation:
      external:
        protocol: "TLS 1.3"
        cipher_suites:
          - "TLS_AES_256_GCM_SHA384"
          - "TLS_CHACHA20_POLY1305_SHA256"
        certificate_provider: "AWS ACM"
        hsts: true
        hsts_max_age: 31536000
      internal:
        protocol: "mTLS (mutual TLS 1.3)"
        service_mesh: "Istio"
        certificate_authority: "Internal CA (cert-manager)"
        rotation: "Every 24 hours (automatic)"

  key_management:
    requirement: "Req 3.6 and 3.7 -- Key management procedures"
    procedures:
      - process: "Key generation"
        method: "AWS KMS hardware security module (FIPS 140-2 Level 3)"
      - process: "Key distribution"
        method: "KMS grants and key policies; keys never leave HSM boundary"
      - process: "Key storage"
        method: "AWS KMS (HSM-backed); no plaintext keys stored anywhere"
      - process: "Key rotation"
        method: "Annual automatic rotation; old key versions retained for decryption"
      - process: "Key destruction"
        method: "KMS key deletion with 30-day waiting period; logged and audited"
      - process: "Split knowledge / dual control"
        method: "Key policy requires 2 IAM principals from different teams to modify"

Best Practices

Do This

• Minimize scope aggressively using tokenization, P2PE, and network segmentation.
• Use the Customized Approach where your existing controls meet the objective differently.
• Conduct targeted risk analyses to justify flexible frequencies for applicable requirements.
• Treat PCI-DSS as a continuous program, not an annual assessment event.
• Engage your QSA early for scoping guidance before implementing controls.
• Use the PCI SSC's Prioritized Approach to focus on the highest-risk areas first.
• Document compensating controls thoroughly if you cannot meet a requirement directly.
• Automate ASV scanning and internal vulnerability scanning on continuous schedules.

Don't Do This

• Do not store sensitive authentication data (full track, CVV, PIN) after authorization -- ever.
• Do not rely solely on disk-level encryption to meet Requirement 3.5 (v4.0 change).
• Do not assume using a third-party payment processor eliminates all PCI-DSS obligations.
• Do not use TLS 1.0 or 1.1; only TLS 1.2+ is acceptable.
• Do not share credentials or use generic accounts in the CDE.
• Do not skip the segmentation validation; it is critical to scope reduction claims.
• Do not ignore future-dated requirements; plan implementation before they become mandatory.

Security Checklist

Scoping:

• CDE boundaries documented with data flow diagrams
• All system components in scope identified and inventoried
• Network segmentation validated by penetration test
• Third-party service providers identified with PCI compliance status
• SAQ type determined or ROC requirement confirmed

Network and Systems (Req 1-2):

• Network security controls (firewalls/security groups) configured and rule sets reviewed
• Default passwords changed on all system components
• Configuration standards established and applied
• Non-console administrative access encrypted

Data Protection (Req 3-4):

• PAN rendered unreadable in storage (application-level encryption or tokenization)
• No SAD stored after authorization
• Strong cryptography (TLS 1.2+) for all CHD transmission
• Key management procedures documented and followed

Vulnerability Management (Req 5-6):

• Anti-malware deployed and current on all applicable systems
• Anti-phishing mechanisms implemented
• Critical patches installed within one month of release
• Secure software development lifecycle implemented
• Web applications protected by WAF or automated vulnerability solution

Access Control (Req 7-9):

• Access restricted by business need to know with least privilege
• Unique IDs assigned to all users; no shared accounts
• MFA enforced for all access into the CDE
• Passwords minimum 12 characters
• Physical access to CDE restricted and monitored

Monitoring and Testing (Req 10-11):

• Audit logging enabled for all CDE components with 12-month retention
• Automated log review mechanisms operational
• Quarterly ASV scans passing
• Annual penetration testing completed
• IDS/IPS monitoring CDE network traffic
• File integrity monitoring deployed

Policy and Program (Req 12):

• Information security policy published and reviewed annually
• Risk assessment performed annually
• Security awareness training completed by all personnel
• Incident response plan documented and tested annually
• Service provider compliance monitored and AOCs collected

Related Skills

• @compliance-crosswalk -- Map PCI-DSS requirements to NIST CSF, SOC 2, and ISO 27001 controls.
• @nist-csf -- Align PCI-DSS controls with NIST Cybersecurity Framework functions.
• @api-security-patterns -- Implement secure API design for payment processing endpoints.

Additional Resources

• PCI-DSS v4.0 Standard -- Official standard document.
• PCI DSS v4.0 Summary of Changes -- Detailed change tracking from v3.2.1.
• PCI SSC Prioritized Approach -- Phased implementation guide.
• PCI DSS Scoping and Segmentation Guidance -- Official scoping methodology.
• PCI SSC Cloud Computing Guidelines -- Cloud-specific PCI considerations.