PCI DSS penetration testing

PCI DSS calls for penetration testing of the cardholder data environment at both the network and application layers, from outside (external) and inside (internal) perspectives. If you use network segmentation to keep systems out of scope, the effectiveness of that segmentation must also be tested.

Testing is required at least annually and after any significant change to the environment. The exact clauses and any version-specific detail should always be confirmed against the current PCI DSS standard and with your assessor (QSA), as requirements are periodically revised. The council’s summary of changes for version 4.0 shows how the testing requirements moved between versions.

In version 4.0 (requirement 11.4.1 in the council’s summary of changes), the penetration testing methodology must be defined, documented and implemented by the entity, and the results retained for at least 12 months. The methodology includes a documented approach to assessing and addressing the risk from exploitable vulnerabilities and security weaknesses found during testing. Requirement 11.4.4 adds that findings are corrected in line with your assessment of the risk they pose.

The council’s guidance gives examples, such as an infrastructure or application upgrade or modification, or a new system component installation, and says that what is significant depends heavily on your risk assessment process and the configuration of your environment.

The PCI Security Standards Council’s penetration testing guidance puts the whole perimeter of the cardholder data environment, and any critical systems, in scope, both the external perimeter and the internal one. If segmentation controls are used to keep systems out of scope, testing them is required too.

In practice that usually means an external and an internal test, plus a web application test of any payment pages or applications that handle card data. If the environment runs in the cloud, the council’s cloud computing guidelines explain how responsibilities split with the provider; see also the cloud testing guide.

Purpose

Vulnerability scan: Identify, rank and report vulnerabilities that could lead to compromise

Penetration test: Find ways to exploit vulnerabilities to get past security features

When

Vulnerability scan: At least quarterly and after significant changes

Penetration test: At least annually and upon significant changes

How

Vulnerability scan: Automated tools combined with manual verification

Penetration test: A manual process that may use scanners, ending in a comprehensive report

A common source of confusion: PCI requires both regular vulnerability scanning and penetration testing. Scanning is an automated, recurring check for known vulnerabilities. Penetration testing is a deeper, manual-led exercise that attempts to exploit weaknesses and confirm whether controls actually hold. Passing scans does not satisfy the penetration-testing requirement.

Look for a firm that tests independently of the systems under test, documents its methodology, and produces a report structured so your assessor can map findings to the relevant requirements. Recognised accreditations such as CREST are a useful signal of quality, though PCI does not mandate one specific certification. Confirm the firm has done PCI-scoped work before and will retest remediated issues.

The council’s guidance also allows a qualified internal team to do the testing, if it is organisationally separate from the management of the systems tested. For version 4.0, the council’s summary of changes says the methodology is documented and the results are kept for at least 12 months.

The council says a report that merely lists vulnerabilities does not meet the intent of the test: it should clearly communicate what was tested, how it was tested, and the results. Its guidance offers a suggested outline, and states that it does not define specific reporting requirements, so confirm the format with your assessor.

Independence matters for who does the work. The guidance says qualified internal resources or a qualified third party may do the test if they are organisationally separate from the management of the target systems. It gives an example: a company carrying out your PCI DSS assessment cannot also do the penetration test if it was involved in installing, maintaining or supporting the systems.