Notifications
Clear all
Topic starter
06/09/2026 9:02 am
TL;DR: PCI DSS 4.0 now expects documented methodology, annual internal and external testing, retesting after significant change, and verified remediation, while FireCompass argues that annual point-in-time pentests no longer match modern change cadence. The governance gap is not just tooling, but whether compliance evidence is continuous, exploit-validated, and tied to the real attack surface.
NHIMG editorial — based on content published by FireCompass: PCI DSS 4.0 Penetration Testing Requirements in 2026: What You Need to Know
By the numbers:
- DAST tools also carry false positive rates between 40 and 70 percent.
Questions worth separating out
Q: What breaks when PCI 4.0 penetration testing is still done only once a year?
A: Annual-only testing breaks the evidence chain because the environment changes faster than the assessment cycle.
Q: Why do scanners not count as PCI DSS 4.0 penetration testing evidence?
A: Scanners report possible weaknesses, but PCI DSS 4.0 expects proof that a vulnerability is actually exploitable and that the fix stopped the exploit.
Q: How should security teams handle retesting after significant infrastructure or application changes?
A: They should tie retesting to change management, not to calendar reminders.
Practitioner guidance
- Map every PCI test to a documented methodology Define the test methodology, scope, and evidence standard before the next cycle so each engagement covers both network-layer and application-layer testing in the cardholder data environment.
- Trigger retesting after material environment change Wire significant deployment and infrastructure changes into a retest workflow so a fix or release does not sit unvalidated until the next annual assessment window.
- Preserve exploit proof for each finding Store working proof-of-concept evidence, remediation timestamps, and retest results together so the QSA can trace exploitability to verification without separate evidence hunts.
What's in the full article
FireCompass's full article covers the operational detail this post intentionally leaves for the source:
- The exact requirement-by-requirement breakdown of PCI DSS 4.0 penetration testing expectations and assessor interpretation.
- Operational examples of how PTaaS changes retesting cadence, evidence capture, and scope management in practice.
- Platform-specific capabilities for producing working proof-of-concept exploits and maintaining audit trails.
- The vendor's view of false positives, segmentation validation logistics, and compliance workflow integration.
👉 Read FireCompass's analysis of PCI DSS 4.0 penetration testing requirements in 2026 →
PCI DSS 4.0 pentesting in 2026: are your controls keeping up?
Explore further
06/09/2026 9:02 am
Continuous evidence has become the real compliance control: PCI DSS 4.0 does not merely ask whether a pentest happened, it asks whether the programme can prove exploitation, remediation, and retest outcomes under a changing environment. Annual testing creates a visibility gap whenever applications or infrastructure move faster than the test cycle. That gap is where assessor findings emerge, because the evidence trail is the control.
A question worth separating out:
Q: When does segmentation testing need to be revisited under PCI DSS 4.0?
A: Segmentation should be revisited whenever the CDE boundary changes and on the recurring cadence your assessor expects. If routing, firewall rules, or privileged access paths change, the old validation may no longer prove isolation. Teams should treat segmentation as a control that can drift, not as a one-time design decision.
👉 Read our full editorial: PCI DSS 4.0 penetration testing in 2026: where programs fail
