Penetration testing (pen testing) remains largely the same in PCI version 4.0 as it was intended in PCI version 3.2.1, but the explanation of the intent is clarified. 

Requirement 11.3 is now 11.4 in v 4.0. From the beginning, the DSS is now clearer on the intended actions required by the entity (the company whose name is on the assessment). Req. 11.4.1 requires the entity to maintain a penetration testing methodology. The methodology must be defined, documented, and implemented by the entity. Creating a methodology is not an easy task and takes into consideration many different aspects that affect the environment. A pen test methodology is not a cookie cutter item across multiple organizations, but rather is specific to each environment and the assets contained within.

Many companies outsource their pen testing and rely on another company to provide the methodology. If the pen testing is done by the entity, Req. 11.4.1 is very specific about what the pen testing methodology must include. I won’t relist the requirements here because they are the same as in v3.2.1, but I will point out that the Council has provided a very thorough definition of internal pen testing and external pen testing. There isn’t any clarification needed after reading these definitions:

Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and INTO [emphasis mine] the CDE from trusted and untrusted internal networks.

Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructure. 

A pen test is not just exploiting vulnerabilities on a vulnerability scan (however, doing so is certainly part of a pen test). A pen tester uses tools to get started, but the real skill lies in the manual efforts. Pen testers are creative and think outside the box and can take a vulnerability to the next level or combine multiple vulnerabilities for unexpected outcomes. If you receive a pen test report from a third party and it’s just automated tools or it doesn’t have any findings, look closely at the methodology used to see if it matches your expectations and the requirements of Req. 11.4.1.

In Req. 11.3.2, the Council states when they expect pen testing to occur: it’s still yearly and after any significant infrastructure or application upgrade or change. In this instance, v3.2.1 was more descriptive on defining change. It stated “at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment”. It remains to be clarified why the additional explanation was excluded, but my guess is it’s difficult to list everything that should be considered a significant change and any list that would be provided by the Council would be considered the only list to enforce so excluding a definition is much better. 

Req. 11.4.2 continues with how internal pen testing can be performed and by whom. It does not require a specific certification to perform penetration testing according to the DSS. The DSS requires a qualified internal resource (or a third party can be used). It’s difficult to describe a qualified internal resource. The pen tester must be independent and not have any configurational influence over the systems being tested. That’s the easiest part to identify. As for the pen tester’s abilities, the assessor will ask for the pen tester’s certifications, experience, methodology used, and tools used, and then attempt to assess their level of understanding. This is not a “run some tools, check the box” requirement. The devil is in the details, as they say.

Req. 11.4.3 switches to external pen testing. The same requirements are needed for external pen testing as internal pen testing, but the testing is performed from a different vantage point (outside looking in). Be sure your pen test includes testing APIs (application programming interface) that are taking card payments, as well as any internet-facing servers that can serve up a payment page.

When the internal and/or external penetration test is completed, Req. 11.4.4 addresses the necessary remediation. Req. 6.3.1 is called upon to define the risk of each issue identified in the pen test report and the timeframe in which that level of risk should be remediated: 

Req 6.3.1 Security vulnerabilities are identified and managed as follows: 

• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). 

• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. 

• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment. 

• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

The remediation must be completed on ALL vulnerabilities and security weaknesses noted in the pen test report. This isn’t like the vulnerability scans where only the riskiest vulnerabilities must be remediated. ALL identified items must be remediated in a pen test (unless the report identifies the issue as informational only). Once remediation is complete, another pen test must be performed. The follow-up test would look for the same vulnerabilities found on the systems in the original pen test. It is not required that the entire pen test be re-performed. The intent is only to confirm those vulnerabilities found in the original test were remediated successfully. If new vulnerabilities are found during this follow-up test, while they SHOULD be remediated, it is not a requirement of the PCI DSS (although they may likely be identified during the next quarterly vulnerability scan and will be required to be remediated according to Req. 11.3.x).

Req. 11.4.5 goes on to talk about segmentation. If the network is flat (does not contain any subnets), the entire network is in scope for the assessment as well as the penetration test. If segmentation is used, the scope of the internal pen test includes everything in the CDE as well as everything used to create the perimeter of the CDE. If it’s in scope for the assessments, contains cardholder data, transmits cardholder data (even if it’s encrypted or later tokenized by your organization), and is not a person, it must be pen tested according to Req. 11.4.x. The Penetration Testing Guidance Information Supplement from the Council gives scoping examples and a definition of critical systems. This can be used to scope any pen test.

The supplement goes on to say that for the purposes of a penetration test, there may be additional systems outside the CDE boundaries that could affect the security of the CDE. These systems should also be considered to be critical systems. This reinforces the DSS in that the shared services devices are in-scope for the pen test. Critical systems are to be identified by the entity, and the inventory is to be presented and explained to the assessor. Be sure to include any warm disaster recovery sites that include cardholder data.

People are also in scope for the assessment. Why aren’t they required to be tested? Req. 12.6.3.1 requires that the security awareness training includes training about various social engineering attempts, and Req. 5.4.1 requires controls to protect against phishing. That’s as close to social engineering testing as the DSS comes. The DSS does not require social engineering testing at this time. You can always scope your pen test to include social engineering… it’s just not a PCI DSS requirement. With the vishing, smishing, and phishing going on, I wonder if we’ll see it as a requirement in upcoming versions.

I digress – back to segmentation. If the network is segmented, Req. 11.4.5 requires that the controls that create the segments be tested annually and after any changes to those controls or methods. Testing of these controls must be covered in the entity’s methodology to ensure they are functioning as expected. Functioning as expected means ensuring all out-of-scope segments cannot communicate with in-scope segments on any port, using any protocol. None. No communication of any kind. This can be tested in various ways and the entity’s methodology should outline the testing approach that is most useful for the environment.

Req. 11.4.6 adds an additional requirement for Service Providers being assessed in that pen testing of segmentation controls is required to be performed every six months and after any change to the segmentation controls.

Multi-tenant service providers will be required to support their customers’ efforts for pen testing. As of March 31, 2025, multi-tenant service providers must allow the tenant access to perform pen testing, or the service provider must conduct the pen testing and provide passing results to the tenant – keeping in mind some sensitive details of the pen test report may need to be redacted by the service provider to protect itself or other tenants. This has been a challenge in the past, and I’m anxious for Req. 11.4.7 to take effect.

Pen tests vary based on the skill level of the pen tester. This is not an area you’ll want to cut corners… the bad guys are willing to do anything to get into your network. You’ll want a pen tester who is also willing to go the extra mile. Now is the time to review your strategy for this important component of your cyber security program – not just for the sake of compliance with PCI DSS v4.0, but from an overall cyber risk perspective as well.