The Transition from PCI DSS v3.2.1 to v4.0

The Payment Card Industry Data Security Standard has been the foundational security framework for organizations handling payment card data since its initial release in 2004. Version 4.0, published in March 2022, represents the first major revision since v3.2.1 and reflects a fundamental shift in the PCI Security Standards Council's approach to security validation.

While PCI DSS v4.0 became effective immediately upon release, organizations were given until March 31, 2025, to comply with requirements designated as "future-dated" — those that were considered best practices until that deadline. As of the second quarter of 2025, all PCI DSS v4.0 requirements are now mandatory, including several that significantly expand the scope and rigor of penetration testing.

For organizations across the San Francisco Bay Area — home to numerous payment technology companies, fintech startups, and e-commerce platforms — these changes have direct and immediate implications for security budgets, testing schedules, and vendor relationships. Understanding the specific penetration testing requirements is essential for maintaining compliance and avoiding the costly consequences of assessment failures.

Requirement 11.4: Penetration Testing in Detail

Requirement 11.4 under PCI DSS v4.0 defines the penetration testing mandates that apply to all organizations subject to the standard. While the core requirement for annual penetration testing is familiar, v4.0 introduces several critical modifications that expand both the depth and the specificity of testing requirements.

Requirement 11.4.1: Penetration Testing Methodology

PCI DSS v4.0 requires that penetration testing follow a defined, documented methodology that is based on an industry-accepted approach. The standard specifically references the NIST SP 800-115, the OWASP Testing Guide, and the PTES (Penetration Testing Execution Standard) as acceptable methodologies, though it does not mandate any single framework.

The methodology must address the following elements:

  • Coverage of the entire cardholder data environment (CDE) perimeter and all critical systems
  • Testing from both inside and outside the network
  • Validation of any segmentation and scope-reduction controls
  • Application-layer penetration testing that includes, at minimum, the vulnerabilities listed in Requirement 6.2.4
  • Network-layer penetration testing that covers all components supporting network functions as well as operating systems
  • Review and consideration of threats and vulnerabilities experienced in the last 12 months
  • A documented approach for retesting to verify that identified vulnerabilities have been remediated
What Changed: While PCI DSS v3.2.1 required a defined methodology, v4.0 is more prescriptive about what that methodology must cover. The explicit requirement to consider recent threats and vulnerabilities ensures that penetration testing is not a static exercise but adapts to the evolving threat landscape.

Requirement 11.4.2: Internal Penetration Testing

Internal penetration testing must be performed at least once every 12 months and after any significant infrastructure or application changes. v4.0 clarifies that "significant changes" include:

  • Changes to the network architecture, including new network segments, modified firewall rules, and new connections to external networks
  • Upgrades or modifications to operating systems or applications within the CDE
  • Changes to security controls that protect the CDE, including firewalls, IDS/IPS, and access control systems
  • Addition of new system components within the CDE
  • Changes to the flow of cardholder data within the environment

Requirement 11.4.3: External Penetration Testing

External penetration testing requirements mirror the internal testing cadence — at least annually and after significant changes. The external test must cover all externally accessible IP addresses and domains associated with the CDE, and must be performed by a qualified internal resource or an external third party. v4.0 emphasizes that the tester must maintain organizational independence from the team responsible for managing the tested environment.

Requirement 11.4.4: Remediation and Retesting

Vulnerabilities identified during penetration testing must be corrected in accordance with the entity's vulnerability management process (Requirement 6.3.1), and the corrections must be verified through retesting. v4.0 is explicit that simply remediating vulnerabilities is insufficient — the organization must demonstrate through retesting that the remediation is effective and that no new vulnerabilities were introduced by the fix.

Authenticated Internal Testing: The New Standard

One of the most impactful changes in PCI DSS v4.0 is the elevated emphasis on authenticated internal penetration testing. While v3.2.1 did not explicitly require authenticated testing, v4.0 makes clear that penetration tests must evaluate the environment from the perspective of an attacker who has gained some level of internal access.

