Your team might think they understand the PCI Secure Software Standard v2.0 update. They're likely wrong about several critical points.
These myths persist because the PCI Security Standards Council's revision introduces genuinely novel concepts, SDK assessments, sensitive asset documentation, and wildcard change tracking, that don't align with how teams approached v1.2.1. Regulatory affairs professionals are hearing conflicting interpretations from assessors, vendors, and internal stakeholders. Without the training materials (expected Q1 2026) or the Report on Validation and Attestation of Validation templates (expected early February 2026), speculation fills the vacuum.
Here's what your team is getting wrong, and what the standard actually requires.
Myth 1: The 12-Month Transition Starts Now
Reality: The transition clock hasn't started yet. The 12-month period begins once the v2.0 computer-based training becomes available, which the PCI Security Standards Council expects in Q1 2026. Until that training launches, you're still operating under v1.2.1 timelines.
This matters because your project plan shouldn't be built around a January 2025 kickoff. If training arrives in March 2026, your compliance deadline is March 2027. Budget your assessor engagement accordingly; rushing to book resources now wastes opportunities. Use this pre-training window to map your sensitive assets and review the new Sensitive Asset Identification companion document, which is already available in the PCI SSC Document Library.
The practical implication: Don't let procurement pressure you into locking in assessment dates before you know when the transition actually begins. You need the training content to properly scope the work.
Myth 2: SDK Assessment Is Optional for 3DS Implementations
Reality: If you're developing or maintaining EMVCo 3DS SDKs, the v2.0 standard provides an alternate assessment path that will eventually replace the PCI 3DS SDK Standard entirely. This isn't a choice between two equivalent options; it's the beginning of a consolidation roadmap.
The PCI 3DS Data Matrix has already been updated to version 1.2 to include 3DS SDK sensitive data elements, signaling that the Council is aligning assessment criteria across standards. If your team is planning a 3DS SDK assessment under the old standard, you're building technical debt. The v2.0 path will become the primary route, and assessors will shift their focus there.
For teams managing 3DS SDKs: Start identifying which data elements in your SDK qualify as sensitive under the new matrix. The v2.0 standard's sensitive asset documentation requirements apply to SDKs just as they do to full applications. If you can't articulate which SDK components handle payment-related data or payment-related functionality, you're not ready for assessment.
Myth 3: Wildcard Changes Reduce Your Documentation Burden
Reality: Wildcards account for non-security impacting changes, but you still need to demonstrate that a change qualifies as non-security impacting. The new Change Impact template (expected early February 2026) will define how you document that determination.
Your team likely hears "wildcard" and thinks "less paperwork." What it actually means is a structured way to group low-risk changes without triggering a full delta assessment. But you're still documenting the rationale. Consider a team that updates library versions monthly for dependency management. Under v2.0, you might apply a wildcard to routine library updates that don't touch payment data handling, but you'll need evidence showing why those updates don't affect security controls.
The revised delta change process requires you to use the Change Impact template to classify modifications. If you're not tracking which code paths interact with sensitive assets, you can't accurately determine whether a change is security-impacting. This loops back to the Sensitive Asset Identification document; you need that baseline first.
Myth 4: Portal Access for Annual Attestations Simplifies Compliance
Reality: Portal access streamlines submission mechanics, but it doesn't reduce the rigor of what you're attesting to. Your software vendor can now submit annual attestations and administrative changes directly through the Portal, but the underlying validation requirements haven't changed.
What has changed is visibility. The PCI SSC has improved Portal and listing features, which means your attestation status is more transparent to acquiring banks and payment processors. If you miss an annual attestation window or submit incomplete administrative updates, downstream partners will see it faster. The operational benefit is real, no more email chains with PDFs, but the compliance bar is the same.
For regulatory affairs teams: Map out who in your organization has Portal access, who's authorized to submit attestations, and what your internal review process looks like before anything goes to the PCI SSC. The ease of submission can create false confidence if your pre-submission controls aren't tight.
Myth 5: You Can Wait Until v1.2.1 Expires to Engage with v2.0
Reality: Waiting until the transition deadline puts you in a reactive posture with no room for remediation. The sensitive asset documentation requirement alone will expose gaps in how your team understands your own software architecture.
The Sensitive Asset Identification companion document asks you to inventory components that handle, process, or store payment-related data. If your team can't produce that inventory today, you're not ready for a v2.0 assessment in 12 months. Most software vendors discover during this exercise that they've lost track of which modules interact with payment data, especially in legacy codebases or after multiple acquisitions.
Start now by conducting an internal sensitive asset mapping exercise. Identify every library, API endpoint, data store, and processing function that touches payment information. Document data flows. This isn't just compliance theater; it's the foundation for scoping your assessment and for making accurate determinations about which changes are security-impacting under the wildcard process.
What to Do Instead
Build your transition plan around three phases: preparation (now through Q1 2026), training and scoping (Q1-Q2 2026), and assessment execution (remainder of the 12-month window).
During preparation, focus on sensitive asset documentation and reviewing the Summary of Changes document. Assign ownership for Portal administration and establish your internal change classification process. When training launches, ensure your assessors and internal security architects complete it immediately; don't wait for the instructor-led sessions if you're working with experienced assessors.
For scoping, use the new templates to conduct a gap analysis between your current v1.2.1 evidence and what v2.0 requires. Pay particular attention to SDK components if you're in the 3DS space. Budget time for the Change Impact template work; this isn't a one-time exercise but an ongoing process.
The teams that will clear v2.0 assessments efficiently are the ones who treat the pre-training window as active preparation time, not a waiting period. Your 12-month transition hasn't started, but your readiness work should have begun the day the standard published.
