PCI DSS 4.0.1
Payment Card Industry Data Security Standard
Standard Introduction
PCI DSS (Payment Card Industry Data Security Standard) is a global information security standard established by the PCI Security Standards Council (PCI SSC), founded in 2006 by major payment card brands including Visa, Mastercard, American Express, Discover, and JCB. Version 4.0.1 is the current v4.x baseline, building on PCI DSS 4.0, which became mandatory from March 31, 2024. The standard applies to all entities that store, process, or transmit cardholder data, including merchants, payment processors, acquirers, issuers, and service providers. PCI DSS is organized into 12 core requirements across 6 control objectives: Build and Maintain a Secure Network, Protect Cardholder Data, Maintain a Vulnerability Management Program, Implement Strong Access Control Measures, Regularly Monitor and Test Networks, and Maintain an Information Security Policy.
PCI DSS 4.0.1 keeps the v4.0 security objectives while adding limited revisions and clarifications. The standard supports both a defined approach and a customized approach, with stronger authentication, expanded e-commerce protections, phishing-focused controls, and automated log review expectations. Compliance validation depends on transaction volume: Level 1 merchants generally require annual on-site assessments by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV). Levels 2-4 may complete Self-Assessment Questionnaires (SAQs). Non-compliance can result in fines, increased transaction fees, and potential loss of card acceptance privileges. Future-dated v4.x requirements became effective on March 31, 2025.
Cardholder Data Protection
Focuses specifically on protecting credit/debit card account numbers, cardholder names, expiration dates, and service codes throughout the transaction lifecycle.
Network Segmentation
Strongly encourages isolating the cardholder data environment (CDE) from the rest of the network to reduce scope and simplify compliance.
Strong Cryptography
Requires encryption of cardholder data in transit over open networks and at rest, with defined key management procedures.
list_alt The 12 Requirements
- Install and maintain network security controls
- Apply secure configurations to all components
- Protect stored account data
- Encrypt cardholder data over open networks
- Protect from malicious software
- Develop and maintain secure systems
- Restrict access by business need-to-know
- Identify users and authenticate access
Who Needs to Comply?
Any organization that stores, processes, or transmits payment card data — merchants, payment processors, acquirers, issuers, and service providers regardless of transaction volume.
Key Requirements
Cardholder Data Environment Scoping
Identify all system components, people, and processes that store, process, or transmit cardholder data. Proper scoping is the foundation — reducing scope reduces compliance burden.
Vulnerability Management
Run internal and external vulnerability scans quarterly (external by an ASV). Conduct penetration testing annually. Address critical vulnerabilities within defined timeframes.
Access Control
Restrict access to cardholder data to only those individuals whose job requires it. Implement multi-factor authentication for all access to the CDE and for remote network access.
Logging and Monitoring
Log all access to network resources and cardholder data. Review logs daily. Retain audit trail history for at least 12 months with 3 months immediately available.
Incident Response Plan
Establish, document, and test an incident response plan. Include procedures for containment, forensics, notification of card brands, and post-incident review.
Implementation Roadmap
Prepare and Scope the CDE
Identify every system, process, and person that stores, processes, or transmits cardholder data, and define the Cardholder Data Environment (CDE). Determine your merchant level and applicable validation type, and map account data flows end to end so you understand exactly what is in scope for PCI DSS.
Gap Analysis and Scope Reduction
Assess current controls against the 12 PCI DSS requirements and identify where you fall short of v4.0.1. Where possible, reduce scope through network segmentation and by eliminating unnecessary storage of cardholder data, then prioritize remediation of the highest-risk gaps.
Implement Controls
Deploy the required security controls, including firewalls, strong access control, MFA, encryption of cardholder data in transit and at rest, vulnerability management, and logging and monitoring. Address the future-dated v4.0 requirements that became mandatory on 31 March 2025, and document policies and procedures.
Validate and Maintain
Complete the appropriate SAQ or a Report on Compliance (ROC) with a QSA, obtain an Attestation of Compliance (AOC), and run required ASV scans. Sustain compliance through continuous monitoring, quarterly scans, annual reassessment, and prompt patching, treating PCI DSS as an ongoing program rather than a point-in-time event.
Compliance Checklist
checklist Scoping and Governance
checklist Technical Controls
checklist Monitoring and Validation
Penalties & Enforcement
Non-compliant organizations face fines from $5,000 to $100,000 per month from card brands. After a breach, costs include forensic investigation ($20K-$500K+), fraud liability, increased processing fees, and potential loss of card acceptance privileges.
Frequently Asked Questions
Who must comply with PCI DSS?
expand_more
PCI DSS applies to any entity that stores, processes, or transmits cardholder data, as well as entities that can affect the security of that data. This includes merchants, service providers, processors, and acquirers, regardless of size or transaction volume. The standard is enforced contractually by the payment brands and acquiring banks rather than by a government body.
What is the CDE and how does segmentation reduce scope?
expand_more
The Cardholder Data Environment (CDE) comprises the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus connected systems. Network segmentation uses controls such as firewalls to isolate the CDE from the rest of the network. Effective segmentation removes out-of-scope systems from assessment, reducing cost, risk, and complexity.
What are the 12 PCI DSS requirements?
expand_more
The 12 requirements are grouped under six goals: build and maintain a secure network and systems; protect account data; maintain a vulnerability management program; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy. Together they cover firewalls, encryption, anti-malware, access control, logging, testing, and governance. Every requirement must be met or handled with a documented compensating control.
What are merchant levels, and does an SAQ or a ROC apply to me?
expand_more
Merchants are classified into four levels based primarily on annual transaction volume, with Level 1 being the highest, and your level drives how you validate. Lower levels may self-validate with a Self-Assessment Questionnaire (SAQ), whose different types match different payment scenarios, while Level 1 merchants and many service providers generally need a formal Report on Compliance (ROC) performed by a QSA. Either path produces an Attestation of Compliance (AOC), and your acquirer or payment brand ultimately confirms your specific requirements.
What changed in v4.0 and what was the March 2025 deadline?
expand_more
PCI DSS v4.0 introduced a more flexible customized approach, expanded authentication and MFA expectations, and stronger requirements around scripts, phishing, and continuous processes; v3.2.1 was retired in March 2024 and v4.0.1 is the current version. A set of future-dated v4.0 requirements were best practices until they became mandatory on 31 March 2025. From that date, assessments must include those newly effective controls.
What are the MFA requirements?
expand_more
PCI DSS requires multi-factor authentication (MFA) for all remote access into the network and, under v4.0, for all access into the CDE, including administrative and non-console access. MFA must combine at least two independent factors and be resistant to replay. This broadened MFA scope is one of the more significant changes in v4.0 for many organizations.
Do I still need PCI DSS if I use a third-party processor like Stripe?
expand_more
Yes. Using a compliant third-party payment processor can significantly reduce your scope and may qualify you for a simpler SAQ, but it does not eliminate your PCI DSS obligations. You remain responsible for how payments are integrated, for not storing prohibited data, and for validating compliance, often via SAQ A or SAQ A-EP depending on your integration. Outsourcing processing shifts, but does not remove, responsibility.
What are the penalties and consequences of non-compliance?
expand_more
PCI DSS is enforced through contracts with payment brands and acquiring banks, which can impose monthly fines, higher transaction fees, or termination of the ability to accept card payments. If a breach occurs while non-compliant, an organization may face significant liability, forensic investigation costs, and reputational damage. Maintaining compliance is both a contractual obligation and a risk-reduction measure.
Official Documentation
PCI DSS v4.0.1 Standard
PDF • PCI SSC • Official Payment Card Industry Data Security Standard
PCI SSC Document Library
External Link • pcisecuritystandards.org • Standards, Guidelines & Resources
QSA & ASV Directory
External Link • pcisecuritystandards.org • Find Qualified Security Assessors