This requirement reflects the reality that modern attackers rarely remain at the network perimeter. Phishing, credential theft, insider threats, and supply chain compromises routinely provide adversaries with authenticated access to internal systems. A penetration test that only evaluates the environment from an unauthenticated external perspective misses the attack scenarios that are most likely to result in cardholder data compromise.

What Authenticated Internal Testing Involves

Authenticated internal penetration testing should evaluate the following areas from the perspective of a compromised user account or system:

  • Privilege Escalation Paths: Testing whether a standard user account can escalate to administrative privileges within the CDE through misconfigured permissions, vulnerable services, or missing access controls.
  • Lateral Movement Opportunities: Assessing whether compromise of one system within the CDE enables access to other systems, particularly those containing cardholder data or cryptographic keys.
  • Data Access Controls: Verifying that authenticated users can only access the cardholder data and system functions that their role requires, and that data exfiltration controls are effective.
  • Segmentation Bypass: Testing whether authenticated access to systems in one network segment can be leveraged to access systems in segments that should be isolated, particularly the CDE itself.
  • Application-Level Authorization: Evaluating whether application-level access controls properly restrict user actions, including Insecure Direct Object Reference (IDOR) vulnerabilities, broken function-level authorization, and missing object-level authorization checks.
Compliance Alert: Organizations that have historically relied on network-only or unauthenticated penetration tests will need to significantly expand their testing scope to meet v4.0 requirements. This may require providing penetration testers with test accounts at multiple privilege levels, access to application environments, and detailed documentation of the CDE architecture.

Segmentation Testing: Validating Your Scope Reduction

Network segmentation is the primary mechanism by which organizations reduce the scope of their PCI DSS assessment. By isolating the CDE from the rest of the network, organizations can limit the number of systems subject to PCI DSS requirements. However, segmentation is only effective if it is properly implemented and regularly validated.

Requirement 11.4.5: Segmentation Penetration Testing

PCI DSS v4.0 requires segmentation penetration testing at least once every six months for service providers and at least annually for merchants. This testing must verify that:

  • Segmentation controls are operational and effective at isolating the CDE from all out-of-scope networks
  • All segmentation methods — whether implemented through firewalls, VLANs, access control lists, or other technologies — successfully prevent traffic from out-of-scope systems from reaching the CDE
  • Segmentation controls prevent traffic from the CDE from reaching out-of-scope networks in ways that could facilitate data exfiltration
  • Any changes to segmentation controls since the last test have not introduced gaps in isolation

Common Segmentation Failures

In our experience conducting PCI DSS segmentation testing for organizations across the San Francisco Bay Area and beyond, several common failure patterns emerge consistently:

Failure Type Description Frequency
Management network overlap Jump hosts or management VLANs that bridge in-scope and out-of-scope segments Very common
DNS and NTP shared services Infrastructure services shared between CDE and non-CDE segments creating trust relationships Common
Firewall rule drift Temporary rules added for troubleshooting or migration that were never removed Very common
Cloud virtual network misconfiguration VPC peering, shared subnets, or security group rules that bypass intended segmentation Increasing
Monitoring and logging paths SIEM agents, log forwarders, or monitoring systems that create bidirectional communication across segment boundaries Common
Container orchestration Kubernetes clusters or Docker networks that span CDE and non-CDE workloads Increasing

The Customized Approach: Flexibility with Rigor

PCI DSS v4.0 introduces the "customized approach" as an alternative to the traditional "defined approach" for meeting security requirements. Under the customized approach, organizations can implement security controls that differ from the prescriptive requirements of the standard, provided they can demonstrate that their alternative controls meet the stated security objective of each requirement.

How the Customized Approach Affects Penetration Testing

