Use the correct requirement before planning the work

PCI DSS v4.0.1 is the reference for this article. Requirement numbers matter: attaching an accurate test result to the wrong requirement can obscure a real coverage gap. This overview addresses the defined approach; use the complete standard and applicable assessment process for the detailed criteria.

  • 11.4.1: documented methodology covering the CDE perimeter, critical systems, internal and external perspectives, network and application layers, and relevant segmentation.
  • 11.4.2 and 11.4.3: internal and external penetration tests respectively, at least every 12 months and after significant infrastructure or application changes.
  • 11.4.4: correct exploitable weaknesses according to risk and repeat testing to verify corrections.
  • 11.4.5: when segmentation isolates the CDE, test it at least every 12 months and after changes to segmentation controls or methods.
  • 11.4.6: service providers using that segmentation test it at least every six months and after segmentation changes.
  • 11.4.7: multi-tenant service providers support customers’ external penetration testing and correction verification.

Reference: PCI DSS v4.0.1 — Requirements 11.4.1–11.4.7

Keep targeted risk analysis in its proper role

Requirement 12.3.1 addresses targeted risk analysis where a requirement explicitly permits an organization to determine an activity’s frequency. Requirement 12.3.2 addresses the customized approach. A TRA is not a general permission to reduce scope or extend fixed testing intervals.

Requirement 11.4.1 does not introduce a universal TRA for penetration-test scoping. Documenting a defensible scope is still essential. Keep the scope rationale, the treatment of findings, and any required TRA distinct so reviewers can see which question each document answers.

For a customized approach, work through its control objectives, documentation, risk analysis, and assessment procedures explicitly. Do not call an ordinary scope exception a customized approach.

Reference: PCI SSC — targeted risk analysis guidance and its two uses

Separate authenticated scanning from penetration testing

Authenticated internal vulnerability scanning is addressed in 11.3.1.2. Requirement 11.4.4 is about correcting and retesting findings; it is not an authenticated internal penetration-testing requirement.

A team may still choose credentialed or assumed-access scenarios when they answer an important security question. Record those starting conditions in the methodology and report. Explain whether an outcome depended on a supplied account, an approved exception, or access obtained during the engagement. That distinction makes the evidence interpretable.

Automation can help a tester investigate the environment. It cannot, on its own, establish that a complete penetration-testing methodology was executed. Conversely, describe a tool’s actual limits rather than claiming that scanners cannot perform any authenticated checks.

Reference: PCI DSS v4.0.1 — Requirements 11.3.1.2 and 11.4

Prepare an evidence package that can be reviewed

Organize the report around what was tested, the conditions under which it was tested, and what the result establishes. Include a current target inventory, agreed boundaries, methodology, dates, tester qualifications and independence, findings, and the limitations of coverage.

Maintain a traceable link from each finding to its corrective action and retest. If a control change affected several systems, explain which systems were rechecked and why. Preserve unresolved items as unresolved; a planned fix is not a verified result.

Review the scope with the assessment team early enough to resolve missing access or third-party restrictions. That conversation is easier before testing starts than when an assessment deadline exposes an evidence gap.