The six-week RFC period for PCI DSS v4.0.1 closes on July 20. If your team has been managing compliance under v4.0 and encountered ambiguities, documented compensating controls for requirements that don't fit your architecture, or questioned certain controls while noticing obvious gaps, now's your chance to influence the future.
The PCI Security Standards Council wants your feedback on how the standard should evolve to support emerging technologies and AI. This isn't theoretical. Your comments during this RFC period will shape the requirements you'll implement three years from now.
The Problem: Standards Drift From Reality
PCI DSS v4.0 introduced customized implementation plans and targeted risk analyses, acknowledging that prescriptive controls don't fit every environment. However, implementation has revealed friction points:
Requirements designed for traditional network architectures don't apply well to serverless functions or containerized microservices. Scoping guidance assumes clear network boundaries that cloud-native payment flows lack. Cryptographic requirements reference outdated standards, while newer protocols lack clear guidance.
AI-powered fraud detection systems process cardholder data in ways the standard didn't anticipate. Real-time authorization decisions occur outside traditional CDE boundaries. Payment orchestration layers route transactions through multiple processors, and the standard's scoping language struggles to define responsibilities.
If you don't provide feedback during this RFC period, the next version will be written without considering your operational reality.
What You Need Before Starting
Access the RFC through the PCI SSC Portal. You'll need to accept a Non-Disclosure Agreement to download the document. This NDA is standard for pre-publication review processes, but it means you can't share the draft publicly or discuss specific proposed changes outside the RFC process.
Before reading the draft, document your current pain points:
Requirement ambiguities: Which controls required QSA interpretation? Where did you and your assessor disagree on scope or applicability? Which requirements forced compensating controls because the prescribed approach didn't fit your architecture?
Implementation gaps: What security controls does your team maintain that aren't reflected in PCI DSS requirements? What threats are you defending against that the standard doesn't address? Where are you doing more than the minimum because the minimum isn't sufficient?
Technology mismatches: Which requirements assume infrastructure patterns you don't use? Where does the standard's language (network segmentation, system components, CDE boundaries) fail to describe your actual payment processing architecture?
AI and automation concerns: If you're using machine learning for fraud detection, anomaly detection, or authorization decisioning, how does that system interact with cardholder data? What controls govern the model's access to sensitive authentication data or full PAN?
Collect specific examples. "Requirement 8.3.6 is unclear" won't move the needle. "Requirement 8.3.6 requires MFA for console access, but our infrastructure-as-code deployment model means engineers never access consoles directly; we need guidance on applying this control to API-driven infrastructure management" gives the Council something concrete to work with.
Step-by-Step: Submitting Effective Feedback
Read the draft systematically, not sequentially. Start with the requirements that caused the most friction during your last assessment. Read the Council's current language, then check if your documented pain points are addressed.
Structure each comment with:
- Requirement number and current language
- Specific implementation scenario that creates ambiguity
- Recommended clarification or alternative language
- Business/technical justification
For AI-related feedback, focus on control objectives rather than prescriptive technology requirements. Don't ask the Council to endorse specific ML frameworks. Instead, identify where current requirements create barriers to using AI for security improvements, or where AI introduces new data handling patterns that need control guidance.
Example: "Requirement 3.4 requires rendering PAN unreadable during storage. Our fraud detection model requires access to full PAN for transaction scoring. We maintain this access through [specific controls], but the requirement doesn't acknowledge this use case or provide guidance on securing ML model access to sensitive authentication data."
Submit comments through the PCI SSC Portal before July 20. The Council can only accept feedback submitted through the portal during the RFC period. Email, forum posts, and conference conversations don't count.
Be specific about emerging technology challenges. If you're implementing payment processing in serverless environments, describe how current scoping guidance fails to address ephemeral compute instances. If you're using tokenization services that didn't exist when v4.0 was written, explain what controls you've implemented and what guidance you need.
Don't request that the Council relax security requirements. Frame feedback as "here's a more effective way to achieve this security objective" or "here's a threat the current requirements don't address."
Validation: Confirm Your Feedback Was Received
After submitting through the portal, you should receive confirmation that your comments were recorded. If you don't see confirmation within 24 hours, follow up through the portal's support channel.
Track which requirements you commented on. When the next version is published, you'll want to check whether your feedback influenced the final language.
Ongoing: Prepare for the Next Version
The Council doesn't publish a timeline for the next major version, but RFC feedback collection is the first step in that process. Start planning now:
Document current compensating controls. If you're using compensating controls because a requirement doesn't fit your architecture, that's evidence the requirement needs revision. But if the requirement doesn't change, you'll need to maintain those compensating controls through the next version.
Monitor your AI and automation implementations. If you deploy new ML models or automation tools that process cardholder data between now and the next version's publication, document what controls govern their access and operation. That documentation becomes your reference point when new requirements emerge.
Track technology changes in your environment. If you migrate to new infrastructure patterns, adopt new payment protocols, or change how you scope your CDE, document what PCI DSS guidance did and didn't help. That's feedback for the next RFC cycle.
The RFC period closes July 20. The Council is explicitly asking for implementation feedback and perspectives on AI and emerging technology. If you wait for the next version to be published and then complain that it doesn't reflect your operational reality, you missed your opportunity to influence it.
