PCI DSS is the global compliance standard for any organization that stores, processes, or transmits cardholder data. Mandated by the major payment card brands (Visa, Mastercard, American Express, Discover, JCB) and managed by the PCI Security Standards Council, it applies to merchants, service providers, and payment processors of all sizes. Non-compliance can result in fines, higher processing fees, or loss of card processing capability.
Version 4.0, released March 2022 with full enforcement beginning March 2024, was the first major update since v3.2.1. It introduced customized control implementation options, stronger authentication requirements, expanded encryption mandates, and new requirements for targeting and monitoring payment page scripts. Several new requirements were future-dated with March 2025 effective dates, including controls directly relevant to AI-adjacent systems: automated log review, continuous monitoring, and detection of suspicious activity.
Requirement 1: Install and Maintain Network Security Controls — firewalls, routers, and network security configurations that restrict traffic between trusted and untrusted networks.
Requirement 2: Apply Secure Configurations to All System Components — change default passwords, remove unnecessary services, harden all systems including cloud and containerized environments.
Requirement 3: Protect Stored Account Data — encryption, tokenization, masking, and hashing of cardholder data at rest. Minimize storage. Retention policies.
Requirement 4: Encrypt Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks — TLS 1.2+, IPsec, or other strong cryptography for data in transit.
Requirement 5: Protect All Systems and Networks from Malicious Software — anti-malware, patch management, and detection of malicious software on all system components.
Requirement 6: Develop and Maintain Secure Systems and Software — secure coding practices, vulnerability scanning, penetration testing, and secure software development lifecycle.
Requirement 7: Enforce Need-to-Know Access to Account Data — role-based access control, least privilege, and network segmentation to restrict access to cardholder data.
Requirement 8: Identify Users and Authenticate Access to System Components — unique IDs, multi-factor authentication, and strong authentication for all access to cardholder data environments.
Requirement 9: Restrict Physical Access to Cardholder Data — physical security controls, visitor management, and media protection for systems handling cardholder data.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data — audit logging, log review, and security monitoring. v4.0 added automated log review requirements.
Requirement 11: Test Security of Systems and Networks Regularly — vulnerability scanning, penetration testing, intrusion detection/prevention, and wireless analysis.
Requirement 12: Support Information Security with Organizational Policies and Programs — risk assessments, security policies, training, incident response, and third-party vendor management.
AI systems handling cardholder data must meet all 12 requirements — no exceptions. There is no "AI carve-out" in PCI DSS. If an AI model, pipeline, or inference system touches cardholder data (the Primary Account Number and any sensitive authentication data), it's in scope. Every control that applies to a traditional database applies to an AI system's training data store, inference server, and model artifacts.
Requirements 3, 7, and 10 are the AI pressure points. Req 3 (encrypt stored data) means CDP used for AI training must be encrypted at rest — and if CDP is embedded in model weights after fine-tuning, the weights themselves may need encryption. Req 7 (need-to-know) means AI system access must be role-based — every API key, every model endpoint, every training pipeline needs access controls. Req 10 (log and monitor) means every AI interaction with CDP must be auditable — prompts, responses, data access events.
PCI DSS v4.0 introduced significant changes from v3.2.1, including: customized approach options that allow organizations to implement controls differently if they achieve the same security objectives; expanded multi-factor authentication requirements covering all access into the cardholder data environment (not just remote access); stronger password requirements (minimum 12 characters); and new requirements for securing payment pages against script attacks (Req 6.4.3).
Several requirements were future-dated with a March 31, 2025 effective date, giving organizations time to implement. These include: automated mechanisms for log review (Req 10.4.2), continuous monitoring of security controls (Req 11.3.2), internal vulnerability scans with automated tools (Req 11.3.1), targeted risk analyses for multi-factor authentication frequency (Req 8.3.2), and detection of suspicious activity through automated monitoring (Req 10.7.2).
The customized approach is the most significant structural change. Previously, organizations had to implement controls exactly as written. v4.0 allows them to design alternative implementations that achieve the same objective — but they must document how their approach meets the requirement, and Qualified Security Assessors (QSAs) must validate the equivalence.
The future-dated automated monitoring requirements are AI-relevant by design. Req 10.4.2 (automated log review) and Req 10.7.2 (automated detection of suspicious activity) push organizations toward AI/ML-based security monitoring. The standard is creating demand for AI security tools at the same time it imposes compliance requirements on AI systems that handle cardholder data — a dual role that benefits established security AI vendors.
The customized approach creates room for AI-specific implementations — but with QSA validation. An organization could theoretically design an AI-based control implementation (e.g., ML-driven access monitoring) under the customized approach. But the QSA must approve it, and QSAs are trained on traditional control implementations. Novel AI approaches face an uphill validation battle. The customized approach is flexible in theory but conservative in practice.
PCI DSS scope is defined by the Cardholder Data Environment (CDE): all systems, networks, and components that store, process, or transmit cardholder data, plus any connected system components. Cardholder data is defined as the Primary Account Number (PAN) alone, or PAN plus cardholder name, expiration date, or service code. Sensitive Authentication Data (full track data, CVV, PINs) must never be stored after authorization.
Scope reduction through tokenization, encryption, and network segmentation is actively encouraged. If cardholder data is properly tokenized before reaching an AI system, that AI system may be considered out of PCI scope — but only if the tokenization is irreversible and the AI system cannot access the mapping between tokens and PANs.
The challenge with AI systems is that they may inadvertently bring cardholder data into scope through: training on transaction data containing PANs, inference on untokenized cardholder data, logging cardholder data in model interaction logs, or storing cardholder data in model context windows or retrieval indices (RAG systems).
Scope creep is the AI compliance trap in PCI DSS. An AI system that was intended to be out of scope can inadvertently enter scope if it processes any data containing PANs. Transaction analysis AI, fraud detection models, and customer service chatbots all risk pulling cardholder data into their pipelines — expanding the CDE to include the AI infrastructure, training data stores, and model artifacts.
Tokenization is the escape hatch — but it shifts the problem. If cardholder data is tokenized before AI processing, the AI system is out of PCI scope. But the tokenization system itself is in scope, and the AI system's utility may be reduced if it can only work with tokens rather than real card data. Fraud detection models, for example, may lose signal when working with tokenized data.
RAG systems and model logs are hidden scope expanders. A retrieval-augmented AI system that indexes documents containing PANs brings those documents into scope. Model interaction logs that capture cardholder data (e.g., a customer service AI processing a payment) must be retained and protected per Req 10. Organizations deploying AI without scoping analysis may unknowingly expand their PCI assessment surface.
PCI DSS compliance is validated through two primary pathways: Self-Assessment Questionnaires (SAQs) for lower-volume merchants and service providers, and on-site assessments by Qualified Security Assessors (QSAs) for Level 1 merchants (6M+ transactions/year) and Level 1 service providers. Internal Security Assessors (ISAs) can conduct internal assessments for larger organizations that maintain ISA programs.
Assessments are annual. Continuous compliance is the stated expectation — v4.0 strengthened language around maintaining controls between assessment cycles, not just during them. The future-dated requirements for automated log review and continuous monitoring reinforce this shift from point-in-time to ongoing compliance.
For AI systems in scope, QSAs must assess whether the AI infrastructure meets each applicable requirement. There is no AI-specific assessment methodology — QSAs apply the same 12 requirements to AI systems as to any other system component. This means the assessor's understanding of AI architecture determines the quality of the assessment.
QSAs apply traditional control frameworks to AI systems they may not fully understand. A QSA evaluating an LLM-based fraud detection system must assess access controls, encryption, logging, and vulnerability management — but the QSA's training is in network and application security, not ML/AI architecture. Model weight protection, training data provenance, and inference logging are novel assessment areas that the PCI SSC hasn't published specific guidance for.
Annual assessments create a compliance snapshot problem for AI. AI systems change continuously — models are retrained, fine-tuned, and updated. An annual QSA assessment captures a point-in-time state that may not reflect the system's configuration a month later. v4.0's shift toward continuous monitoring helps, but the assessment framework is still fundamentally annual.
Related frameworks: SOC 2 (service organizations handling payment data often need both) · ISO/IEC 27001 (broader ISMS that can encompass PCI DSS controls) · NIST SP 800-53 (federal control catalog overlapping with PCI DSS requirements) · GDPR (cardholder data is also personal data — dual compliance required for EU operations)
Investigation tracks: The Compliance Trap (scope expansion as AI risk) · The Infrastructure Play (tokenization as the scope escape hatch) · The Asymmetry (QSA expertise gap in AI systems)