PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards developed by major payment card brands including Visa, Mastercard, American Express, Discover, and JCB International. Originally introduced in 2004, this standard is governed by the Payment Card Industry Security Standards Council (PCI SSC) to ensure the protection of cardholder data across the entire payment ecosystem.
Organizations should think of it as traffic signals for handling card data, ensuring it flows smoothly and securely. Businesses that accept, transmit, or store card information, regardless of transaction volume, need to comply to avoid hefty fines, card processing restrictions, and reputational damage.
Current version: PCI DSS v4.0.1 has been the mandatory standard since March 31, 2025. All future-dated requirements from v4.0 are now fully enforced, and every assessment is conducted against this version. The previous version (v3.2.1) was retired on March 31, 2024.
Following PCI DSS Compliance primarily helps in 3 things;
- Prevent data breaches and leaks of sensitive cardholder information.
- Minimize the risk of fraud and financial loss for both businesses and customers.
- Maintain trust with customers by demonstrating a commitment to data security.
What changed in PCI DSS v4.0 and v4.0.1
PCI DSS v4.0 was published in March 2022 and introduced 64 new or updated requirements compared to v3.2.1. A clarifying revision, v4.0.1, was released in June 2024 with corrections and clearer wording but no additional or deleted requirements. Here are the most significant changes compliance officers and engineering teams need to understand:
Customized Approach for Validation
One of the most impactful changes is the introduction of the Customized Approach. Organizations can now meet a requirement’s security objective using alternate controls rather than strictly following the prescribed (Defined) approach. This provides flexibility for companies with mature security programs to implement innovative solutions, provided they can demonstrate equivalent security through a targeted risk analysis.
Expanded Multi-Factor Authentication (MFA)
MFA is no longer limited to remote access into the cardholder data environment (CDE). Under v4.0, MFA is required for all access to the CDE, including local/console access. This significantly broadens the scope of authentication controls.
Targeted Risk Analysis
Several requirements now allow organizations to perform their own targeted risk analysis to determine the frequency of certain activities (such as log reviews, password rotations, or vulnerability scans) rather than following rigid prescribed frequencies. This empowers organizations to calibrate controls based on their specific threat landscape.
Client-Side Security (Requirement 6.4.3)
A critical new requirement addresses payment page script security. Organizations must implement mechanisms to manage and monitor all payment page scripts (JavaScript) that are loaded and executed in the consumer’s browser. This directly combats web skimming attacks like Magecart and formjacking. Requirements include:
- Maintaining an inventory of all scripts on payment pages
- Ensuring each script is authorized and has integrity verification
- Implementing a method to confirm scripts have not been tampered with
Anti-Phishing and Social Engineering (Requirement 5.4.1)
PCI DSS v4.0 now mandates automated anti-phishing mechanisms to detect and protect personnel against phishing attacks. Security awareness training alone no longer satisfies this requirement. Organizations must implement technical controls such as DMARC, SPF, and DKIM for email authentication, along with anti-phishing tools that provide automated detection and prevention.
Additional Key Changes
- Passwords/passphrases: Minimum length increased to 12 characters (up from 7 in v3.2.1)
- Automated log review: Organizations must implement automated mechanisms for reviewing audit logs
- Authenticated vulnerability scanning: Internal vulnerability scans must be performed with authentication
- Full disk encryption ban for CDE: Full disk encryption (FDE) alone is no longer acceptable for protecting stored cardholder data; volume or file-level encryption is required
- Continuous security focus: Shift from point-in-time compliance to continuous security posture management
PCI DSS 12 Requirements for Handling Cardholder Data
The 12 core requirements remain the same in number under v4.0, but their content has expanded significantly. Here we discuss the key areas that build the foundation for PCI DSS compliance.
Cardholder Data Protection
Encryption
- Encrypt cardholder data at rest using strong algorithms like AES-256. Note that full disk encryption alone is no longer sufficient under v4.0; use volume-level or file-level encryption.
- Encrypt data in transit using secure protocols like TLS 1.2 or higher (TLS 1.0 and 1.1 are no longer acceptable).
Secure Storage
- Implement secure storage methods like dedicated databases or hardware security modules (HSMs) for cardholder data.
- Restrict physical access to storage locations through appropriate security measures.
- Minimize stored data: retain only what is necessary and for the shortest duration needed.
Restricted Access
- Limit access to cardholder data to authorized personnel based on the principle of least privilege.
- Implement robust user access controls with strong authentication mechanisms including multi-factor authentication (MFA) for all CDE access.
Access Control Measures
Least Privilege
- Grant users only the minimum access permissions necessary to accomplish their job.
- Do not grant excessive privileges; reduce the potential impact of compromised accounts.
- Regularly review access rights to confirm ongoing business need.
Strong Authentication
- Implement multi-factor authentication (MFA) for all access to the cardholder data environment, not just remote access.
- Passwords/passphrases must be a minimum of 12 characters.
- MFA adds an extra layer of security, requiring additional verification beyond just a username and password.
Activity Monitoring
- Continuously monitor user activity within systems containing cardholder data.
- Implement automated mechanisms for reviewing audit logs rather than relying solely on manual review.
- Identify and investigate suspicious activity promptly to detect potential security incidents.
Secure Network Systems
Firewalls and Network Security Controls
- Implement network security controls (the term “firewalls” has been broadened in v4.0 to “network security controls”) to filter incoming and outgoing network traffic, blocking unauthorized access to sensitive systems.
- Regularly update rules and configurations to maintain effectiveness against evolving threats.
Intrusion Detection/Prevention Systems (IDS/IPS)
- Deploy IDS/IPS to detect and potentially block malicious activity on your network in real-time.
- These systems continuously monitor network traffic for suspicious behavior indicative of attacks.
Regular Security Assessments
- Conduct regular internal and external security assessments to identify vulnerabilities in your network infrastructure and applications.
- Internal vulnerability scans must now be performed with authentication (authenticated scanning).
- Proactively address identified vulnerabilities to prevent attackers from exploiting them.
Encrypted Data Transmission
Secure Protocols
- Require the use of TLS 1.2 or higher for all communication involving cardholder data.
- Older protocols like SSL and early TLS versions are explicitly prohibited.
Certificates and Validation
- Securely manage and validate digital certificates used for secure communication channels.
- Ensure only valid and trusted certificates are used to prevent potential man-in-the-middle attacks.
Data Minimization
- Collect, store, and transmit only the minimum amount of cardholder data necessary for business purposes.
- Reduce the attack surface by minimizing the amount of sensitive data readily available within your systems.
Client-Side and Payment Page Security
This is a new area of focus under v4.0 that is particularly relevant for e-commerce businesses.
Script Management (Requirement 6.4.3)
- Maintain a complete inventory of all scripts loaded on payment pages.
- Implement integrity verification for each authorized script (e.g., Subresource Integrity or Content Security Policy).
- Deploy monitoring to detect unauthorized changes to payment page scripts.
- This requirement directly addresses web skimming (Magecart-style) attacks.
HTTP Header Security (Requirement 11.6.1)
- Implement a change and tamper detection mechanism for HTTP headers and payment page content.
- Alert on unauthorized modifications that could indicate a compromise.
Anti-Phishing and Social Engineering Controls
Automated Anti-Phishing (Requirement 5.4.1)
- Deploy automated anti-phishing mechanisms (not just training) to protect personnel against phishing attacks.
- Implement email authentication protocols: DMARC, SPF, and DKIM.
- Use phishing detection tools that provide real-time analysis and blocking of suspicious content.
Tokenization, P2PE, and Scope Reduction
Modern approaches to PCI DSS compliance increasingly focus on reducing the cardholder data environment (CDE) scope. These technologies are now standard considerations for organizations processing card payments.
Tokenization
Tokenization replaces cardholder data with non-sensitive tokens that have no exploitable value if breached. Key considerations under v4.0:
- The tokenization system itself is part of the CDE and must be properly segmented.
- Out-of-scope systems must not be able to reach the token vault, keys, or de-tokenization services.
- Tokenization significantly reduces the number of systems in scope for PCI DSS, lowering compliance cost and complexity.
Point-to-Point Encryption (P2PE)
P2PE protects card data from the moment of capture (at the payment terminal) through decryption at the secure decryption environment. Benefits include:
- Merchants using a PCI-validated P2PE solution can use the simplified SAQ P2PE questionnaire.
- Dramatically reduces CDE scope because encrypted data cannot be decrypted within the merchant’s environment.
- Particularly effective for in-person/card-present transactions.
Cloud-Specific PCI Scoping
For organizations running workloads in the cloud, PCI DSS scoping requires careful consideration of the shared responsibility model:
- Cloud service providers (CSPs) may hold their own PCI DSS compliance (e.g., AWS, Azure, GCP are Level 1 service providers), but this does not automatically make your workloads compliant.
- You are responsible for controls within your layer (operating systems, applications, data, identity management).
- Hybrid and multi-cloud CDE environments are increasingly common and require proper network segmentation and micro-segmentation strategies.
- The PCI SSC published a Scoping and Segmentation Guidance for Modern Network Architectures supplement covering cloud, zero trust, and containerized environments.
Compliance Levels: Merchants and Service Providers
PCI DSS compliance requirements are divided based on the entity type and annual transaction volume.
Merchant Levels
Merchant classification is based on the annual number of card transactions processed:
Level 1: Merchants processing over 6 million card transactions annually
- Onsite assessment by an approved Qualified Security Assessor (QSA)
- Completion of a Report on Compliance (ROC)
- Quarterly network scans by an Approved Scanning Vendor (ASV)
Level 2: Merchants processing 1 to 6 million card transactions annually
- Annual completion of a Self-Assessment Questionnaire (SAQ)
- Quarterly network scans by an Approved Scanning Vendor (ASV)
- May be required to undergo an onsite assessment by a QSA at the discretion of the payment brands
Level 3: Merchants processing 20,000 to 1 million e-commerce transactions annually
- Annual completion of a Self-Assessment Questionnaire (SAQ)
- Quarterly network scans by an Approved Scanning Vendor (ASV)
Level 4: Merchants processing fewer than 20,000 e-commerce transactions or up to 1 million total transactions annually
- Annual completion of a Self-Assessment Questionnaire (SAQ)
- Quarterly network scans by an Approved Scanning Vendor (ASV)
- May be eligible for a simplified compliance process depending on payment acceptance method
Service Provider Levels
Service providers (entities that store, process, or transmit cardholder data on behalf of other businesses) have a separate two-level classification:
Level 1: Service providers processing over 300,000 transactions annually
- Annual onsite assessment by a QSA resulting in a Report on Compliance (ROC)
- Quarterly ASV scans
- Annual penetration testing
Level 2: Service providers processing fewer than 300,000 transactions annually
- Annual completion of SAQ-D for Service Providers
- Quarterly ASV scans
- Annual penetration testing
Self-Assessment Questionnaires (SAQs) Under v4.0.1
SAQs are validation tools provided by PCI SSC. Under v4.0.1, there are nine SAQ types, each designed for specific eligibility profiles based on payment acceptance channels and cardholder data handling:
| SAQ Type | Applicable To |
|---|---|
| SAQ A | E-commerce or mail/telephone-order merchants that fully outsource cardholder data functions (stricter eligibility under v4.0) |
| SAQ A-EP | E-commerce merchants with websites that redirect to or include payment pages from third-party processors |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals only |
| SAQ B-IP | Merchants using standalone IP-connected PTS-approved payment terminals |
| SAQ C | Merchants with payment applications connected to the internet |
| SAQ C-VT | Merchants manually entering transactions via virtual terminals |
| SAQ P2PE | Merchants using validated Point-to-Point Encryption (P2PE) solutions |
| SAQ D (Merchants) | All merchants not qualifying for another SAQ type |
| SAQ D (Service Providers) | All service providers eligible for SAQ-based validation |
Important: SAQ A eligibility has tightened under v4.0. E-commerce merchants must now confirm they are not susceptible to attacks from scripts on their payment pages, even when using iframes or redirects to third-party processors.
For the latest SAQ instructions and guidelines, refer to the PCI SSC Document Library.
Validation Approaches
Under v4.0, organizations can validate compliance using one of two approaches:
- Defined Approach — Follow the specific requirements as prescribed (traditional method)
- Customized Approach — Meet the security objective of a requirement using alternative controls, supported by a targeted risk analysis and documented evidence
The Customized Approach is not available for all requirements and demands greater documentation and testing rigor, but provides flexibility for organizations with mature security programs.
What if PCI DSS Compliance is Expired or Inactive?
Many teams often get asked “What if PCI DSS Compliance is expired or inactive?” The simple answer is that the organization is no longer in compliance with PCI DSS standards, and there could be several reasons and consequences.
Reasons for Inactive/Expired Compliance
- Failure to renew compliance: PCI DSS requires annual assessments (QSA onsite for Level 1, or SAQ completion for other levels). Failure to complete the assessment results in an inactive/expired status.
- Non-compliance issues: During an assessment, critical vulnerabilities or gaps are identified that the organization has not remediated.
- Change in business model: If an organization no longer stores, processes, or transmits cardholder data, PCI DSS may become irrelevant. However, proper handling of any remaining data and decommissioning obligations still need attention.
- Failure to meet new v4.0 requirements: Organizations that did not implement the 51 future-dated requirements by March 31, 2025 are now non-compliant.
Consequences of Inactive/Expired Compliance
- Fines and penalties: Payment card brands and acquiring banks can impose fines ranging from $5,000 to $100,000 per month on organizations that fail to maintain compliance.
- Reputational damage: A data breach resulting from non-compliance damages an organization’s reputation, leading to customer loss and eroded trust.
- Card processing restrictions: Payment card brands can restrict or terminate an organization’s ability to process card payments.
- Increased transaction fees: Acquiring banks may increase processing fees for non-compliant merchants.
- Liability for breach costs: Non-compliant organizations may be held liable for fraud losses and card replacement costs in the event of a breach.
Regaining Compliance
- Address identified issues: Identify and remediate all non-compliance gaps, including the new v4.0 requirements around client-side security, expanded MFA, and anti-phishing controls.
- Undergo reassessment: Complete a new assessment (ROC or SAQ) to confirm compliance with the current PCI DSS v4.0.1 standard.
- Maintain continuous compliance: Implement ongoing monitoring, regular security assessments, vulnerability scanning, and adherence to updated security practices. PCI DSS v4.0 emphasizes a shift from annual compliance validation to continuous security.
Getting Started with PCI DSS v4.0.1 Compliance
For compliance officers and engineering leads at fintech or e-commerce companies, here is a practical starting path:
- Determine your scope: Map out all systems, people, and processes that store, process, or transmit cardholder data. Consider tokenization and P2PE to reduce scope.
- Identify your merchant or service provider level based on annual transaction volumes.
- Select the appropriate SAQ or engage a QSA for a full ROC assessment.
- Choose your validation approach: Defined Approach for prescriptive compliance, or Customized Approach if you have mature, well-documented alternative controls.
- Address v4.0 priority items: Client-side script management, expanded MFA, automated log review, anti-phishing mechanisms, and authenticated vulnerability scanning.
- Implement scope reduction: Adopt tokenization for stored data, P2PE for card-present transactions, and proper network segmentation for cloud environments.
- Establish continuous compliance: Move beyond annual assessments to continuous monitoring, automated evidence collection, and ongoing risk analysis.
