Notifications
Clear all
Topic starter
11/08/2026 3:18 pm
TL;DR: PCI DSS v4.0.1 expands internal penetration testing scope beyond traditional network segments to include cloud infrastructure, SaaS applications, and build pipelines such as GitHub Actions, Azure DevOps, and Jenkins, because credential theft and pipeline compromise can provide direct paths into the CDE, according to Bishop Fox. For IAM and PAM teams, segmentation must now be validated across authentication, authorization, and identity-bearing systems, not just network boundaries.
NHIMG editorial — based on content published by Bishop Fox: PCI DSS internal penetration testing now spans cloud and build pipelines
Questions worth separating out
Q: What fails when PCI segmentation is tested only at the network layer?
A: Network-only testing misses the most common bypass route: authenticated access.
Q: Why do cloud and SaaS identities matter in PCI DSS internal testing?
A: Because cloud tenants, SaaS platforms, and their administrative identities can control, store, or expose systems that touch the CDE.
Q: How should security teams test build pipelines in PCI environments?
A: They should treat pipelines as privileged identities that can alter production-adjacent systems.
Practitioner guidance
- Map CDE reachability through identity paths Document every login, token, service account, and session that can reach systems near the CDE, including SaaS and cloud admin paths.
- Include CI/CD identities in penetration scope Treat GitHub Actions, Azure DevOps, Jenkins, and similar systems as part of the attack surface when they can deploy into or modify systems connected to the CDE.
- Test authentication segmentation, not just network segmentation Validate whether a stolen account, reused session, or over-permissioned role can reach CHD through internal apps, SaaS tools, or shared services even when direct network routes are blocked.
What's in the full article
Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:
- The scoping inputs used to map cardholder-data flows, segmentation boundaries, and third-party connections.
- The practical spreadsheet structure used to document tested segments, IP addresses, and open ports.
- The differences between an IPT report and a segmentation findings report for QSA review.
- The kinds of environments Bishop Fox uses to test from, including internal VMs, appliances, and compromised pods.
👉 Read Bishop Fox's guide to PCI DSS internal penetration testing and scoping →
PCI DSS IPT scoping now includes cloud and pipelines, what changes?
Explore further
11/08/2026 3:30 pm
PCI scoping is now an identity problem as much as a network problem. The article reflects a wider shift in which cloud tenants, SaaS applications, and deployment pipelines can no longer be treated as peripheral to segmentation. For identity practitioners, that means the boundary between IAM, PAM, and PCI testing is thinner than many governance models assume. If a credential or session can bridge into the CDE, segmentation is only as strong as the identity path feeding it.
A question worth separating out:
Q: Who is accountable when segmentation fails because of identity abuse?
A: Accountability sits with the environment owner, the identity governance team, and the assessor responsible for confirming scope and control effectiveness. PCI DSS requires the organisation to document what is in scope and prove segmentation works as intended. If identity paths are ignored, the failure is usually a governance gap, not only a technical one.
👉 Read our full editorial: PCI DSS internal penetration testing now spans cloud and build pipelines
