PCI DSS
PCI Security Standards Council · Version v4.0.1 · June 2024
The global security standard for any organization that stores, processes, or transmits payment card data.
Overview
PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard, published by the PCI Security Standards Council in June 2024 as a minor update to v4.0. Any organization that stores, processes, or transmits cardholder data or sensitive authentication data must comply. The standard comprises 12 requirements organized around six goals: 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 v4.0 introduced two assessment approaches: the traditional defined approach, where organizations implement the standard requirements exactly as written, and the customized approach, where organizations design their own controls to meet the stated objective. The customized approach requires documented evidence of how the custom control meets the requirement and additional validation by a Qualified Security Assessor. Merchant levels determine assessment requirements. Level 1 merchants processing over six million Visa or Mastercard transactions annually require an on-site assessment by a QSA and a Report on Compliance. Lower-level merchants may use Self-Assessment Questionnaires, of which there are several types depending on how card data is processed.
Who Needs This
Merchants who accept payment cards regardless of volume or channel
Payment processors, acquirers, issuers, and other payment service providers
Technology vendors whose products are involved in cardholder data environments
Service providers who store, process, or transmit cardholder data on behalf of other entities
Cloud providers hosting systems within a cardholder data environment
Structure at a Glance
Install and maintain network security controls and apply secure configurations to all system components.
Protect stored account data and protect cardholder data with strong cryptography during transmission over open, public networks.
Protect all systems and networks from malicious software and develop and maintain secure systems and software.
Restrict access to system components and cardholder data, identify users and authenticate access, and restrict physical access to cardholder data.
Log and monitor all access to system components and cardholder data, and test security of systems and networks regularly.
Support information security with organizational policies and programs covering personnel, vendors, and risk management.
AI Prompt Recipes
Copy these prompts directly into Claude or any capable model. Replace the bracketed placeholders with your organization-specific details.
Cardholder Data Environment Scoping
Use this to define and document the CDE before starting an assessment.
You are a PCI DSS v4.0.1 Qualified Security Assessor conducting a scoping exercise. My organization is a [TYPE OF BUSINESS]. We process card transactions through [DESCRIBE PAYMENT FLOW]. Our current network architecture: [DESCRIBE ARCHITECTURE]. Help me: (1) identify all in-scope system components, network segments, and personnel for the cardholder data environment, (2) determine which data flows involve cardholder data or sensitive authentication data, (3) recommend segmentation controls to reduce scope, and (4) identify which SAQ type would apply if we were a lower-level merchant.
Requirement Gap Analysis
Use this to assess conformance with a specific PCI DSS requirement.
I am assessing compliance with PCI DSS v4.0.1 Requirement [NUMBER] — [REQUIREMENT NAME]. My current implementation: [DESCRIBE CURRENT CONTROLS AND PROCESSES]. Evaluate this against the requirement's testing procedures. Identify: specific gaps between current state and the requirement, which testing procedures from the ROC template would fail based on current state, remediation steps with effort estimates, and whether a compensating control could address any gap that would be technically difficult to remediate within 90 days.
Compensating Control Documentation
Use this when a standard requirement cannot be met exactly as written.
I need to document a compensating control for PCI DSS v4.0.1 Requirement [NUMBER]. The reason the requirement cannot be met as written: [DESCRIBE TECHNICAL OR BUSINESS CONSTRAINT]. The compensating control I am proposing: [DESCRIBE PROPOSED CONTROL]. Draft a compensating control worksheet that includes: the reason the requirement cannot be met, the risk mitigated by the original requirement, the proposed compensating control and how it addresses the equivalent intent, an analysis of any residual risk, and maintenance and monitoring procedures for the compensating control.
Network Segmentation Review
Use this to document that out-of-scope systems are properly isolated from the CDE.
I need to document network segmentation for PCI DSS v4.0.1 to support a scope reduction claim. My CDE segments: [DESCRIBE CDE]. My out-of-scope segments: [DESCRIBE SEGMENTS CLAIMING ISOLATION]. Current segmentation controls: [DESCRIBE FIREWALL RULES, VLANS, ACCESS CONTROLS]. For each out-of-scope segment, provide: the evidence needed to demonstrate it cannot communicate with the CDE, the test procedures a QSA would use to validate segmentation, and any gaps in the current segmentation design that could invalidate the scope reduction claim.
Common Pitfalls
These are the mistakes practitioners see repeatedly in real assessments and implementation projects.
Scoping conversations happen too late. Scope determines cost, effort, and risk. Organizations that define scope after controls are already implemented often discover that more systems are in scope than expected.
Treating annual assessments as the full compliance program. PCI DSS requires continuous control operation. Evidence collected during a one-week QSA visit must reflect twelve months of operational practice.
Requirement 8 (authentication) misunderstandings around multi-factor authentication. PCI DSS v4.0 expanded MFA requirements significantly. MFA is now required for all access into the CDE, not just remote access.
Using SAQ D when a more limited SAQ type applies. SAQ D is the most comprehensive questionnaire. Organizations that misidentify their payment processing model end up doing far more work than required.
Ignoring Requirement 12 as administrative overhead. The information security policy requirements in v4.0 are more detailed than in previous versions and auditors now test their operational implementation, not just their existence.
Cross-Framework Mapping
ISO 27001
PCI DSS requirements map substantially to ISO 27001 Annex A controls, particularly in the Technological theme. A certified ISO 27001 organization has addressed many PCI DSS requirements but must still complete PCI-specific validation.
View Detailed Mapping ↗NIST CSF 2.0
PCI DSS maps to the Protect and Detect functions. NIST provides reference mappings.
HIPAA
Healthcare organizations that also process payment cards must satisfy both frameworks independently. Controls overlap in access management and audit logging but the compliance programs remain separate.
All content sourced from official issuing body documentation.
Official source ↗