Organizations using the customized approach for any PCI DSS requirement must undergo more rigorous validation of their alternative controls. For penetration testing specifically, this means:

  • Control Effectiveness Validation: Penetration testing must specifically evaluate whether the customized security controls achieve their intended security objective. This goes beyond testing for vulnerabilities — it requires the penetration tester to understand the security objective and assess whether the implemented control achieves it.
  • Documentation Requirements: The customized approach requires detailed documentation of the security objective being addressed, the controls implemented, and the rationale for why those controls are sufficient. Penetration test reports must reference this documentation and provide evidence of control effectiveness.
  • Assessor Expertise: Qualified Security Assessors (QSAs) evaluating customized approach implementations must have sufficient expertise to evaluate the alternative controls. This often requires penetration testers with specialized knowledge of the specific technologies and architectures in use.
Practical Consideration: The customized approach is not a shortcut — it typically requires more effort, not less, to achieve and maintain compliance. Organizations considering the customized approach should ensure that their penetration testing partner has the expertise to evaluate alternative controls against the stated security objectives, not just against a checklist of standard requirements.

Compliance Timeline: Where We Stand

Understanding the PCI DSS v4.0 timeline is critical for planning penetration testing engagements and ensuring continuous compliance.

Key Milestone Dates

  • March 2022: PCI DSS v4.0 published. Future-dated requirements designated as best practices.
  • March 2024: PCI DSS v3.2.1 retired. All new assessments must use v4.0.
  • March 31, 2025: All future-dated requirements become mandatory. Organizations must be fully compliant with the complete v4.0 standard.
  • Ongoing: Annual and semi-annual penetration testing cadences continue per requirements 11.4.2 through 11.4.5.

As of this publication, the March 31, 2025, deadline has passed. Organizations that have not yet updated their penetration testing programs to meet v4.0 requirements are at risk of non-compliance findings during their next assessment. For Bay Area payment technology companies and fintech firms, many of which process significant transaction volumes as Level 1 or Level 2 merchants, the consequences of non-compliance include increased transaction fees, mandatory remediation timelines, and potential restrictions on card processing capabilities.

Planning Your Testing Schedule

Given the annual and semi-annual testing cadences required by v4.0, organizations should establish a testing schedule that accounts for:

  • Annual internal and external penetration tests aligned with the assessment cycle
  • Semi-annual segmentation tests for service providers
  • Ad hoc testing triggered by significant infrastructure or application changes
  • Sufficient time for remediation and retesting before the assessment date
  • Potential delays due to testing partner availability, particularly during peak assessment seasons

ASV Scanning Requirements Under v4.0

While Approved Scanning Vendor (ASV) scans are distinct from penetration testing, v4.0 introduces changes to ASV requirements that affect the overall external security assessment program and should be coordinated with penetration testing activities.

Updated ASV Requirements

PCI DSS v4.0 Requirement 11.3.2 requires quarterly external vulnerability scans performed by a PCI SSC-approved ASV. Key updates under v4.0 include:

  • Authenticated Scanning: v4.0 encourages (and for some requirements mandates) authenticated vulnerability scanning in addition to unauthenticated ASV scans. Authenticated scans provide significantly more accurate results by evaluating the system from the perspective of a logged-in user.
  • Scan Scope Accuracy: Organizations must ensure that ASV scans cover all externally accessible IP addresses and domains associated with the CDE. v4.0 places greater emphasis on scope accuracy, requiring organizations to maintain an up-to-date inventory of external-facing assets.
  • Vulnerability Prioritization: Identified vulnerabilities must be addressed based on risk ranking, with critical and high-severity findings remediated within defined timelines. v4.0's risk-based approach allows organizations to prioritize remediation based on exploitability and potential impact rather than CVSS score alone.
  • Scan Quality: v4.0 addresses the historical practice of disputing legitimate scan findings to achieve a passing result. The standard now requires that disputes be supported by evidence that the finding is a false positive, not simply an inconvenient truth.

Coordinating ASV Scans with Penetration Testing

