August 2, 2026
AI System Threat Modeling: A Guide to Mapping ML Pipeline Risks
AI System Threat Modeling: A Guide to Mapping ML Pipeline Risks
Omair
New Update: Our new blog is updated.
Free download
Fiza Nadeem is an SEO content writer at ioSENTRIX with 2.5+ years of experience in content writing, copywriting, and SEO.
Payment card data remains a high-value target for cybercriminals. A single weakness in a payment application, network, API, or access control can give attackers a path to sensitive cardholder data.
For organizations that store, process, or transmit payment card information, penetration testing is therefore an important part of PCI DSS compliance and security validation.
PCI DSS v4.0.1 is the current revision of the standard. While v4.0.1 did not add or remove requirements, it clarified parts of the standard and retained the March 31, 2025 effective date for the new future-dated requirements.
In 2026, organizations should therefore be operating against the fully effective PCI DSS v4.x requirements that apply to their environment.
For penetration testing, Requirement 11.4 is particularly important. It covers the penetration testing methodology, internal and external testing, remediation and retesting, segmentation testing, and additional requirements for certain service providers.
The focus is also broader than simply having an annual penetration test report. Organizations need to show that testing is properly scoped, performed using an appropriate methodology, followed by remediation where needed, and supported by evidence.
This is especially important when network segmentation is being used to reduce the scope of the cardholder data environment (CDE).
PCI DSS v4.0.1 Requirement 11.4 requires applicable organizations to perform internal and external penetration testing using a defined methodology. Testing must be performed at least every 12 months and after significant infrastructure or application changes.
Organizations must also remediate exploitable vulnerabilities and security weaknesses. If segmentation is used to isolate the cardholder data environment, the segmentation controls must also be tested.
Service providers and multi-tenant service providers also have additional requirements. The main Requirement 11.4 controls can be summarized as follows:
These requirements are designed to determine whether security controls actually withstand realistic attack attempts. A compliant penetration testing program should therefore go beyond automated vulnerability discovery.
It should examine how weaknesses can be exploited and whether an attacker could use them to reach the CDE or compromise systems that affect its security.
For organizations using segmentation to isolate their CDE, segmentation testing is especially important. PCI DSS requires organizations to validate that their segmentation controls are operational and effective rather than simply assuming that a firewall, VLAN, access control, or other boundary provides sufficient isolation.
The biggest point to understand in 2026 is that organizations are no longer in the transition period for PCI DSS v4.x. The future-dated requirements became effective on March 31, 2025.
PCI SSC states that once the effective date is reached, applicable new requirements must be fully considered as part of the PCI DSS assessment.
PCI DSS v4.0.1 is a limited revision of PCI DSS v4.0. It was introduced to address stakeholder feedback, correct errors, and clarify the intent of certain requirements and guidance.
This means organizations should not treat PCI DSS v4.0.1 as an entirely new standard. Instead, they should view it as the current version of PCI DSS v4 with clarifications and corrections that need to be reflected in their compliance activities.
PCI DSS v4.0 included several requirements that were initially identified as future-dated. Organizations could treat those requirements as best practices before the specified effective date.
That transition ended on March 31, 2025. In 2026, applicable future-dated requirements must be included in the assessment process rather than treated as optional best practices.
For penetration testing programs, this makes it important to review existing testing procedures, scope documents, segmentation controls, tester qualifications, and remediation processes against the current requirements.
PCI DSS penetration testing should be treated as a defined security process rather than a once-a-year technical exercise. A mature program should include:
This approach provides stronger assurance than simply commissioning a generic penetration test and storing the final report for the next audit.
Requirement 11.4 is the central PCI DSS requirement for penetration testing. It establishes how testing should be planned, performed, validated, and documented.
Organizations need a documented penetration testing methodology that defines how testing will be performed. The methodology should be appropriate for the organization's environment and based on accepted industry practices.
A suitable methodology should establish the testing procedures, systems and applications in scope, and types of attacks that will be evaluated. It should also provide sufficient coverage of the network and application layers relevant to the environment.
The methodology should account for:
The goal is not simply to identify a list of known vulnerabilities. Penetration testing should simulate realistic attack behavior and determine whether weaknesses can actually be exploited.
This is why a vulnerability scan alone does not constitute a PCI DSS penetration test. Automated scanners are useful for finding known vulnerabilities, but penetration testing adds manual validation, exploitation, attack-path analysis, and contextual assessment of security weaknesses.
Internal penetration testing evaluates the security of systems and networks from inside the organization's environment. The objective is to understand what an attacker, compromised endpoint, malicious insider, or unauthorized internal user could potentially reach after gaining access to the internal network.
Testing may assess:
For example, an attacker may initially compromise a workstation that is outside the CDE. If that workstation can then communicate with a payment server because of an overly permissive firewall rule, the segmentation and access-control design may not provide the intended protection.
PCI DSS requires internal penetration testing at least once every 12 months and after significant infrastructure or application upgrades and modifications. The exact scope should be based on the organization's PCI DSS scope and the systems that could affect the security of the CDE.
External penetration testing evaluates systems from outside the organization's network perimeter. The purpose is to determine whether an internet-based attacker can identify and exploit weaknesses that could lead toward sensitive systems or cardholder data.
Depending on the environment, external testing may include:
External penetration testing should not stop at basic port scanning. Testers should investigate exposed services, attempt controlled exploitation, evaluate authentication and authorization, and determine whether weaknesses can be chained into a meaningful attack path.
Like internal testing, external penetration testing is required at least once every 12 months and after significant infrastructure or application upgrades and modifications.
Finding vulnerabilities is only one part of an effective PCI DSS penetration testing program.
Requirement 11.4.4 requires exploitable vulnerabilities and security weaknesses identified during penetration testing to be corrected based on the organization's assessment of the risk posed by the issue.
Penetration testing is then repeated to verify that the corrections were effective. A practical remediation process should include:
For example, if a penetration test identifies an authorization flaw in a payment application, fixing the code is not enough. The organization should verify that the original attack path is no longer exploitable.
Retesting is therefore an important distinction between completing a penetration test and maintaining an effective PCI DSS penetration testing program.
.webp)
Segmentation testing is one of the most important parts of PCI DSS penetration testing when an organization uses network segmentation to reduce the scope of its CDE.
Network segmentation separates the CDE from other networks or systems that do not need direct access to cardholder data. Organizations may use firewalls, network access controls, VLANs, routing rules, security groups, or other technical controls to create these boundaries.
However, segmentation only reduces risk and PCI DSS scope if those boundaries actually work. Requirement 11.4.5 requires penetration testing of segmentation controls when segmentation is used to isolate the CDE from other networks.
Testing should confirm that:
For example, suppose an organization separates its payment processing environment from its corporate network using multiple firewall rules and access controls. A segmentation test should not simply review those rules. The tester should attempt to determine whether an attacker on the corporate network can bypass or move through those controls and reach the CDE.
Requirement 11.4.5 also requires the testing to be performed by a qualified internal resource or qualified external third party, with organizational independence. The tester does not have to be a QSA or ASV for this requirement.
Requirement 11.4.6 applies specifically to service providers.
When a service provider uses segmentation to isolate its CDE from other networks, the segmentation controls must be penetration tested at least every six months and after changes to segmentation controls or methods.
The test should confirm that the segmentation controls remain operational and effective and that they properly isolate the CDE from out-of-scope systems.
The 6-month frequency is particularly important for service providers because their environments may involve complex infrastructure, shared services, and multiple customer environments. A segmentation failure can therefore have consequences beyond a single internal network.
Requirement 11.4.7 applies to multi-tenant service providers. These providers must support their customers in performing external penetration testing under Requirements 11.4.3 and 11.4.4. A multi-tenant service provider can generally meet this requirement by either:
Any evidence provided to customers should contain enough information to demonstrate that the relevant requirements have been addressed. Redacted penetration testing results may be used where appropriate.
This requirement is particularly relevant to organizations using shared hosting, cloud, SaaS, or other multi-tenant environments where customers cannot independently control the underlying infrastructure.
PCI DSS penetration testing scope should align with the organization's cardholder data environment and the systems that can affect its security.
The CDE is not necessarily limited to the servers that directly store cardholder data. Depending on the architecture, connected systems and security controls may also need to be considered when determining the appropriate testing scope.
The CDE includes systems and components involved in storing, processing, or transmitting cardholder data. Depending on the organization's environment, this can include:
The goal is to identify the complete environment that participates in the cardholder data flow and understand how those systems are connected.
Organizations should also evaluate systems that can affect the security of the CDE. Examples may include:
For example, an identity system may not store cardholder data but could provide administrative access to a CDE server. A compromise of that identity system could therefore become an attack path into the CDE.
The same principle applies to network infrastructure and administrative access systems. Scope should be based on how systems interact with and affect the security of the cardholder data environment.
Modern payment environments often depend on web applications, mobile applications, APIs, third-party integrations, and cloud services. These interfaces can introduce attack paths that are not obvious from a traditional network diagram.
Payment portals may expose authentication and transaction functions. APIs may process payment information or connect applications to payment services. Integrations may also transfer data between the CDE and external systems.
These components should therefore be considered carefully when defining the PCI DSS penetration testing scope. A well-scoped test should make it clear which applications, APIs, infrastructure, and network boundaries were tested and how they relate to the CDE.
Preparing for PCI DSS penetration testing should start before the tester begins technical work. Good preparation helps prevent scope gaps and makes the final report more useful for both security teams and PCI DSS assessors.
Start by confirming which systems, applications, networks, and processes are within PCI DSS scope.
PCI DSS v4.x also requires organizations to document and confirm their PCI DSS scope at least annually, making scope management an important part of the broader compliance process.
Document how cardholder data enters, moves through, and leaves the environment. Identify:
This makes it easier to identify potential attack paths and testing boundaries.
Clearly identify the CDE and systems that can affect its security. Do not assume that a system is out of scope simply because it does not store cardholder data. Consider whether a compromised system could provide access to, control over, or connectivity with the CDE.
If segmentation is being used to isolate the CDE, document the controls that create those boundaries. This may include:
The penetration test should then validate whether those controls actually provide the intended separation.
Your statement of work should clearly identify:
Clear scope documentation reduces the risk of completing a technically strong penetration test that does not adequately demonstrate coverage for the PCI DSS assessment.
Review the tester's experience, technical skills, methodology, and relevant industry experience. The PCI DSS requirement focuses on qualification and organizational independence. A tester does not have to be a QSA or ASV simply to perform the penetration test.
.webp)
Give the testing team enough information to understand the environment and conduct meaningful testing. Depending on the engagement, this may include:
Providing the right context allows testers to focus on realistic attack paths rather than spending the engagement trying to understand basic architecture.
The testing team should execute the agreed methodology and assess the relevant attack surfaces. Testing should combine appropriate automated tools with manual techniques.
Manual testing is particularly important for identifying attack chains, business logic weaknesses, access-control issues, and other vulnerabilities that automated scanners may not understand.
Once the test is complete, review the findings based on risk and business impact. Critical and high-risk issues that could expose the CDE should receive prompt attention. Remediation should be documented so the organization can demonstrate how identified weaknesses were addressed.
After remediation, retest the affected systems and vulnerabilities. The goal is to verify that the original vulnerability has actually been corrected and that the fix has not introduced another weakness.
Keep relevant evidence together, including:
Good documentation makes it easier to demonstrate that the PCI DSS penetration testing requirements were addressed throughout the assessment period.
A PCI DSS penetration test should do more than generate a list of vulnerabilities. It should help organizations understand whether an attacker could exploit weaknesses to reach sensitive systems or cardholder data.
ioSENTRIX's PCI-DSS Compliance Services include PCI-focused penetration testing, segmentation testing, POS application analysis, and security evaluations designed around the organization's environment.
ioSENTRIX performs penetration testing across networks, applications, and infrastructure using a combination of manual and automated techniques.
Its penetration testing services cover areas such as web applications, APIs, mobile applications, SaaS environments, cloud infrastructure, networks, and other specialized attack surfaces.
For PCI DSS environments, this approach can help organizations evaluate both external attack surfaces and internal paths that could lead toward the CDE.
Segmentation testing is particularly important when an organization relies on network isolation to limit PCI DSS scope. ioSENTRIX's PCI-DSS compliance offering specifically includes segmentation testing and assessments of the Cardholder Data Environment.
This allows testing to focus not only on individual vulnerabilities but also on whether the security boundaries protecting the CDE work as intended.
Automated tools are useful for identifying known vulnerabilities, but they do not always understand how an application's features or systems can be combined to create an attack.
ioSENTRIX combines automated tools with manual testing and focuses on business logic and abuse cases. Its penetration testing methodology includes turning legitimate use cases into abuse cases to identify weaknesses that may not be detected by conventional automated testing.
This is particularly useful for payment environments where authorization, transaction workflows, and application logic can have a direct impact on security.
A useful PCI DSS penetration testing report should make remediation practical. ioSENTRIX provides detailed findings with evidence, remediation guidance, and retesting options.
Its PTaaS offering also includes reporting and remediation guidance, with retesting available to verify that fixes are effective. This supports the remediation and validation cycle required under Requirement 11.4.4.
Documentation is an important part of PCI DSS penetration testing. Organizations need evidence showing what was tested, which weaknesses were identified, and how those findings were addressed.
ioSENTRIX states that its penetration testing services provide audit-ready reports mapped to compliance frameworks, including PCI DSS. Its PTaaS offering also provides reports mapped to PCI DSS and other major compliance frameworks.
If your organization is preparing for a PCI DSS assessment, the testing scope and reporting format should be discussed before the engagement begins.
A PCI DSS assessment should not be the first time you discover gaps in your security testing. Make sure your penetration testing covers the cardholder data environment, connected systems, external attack surfaces, and segmentation controls.
ioSENTRIX can help you validate your PCI DSS penetration testing scope, identify exploitable weaknesses, and verify remediation before your assessment. Get in touch with our security experts to discuss your environment and prepare for your next PCI DSS assessment.
For entities to which Requirement 11.4 applies, penetration testing is a PCI DSS requirement rather than simply a recommended security activity. The exact applicability depends on the organization's PCI DSS scope and assessment method.
Internal and external penetration testing must generally be performed at least once every 12 months and after significant infrastructure or application upgrades and modifications. Segmentation testing under Requirement 11.4.5 is required at least every 12 months and after changes to segmentation controls or methods. Service providers subject to Requirement 11.4.6 have a six-month segmentation testing frequency.
Segmentation testing evaluates whether the technical controls separating the CDE from other networks actually work as intended. The tester attempts to determine whether an attacker or compromised system outside the CDE could bypass the segmentation controls and reach the cardholder data environment.
No. Vulnerability scanning and penetration testing serve different purposes. A vulnerability scan can identify known weaknesses, while penetration testing evaluates whether vulnerabilities and other weaknesses can be exploited in realistic attack scenarios. A scan alone does not provide the same level of validation as a penetration test.
The organization should assess the risk, prioritize remediation, correct the vulnerability or security weakness, and perform appropriate retesting to verify that the issue has been addressed. Findings should be documented along with remediation and retest evidence. Critical findings that create a realistic path to cardholder data should receive immediate attention.
