PCI DSS network segmentation: scope, drift, and the evidence gaps QSAs miss
Sienna VanceApril 29, 2026
Key takeaways
PCI DSS v4.0 introduced a customized approach option in Requirement 12.3.2 that requires a targeted risk analysis for each custom control -- but QSAs report that most organizations document generic risks rather than control-specific ones, leaving a gap that survives the annual assessment.
SAQ A eligibility requires that the merchant has no ability to impact the security of the payment page. Merchants using iframes their developers can modify do not qualify for SAQ A and are operating outside their correct scope category without realizing it.
Segmentation testing under PCI DSS Requirement 11.4.5 must be performed at least annually and after any significant change to segmentation controls. Most organizations test annually but cannot demonstrate evidence of post-change testing -- a finding that QSAs increasingly treat as a standalone deficiency.
Vulnox analysis shows that 42% of organizations with documented network segmentation have at least one firewall rule permitting traffic between the CDE and an in-scope adjacent network segment that was not reflected in the current network diagram. (Vulnox assessment data, 2025)
Configuration drift is the primary mechanism by which organizations that passed their last QSA assessment are non-compliant six months later. Firewall rule changes added outside the change control process are the single most common source.
TL;DR
PCI DSS network segmentation failures are rarely about not having a firewall. They are about the gap between what the network diagram shows, what the firewall rules actually permit, and what a QSA will accept as evidence. PCI DSS v4.0 raised the evidence standard in ways most organizations have not caught up to yet. The compliance exposure is real, and it does not wait for the annual assessment.
The segmentation that passed the QSA and failed the breach investigation
A mid-size e-commerce merchant had maintained SAQ D compliance for three years. Their network diagram showed clear segmentation between the CDE and the corporate network. Their QSA signed off annually. When a forensic investigation followed a cardholder data breach, investigators found a firewall rule added 14 months earlier by a network engineer handling an urgent vendor connectivity request. The rule permitted unrestricted outbound traffic from a CDE server to a subnet classified as out-of-scope on the network diagram -- a subnet that had since been connected to corporate infrastructure. The rule was not in the change log. The network diagram had not been updated. The QSA had reviewed the diagram, not the running configuration.
The merchant was technically non-compliant for 14 months before the breach. The annual QSA assessment had not detected it because the assessment validated documentation, not operational state. PCI DSS requires continuous compliance. The annual assessment is evidence of compliance at a point in time. Those are not the same thing, and the card brands do not treat them as equivalent when assigning liability.
How PCI DSS defines segmentation scope and what v4.0 changed
PCI DSS defines the cardholder data environment (CDE) as all system components that store, process, or transmit cardholder data, plus all systems that are connected to or could impact the security of those systems. The second category -- systems connected to CDE systems -- is where scope creep happens. A system does not need to touch cardholder data to be in scope. It needs to be able to reach a system that does. Effective network segmentation isolates the CDE such that out-of-scope systems have no access path to CDE systems, which removes them from the compliance perimeter entirely. Without that isolation, the scope expands to include every system with network reachability to the CDE.
Example
PCI DSS v4.0, effective March 2024, introduced two changes that directly affect segmentation compliance. First, Requirement 12.3.2 formalized the customized approach, allowing organizations to implement alternative controls to meet the intent of a requirement -- but requiring a targeted risk analysis for each customized control, documented with specific evidence of how the custom control addresses the vulnerability the standard control was designed to mitigate. Second, Requirement 11.4.5 clarified that segmentation testing must occur after any significant change to segmentation controls, not just annually. Both requirements have generated new deficiency categories that did not exist under PCI DSS v3.2.1.
The customized approach risk analysis under Requirement 12.3.2 must address the specific vulnerability the standard control mitigates, the inherent risk of the customized control, and the compensating factors that bring residual risk to an acceptable level. A risk analysis that documents generic threats (e.g., unauthorized access, data exfiltration) without tying them to the specific control being replaced will not satisfy a rigorous QSA review. This is the most common documentation failure Vulnox observes in v4.0 gap assessments.
What segmentation looks like when Vulnox tests the running configuration, not the diagram
Assessment base: Vulnox client assessment data, 2024-2025, covering e-commerce merchants, payment processors, and service providers subject to PCI DSS across retail, hospitality, and financial services sectors
Firewall rules permitting CDE-to-adjacent traffic not reflected in network diagrams
In 42% of assessments involving documented network segmentation, Vulnox found at least one active firewall rule permitting traffic between the CDE and an adjacent network segment that was classified as out-of-scope on the current network diagram. The rules were not orphaned or legacy configurations -- they were operational rules added to support business functions, added outside the formal change control process or without updating the network documentation. The mismatch between diagram and running configuration is the structural gap that QSA documentation reviews cannot catch.
A QSA reviewing the network diagram and a sample of firewall rules may not identify this gap if the sampled rules match the documented architecture. The only reliable detection method is comparing the full exported firewall ruleset against the network diagram systematically, not sampling. Organizations that perform this comparison as part of continuous monitoring rather than pre-assessment preparation find these gaps earlier and with far lower remediation cost.
SAQ A merchants with iframe configurations that trigger SAQ D scope
SAQ A applies to merchants who have outsourced all cardholder data functions to a PCI DSS compliant third-party processor, with no electronic storage, processing, or transmission of cardholder data on the merchant's systems or premises. The eligibility requirement includes that the merchant has no ability to impact the security of the payment page. Vulnox assessments have identified merchants using embedded payment iframes whose development teams had the ability to modify the iframe source, the page hosting it, or the content security policy governing it. All three configurations disqualify SAQ A eligibility and require at minimum SAQ A-EP, which carries significantly broader control requirements.
The downstream compliance exposure is not just the wrong SAQ. A merchant who self-certifies SAQ A compliance while operating under SAQ A-EP or SAQ D scope has submitted an inaccurate compliance attestation to their acquiring bank. If a breach occurs, the acquiring bank''s forensic investigation will identify the scope mismatch and the merchant faces liability for non-compliance during the breach period, in addition to the breach itself.
Post-change segmentation testing not performed or not documented
PCI DSS v4.0 Requirement 11.4.5 requires segmentation testing at least once every 12 months and after any significant change to segmentation controls or methods. In assessments of organizations that had completed annual segmentation tests, Vulnox consistently found no documentation of post-change testing for firewall modifications, VLAN reconfigurations, or network architecture changes made during the year. The changes were documented in change records. The segmentation testing that Requirement 11.4.5 requires following those changes had not been performed or had not been documented as segmentation tests -- a distinction QSAs are beginning to enforce as a separate requirement from the annual test.
An organization with a clean annual segmentation test result and undocumented post-change tests has a documented deficiency under v4.0, regardless of whether the changes affected segmentation effectiveness. The evidence standard is the issue: v4.0 requires proof that testing occurred, not just that segmentation is currently effective.
Reducing CDE scope does not always reduce compliance cost
Common belief
The primary goal of network segmentation for PCI DSS is scope reduction: fewer systems in scope means fewer controls to implement and a smaller, cheaper assessment.
What we found
In post-breach forensic support engagements, the most common regulatory exposure pattern is not a merchant who skipped segmentation. It is a merchant who implemented segmentation to qualify for a reduced SAQ type, did not maintain the continuous evidence obligations that segmentation requires, and then faced liability for the period between their last documented compliance and the breach date -- a period that often runs 12 to 24 months.
Scope reduction through segmentation requires maintaining the segmentation controls that achieve the scope reduction. Those controls -- firewall configurations, VLAN policies, access control lists, segmentation testing -- are themselves PCI DSS requirements with ongoing evidence obligations. For smaller merchants, the cost of maintaining and documenting segmentation controls can exceed the cost of including a few additional systems in scope under a flat network model. The calculation depends on transaction volume, system architecture, and the complexity of the segmentation implementation. Sienna Vance''s observation from regulatory evidence reviews is that the most expensive compliance failures are usually not scope-expansion failures -- they are scope-reduction attempts where the organization implemented segmentation without building the evidence program to support it, then failed a forensic investigation because they could not demonstrate the segmentation was continuously maintained.
Four PCI DSS segmentation gaps that survive annual QSA assessments
Customized approach risk analyses that document generic risks
PCI DSS v4.0 Requirement 12.3.2 requires a targeted risk analysis for each control where the customized approach is used. The analysis must address the specific vulnerability the standard control was designed to mitigate. QSAs report -- and Vulnox assessment data confirms -- that most organizations produce risk analyses that document general threat categories rather than control-specific vulnerability mechanisms. A risk analysis for a custom logging implementation that cites unauthorized access and data exfiltration as risks, without describing how the custom logging mechanism addresses the specific detection gap the standard control closes, will not survive a rigorous QSA review and will not provide a defensible evidence record in a breach investigation.
Network time protocol (NTP) synchronization across CDE systems
PCI DSS Requirement 10.6 requires that all critical system clocks and times are synchronized using time-synchronization technology. In practice, CDE systems with unsynchronized clocks produce log records that cannot be reliably correlated during a forensic investigation. QSAs verify that NTP is configured. They rarely verify that all CDE systems are actually synchronizing to the same authoritative source with consistent time offsets. Systems that have drifted from NTP synchronization produce log correlation gaps that are invisible in normal operations and become material evidence failures in post-breach investigations. Regulators examining breach timelines will identify these gaps.
Shared hosting environments and CDE isolation
Merchants using shared hosting providers frequently assume that PCI DSS compliance is the hosting provider''s responsibility. The responsibility split is more nuanced: hosting providers are responsible for the physical environment and shared infrastructure, but merchants retain responsibility for their application layer controls, including segmentation from other tenants. A merchant on a shared hosting platform where the provider is PCI DSS compliant but where tenant isolation relies on application-level controls rather than network-level segmentation has a scope that extends to the shared infrastructure. Most merchants in this configuration do not know it and are using SAQ types that do not reflect their actual scope.
Third-party JavaScript on payment pages
PCI DSS v4.0 Requirement 6.4.3 added explicit requirements for managing all payment page scripts, including third-party scripts loaded by the payment page. Organizations must maintain an inventory of all scripts, have a documented justification for each, and implement integrity controls. Third-party scripts that are not in the inventory -- analytics tags, chat widgets, A/B testing tools added by marketing -- are a compliance deficiency under v4.0 regardless of whether they handle cardholder data. They expand the scope of the payment page environment and the evidence obligations that come with it.
SAQ types and what segmentation each actually requires
SAQ A
Applies only when all payment processing is fully outsourced and the merchant has zero ability to impact the security of the payment page. No cardholder data on merchant systems. No iframe the merchant can modify. Covers 22 requirements.
Most merchants who self-certify SAQ A have development teams with some access to payment page configuration. If a developer can change the page that hosts the payment iframe, or modify the CSP headers, the merchant does not qualify. SAQ A-EP or SAQ D applies instead.
SAQ A-EP
Applies when the merchant outsources payment processing but uses a script or iframe on a merchant-controlled page. The merchant''s page is in scope because it loads the payment mechanism. Covers approximately 190 requirements.
The jump from SAQ A to SAQ A-EP is the single largest scope expansion in PCI DSS self-assessment. Organizations that discover they do not qualify for SAQ A mid-assessment face a compliance program that is three to four times larger than they planned for.
SAQ D (Merchant)
Applies to merchants that do not qualify for any other SAQ type, including those who store cardholder data electronically or have complex environments. Covers all 12 PCI DSS requirements and most sub-requirements. Typically requires a QSA for Level 1 merchants.
SAQ D scope includes full network segmentation evidence obligations, annual penetration testing, and the v4.0 customized approach documentation requirements if any custom controls are in use. This is the category where undocumented configuration drift creates the highest regulatory exposure.
Where PCI DSS enforcement is heading after v4.0
By end of 2026, acquiring banks will begin including Requirement 6.4.3 (payment page script inventory and integrity) in their standard merchant compliance questionnaires, making undocumented third-party JavaScript a direct compliance attestation risk rather than a QSA finding.
Requirement 6.4.3 became a best practice under PCI DSS v4.0 and is mandatory from March 2025. Card brands have signaled that client-side skimming attacks -- the threat class Requirement 6.4.3 was designed to address -- are a primary enforcement focus. Acquiring banks lag card brand guidance by 12 to 18 months in questionnaire updates. The update cycle puts standard questionnaire inclusion in late 2025 to mid-2026.
Confidence: highTwo or more major acquiring banks publish updated merchant compliance questionnaires that include Requirement 6.4.3 script inventory documentation as a scored question by end of 2026.Post-change segmentation testing documentation will become a standalone audit finding category -- separate from annual segmentation test results -- in QSA assessment reports by 2027, as v4.0 assessment experience accumulates and QSAs standardize on the distinction.
PCI DSS v4.0 Requirement 11.4.5 explicitly separates annual and post-change testing obligations. QSAs are currently treating them inconsistently -- some assess post-change testing as part of the annual testing finding, others as a separate requirement. As the QSA community develops shared assessment practice on v4.0, the explicit requirement language will drive toward separate scoring. A published QSA guidance update from the PCI SSC on this distinction would accelerate standardization.
Confidence: mediumPCI SSC publishes assessment guidance that explicitly treats Requirement 11.4.5 annual and post-change testing as separately scored elements, or a majority of ROC templates in circulation by end of 2027 score them separately.
The annual QSA model is structurally mismatched to the compliance it is supposed to validate
PCI DSS compliance is a continuous obligation. The QSA assessment model produces a point-in-time snapshot. The gap between those two things is where most breach liability lives. A merchant who passes their annual assessment in January and experiences a breach in October was non-compliant for some period between those dates. The question in the forensic investigation is how long and what changed. That question is answered by operational evidence -- change logs, monitoring records, segmentation test documentation -- not by the prior year''s QSA report. Organizations that build their compliance programs around passing the annual assessment rather than maintaining continuous operational evidence are building toward a liability gap, not away from one. The regulatory evidence standard in a breach investigation is not whether the merchant had a clean QSA report. It is whether the controls were operating as documented at the time of the breach.
Counterargument
The counterargument is that continuous compliance monitoring is expensive and disproportionate for smaller merchants operating under SAQ A or SAQ B. That is a fair resource constraint. The response is not to treat the annual assessment as sufficient -- it is to implement lower-cost continuous controls: automated firewall rule change alerts, monthly network diagram reviews, post-change testing checklists. The cost of those controls is measurably lower than the cost of a forensic investigation that finds a 14-month compliance gap.
One thing to do this week
Export your current firewall ruleset and compare it line by line against your most recent network diagram. Do not sample -- compare the full ruleset. Flag every rule that permits traffic between any system and the CDE that is not reflected in the diagram as a documented, approved connection. That list is your segmentation drift gap. It is also the list a forensic investigator would build in the first 48 hours of a breach response. Building it yourself, before an incident, is the difference between finding a configuration issue and facing a compliance gap that predates the breach.
Further Reading
Gap Analysis
PCI DSS gap analysisVulnerability Assessment
vulnerability assessment servicesPCI DSS SAQ types explained: which one applies to your organization
https://vulnox.io/blog/pci-dss-saq-types-explainedPCI DSS Standards Overview
official PCI DSS standardsNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionOWASP Penetration Testing Guide
OWASP penetration testing guide
Frequently Asked Questions
How do I validate PCI DSS network segmentation under v4.0?
PCI DSS v4.0 Requirement 11.4.5 requires segmentation testing at least annually and after any significant change to segmentation controls. Validation requires comparing the full exported firewall ruleset against the current network diagram -- not sampling -- to identify rules permitting CDE access that are not reflected in the documented architecture. Evidence must demonstrate both the annual test result and post-change test documentation for any segmentation-affecting changes made during the year. QSAs are increasingly treating the absence of post-change test documentation as a standalone deficiency separate from annual test results.
What firewall rules are required for PCI DSS network segmentation?
PCI DSS Requirement 1 requires firewall rules that restrict all traffic between the CDE and untrusted networks, permit only explicitly authorized traffic using a default-deny posture, and restrict inbound and outbound traffic to only what is necessary for cardholder data functions. Rules must be reviewed at least every six months. The review must verify that each rule has a documented business justification and that rules added outside the change control process are identified and remediated. Rules permitting CDE-to-adjacent-network traffic that is not reflected in the current network diagram are the most common segmentation deficiency Vulnox identifies.
Does SAQ A apply if we use an iframe for payment processing?
SAQ A eligibility requires that the merchant has no ability to impact the security of the payment page. If the merchant''s development team can modify the iframe source, the page that hosts the iframe, or the content security policy headers governing the iframe, SAQ A does not apply. SAQ A-EP applies when the merchant uses a script or iframe on a merchant-controlled page. The scope difference is significant: SAQ A covers 22 requirements, SAQ A-EP covers approximately 190. Merchants who self-certify SAQ A while operating under SAQ A-EP scope have submitted an inaccurate compliance attestation to their acquiring bank.
What does PCI DSS v4.0 Requirement 12.3.2 require for customized controls?
Requirement 12.3.2 requires a targeted risk analysis for each control where the customized approach is used as an alternative to the standard requirement. The analysis must document the specific vulnerability the standard control was designed to mitigate, the inherent risk of the customized control, and the compensating factors that bring residual risk to an acceptable level. Risk analyses that document generic threats rather than control-specific vulnerability mechanisms will not satisfy a rigorous QSA review. This is the most common documentation failure in v4.0 gap assessments.
What is the compliance exposure if a PCI DSS breach occurs after a clean QSA assessment?
A clean QSA report establishes compliance at the point of assessment, not for the period following it. In a breach investigation, card brands and acquiring banks examine whether controls were operating as documented at the time of the breach. Configuration drift -- firewall rules added outside change control, network diagram updates not performed, post-change segmentation testing not documented -- creates a period of non-compliance that begins when the drift occurred, not when it was discovered. Merchants face liability for the full non-compliant period, which in documented cases has run 12 to 24 months before the breach.
What is PCI DSS scope and how does it expand beyond cardholder data systems?
PCI DSS scope includes all system components that store, process, or transmit cardholder data, plus all systems connected to or capable of impacting the security of those systems. A system does not need to handle cardholder data to be in scope -- it needs network reachability to a system that does. Effective segmentation eliminates that reachability for out-of-scope systems. Scope creep most commonly occurs through firewall rules added outside change control, cloud service connections not reflected in network diagrams, and shared hosting environments where tenant isolation relies on application-layer rather than network-layer controls.
What does PCI DSS v4.0 require for third-party scripts on payment pages?
PCI DSS v4.0 Requirement 6.4.3 requires merchants to maintain an inventory of all scripts on payment pages (including third-party scripts loaded by the page), document a business or technical justification for each, and implement integrity controls to prevent unauthorized script modification. This requirement became mandatory in March 2025. Scripts added by marketing teams -- analytics tags, chat widgets, A/B testing tools -- that are not in the inventory are a compliance deficiency regardless of whether they handle cardholder data. QSAs are beginning to assess script inventories as a routine part of payment page reviews.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.