ASV scans and penetration tests serve complementary but distinct purposes. ASV scans provide broad, automated vulnerability identification across the external attack surface, while penetration tests provide depth, context, and exploitation validation. Organizations should coordinate these activities to avoid duplication, ensure comprehensive coverage, and maximize the value of both.

"PCI DSS v4.0 penetration testing is not just about checking a compliance box — it is about validating that your security controls actually work against the techniques that real attackers use. Organizations that treat penetration testing as a checkbox exercise will find themselves compliant on paper but vulnerable in practice."

Selecting a Penetration Testing Partner for PCI DSS v4.0

The choice of penetration testing partner is a critical decision that directly affects the quality of the assessment and the organization's compliance posture. When evaluating potential partners for PCI DSS v4.0 penetration testing, consider the following criteria:

  • PCI DSS Expertise: The testing team must understand the specific requirements of PCI DSS v4.0, including the nuances of scope determination, segmentation validation, and the customized approach. General-purpose penetration testers who are not familiar with PCI DSS may miss compliance-relevant findings or waste effort testing out-of-scope systems.
  • Methodology Alignment: The partner's testing methodology should align with the industry-accepted frameworks referenced in Requirement 11.4.1 and should be documented in sufficient detail to satisfy QSA review.
  • Reporting Quality: PCI DSS assessments require specific documentation of penetration testing activities, findings, and remediation verification. The testing partner's reports must provide the evidence that QSAs need to validate compliance.
  • Independence: v4.0 requires organizational independence between the penetration testing team and the team responsible for managing the tested environment. External testing partners inherently satisfy this requirement, but organizations using internal testing teams must establish appropriate separation of duties.
  • Retesting Capability: Requirement 11.4.4 mandates verification of remediation through retesting. The testing partner should include retesting in their engagement scope and provide timely turnaround to avoid delaying the compliance assessment.

Preparing Your Organization for a PCI DSS v4.0 Penetration Test

Organizations can maximize the value of their penetration testing engagement and streamline the compliance process by preparing effectively before testing begins:

  • Update the CDE Scope Documentation: Ensure that the CDE scope, including all system components, network segments, and data flows, is accurately documented and current.
  • Provide Network Architecture Diagrams: Current network diagrams that show segmentation controls, firewall placements, and data flow paths enable the testing team to focus their efforts effectively.
  • Prepare Test Accounts: For authenticated testing, provision test accounts at appropriate privilege levels within all in-scope applications and systems.
  • Identify Change History: Document all significant changes to the CDE since the last penetration test, including infrastructure modifications, application updates, and security control changes.
  • Coordinate with Operations: Ensure that IT operations, security operations, and application teams are aware of the testing schedule and prepared to support the engagement without interfering with results.
  • Review Previous Findings: Provide the testing team with the results of previous penetration tests and vulnerability scans so they can verify that prior findings have been effectively remediated.

Conclusion

PCI DSS v4.0 represents a significant evolution in penetration testing requirements for organizations that handle payment card data. The enhanced emphasis on authenticated internal testing, rigorous segmentation validation, and the introduction of the customized approach demand more comprehensive, more frequent, and more sophisticated security assessments than ever before.

With the March 2025 deadline for future-dated requirements now behind us, every organization subject to PCI DSS must ensure that their penetration testing program fully meets v4.0 mandates. The consequences of non-compliance extend beyond regulatory penalties — inadequate penetration testing means undetected vulnerabilities that real attackers will find and exploit.

At CyberGuards, our San Francisco-based team specializes in PCI DSS penetration testing that goes beyond compliance checkboxes to deliver genuine security assurance. We help organizations throughout the Bay Area and across the nation navigate the complexities of v4.0 requirements while strengthening their actual security posture against the threats that the standard is designed to address.

If your organization processes, stores, or transmits cardholder data and you have not yet aligned your penetration testing program with PCI DSS v4.0, the time to act is now. Contact our team to discuss your compliance requirements and develop a testing plan that meets both the letter and the spirit of the standard.