Segmentation testing vs network penetration testing: which one your PCI scope needs
Segmentation testing is a targeted proof that out-of-scope networks cannot reach the cardholder data environment (CDE), while a network penetration test is a broader search for exploitable weaknesses across internal hosts, services and paths. Consider a payment team that must show its scope reduction holds and also wants a wide internal test. The two outputs answer different questions, so one report rarely does both jobs well. PCI DSS requirement 11.4.5 asks for penetration tests of segmentation controls at least every 12 months and after changes, confirming that the CDE is isolated from every out-of-scope system. Requirement 11.4.6 raises that frequency to every six months for service providers. If your organization is a service provider, the six-month cadence sets the calendar before any other decision. Confirm your entity type and the exact wording of your assessor's requirements before you fix a schedule.
Choose a segmentation test when the question is whether a defined boundary holds. Its scope is the segmentation controls themselves: the firewall rules, VLAN and routing boundaries, and any jump hosts or management paths that cross between CDE and non-CDE networks. The tester attempts to reach CDE systems from each out-of-scope network segment and records what succeeded or failed. Choose a full internal network penetration test when you need to know what an attacker on a compromised workstation could chain together, including credential reuse, misconfigured services and privilege escalation. That test is broader, takes longer, and produces findings that feed remediation across the estate. Ask the provider to show, in writing, which segments are in scope for each test and which assumptions they used about where an attacker starts.
How the two approaches differ on scope, frequency, method and evidence
This table compares a PCI DSS segmentation test with a full internal network penetration test across goal, trigger, boundary, frequency, method and evidence. Read it to see which engagement answers which question, and where one engagement can cover both.
| Dimension | Segmentation testing (PCI DSS 11.4.5) | Full internal network penetration test (PCI DSS 11.4.1) |
|---|---|---|
| Primary goal | Prove out-of-scope networks cannot reach the cardholder data environment (CDE) | Find and validate exploitable weaknesses reachable from inside the network |
| Trigger | Requirement 11.4.5 at least every 12 months and after changes to segmentation controls | Internal tests at least every 12 months and after significant changes, per requirement 11.4.1 and related requirements |
| Frequency for service providers | At least every six months under requirement 11.4.6 | Confirm the applicable cadence with your QSA, as the internal test cadence follows the general requirement |
| Scope boundary | Defined by the segmentation controls and the systems on each side of them | Defined by the internal network segments, including the CDE and its trusted and untrusted neighbors |
| Method | Targeted attempts to cross the boundary from out-of-scope segments into the CDE, with results recorded per path | Broad reconnaissance, vulnerability validation and exploitation across hosts, services and accounts |
| What success looks like | Every tested path into the CDE is blocked, or any open path is documented as a finding | Exploitable weaknesses are validated, their impact is shown and remediation is prioritized |
| Testing viewpoint | Inside the network, starting from segments that should be isolated from the CDE | Inside the network, covering the CDE interior and access from trusted and untrusted internal networks |
| Team skills | Testers who understand network controls, firewalls, routing and how to prove a negative | Testers with broad exploitation, lateral movement and privilege escalation skills |
| Report contents | Must show the segmentation test results as a dedicated section in the PCI SSC report outline | Methodology, testing narrative, findings with references such as CVE and CWE, tools and clean-up, plus segmentation results |
| Typical deliverable | A segmentation section that states tested boundaries, methods and outcomes for assessor review | A full report with findings, evidence and remediation guidance, which can include the segmentation section |
What a segmentation test must prove that a network test may not
A segmentation test starts from the outside of the cardholder data environment (CDE) and tries to get in. The question it answers is narrow: can a system that is supposed to be out of scope reach the CDE, and if it can, through which path? A network penetration test starts from a defined set of hosts and follows any route that yields a weakness, so it may never check whether a given boundary holds. Under PCI DSS requirement 11.4.1, the methodology must include testing from inside the network, testing into the CDE from both trusted and untrusted internal networks, and segmentation validation. Those are separate deliverables, and a report that only shows exploited hosts does not prove isolation.
The first decision is the boundary itself. Before any test, confirm with your QSA exactly which networks, VLANs, firewalls, jump hosts, directory services and management planes are treated as out of scope, and which are connected to the CDE in ways that count as in scope. Ask the QSA to state in writing which segmentation controls the test must attempt to bypass, such as firewall rule sets, routing, DNS resolution across zones and shared administrative accounts. A tester cannot prove isolation against a boundary nobody has defined, and a boundary that differs between the QSA's view and the tester's scope is the most common reason a segmentation report is rejected.
The output must reflect that difference. A segmentation section should list each out-of-scope network tested, the source tested from, the CDE targets attempted, the method used and the result, with any reachable path documented as a finding. A general network report can be accurate and still omit these entries, since it records what was compromised rather than what was blocked. Plan for both in one engagement, but set the segmentation scope and sign-off criteria before the network test starts so that the evidence for requirement 11.4.5 is not assembled from leftover notes afterward.
What each approach finds and what it misses
Segmentation testing and a full internal network penetration test answer different questions about the cardholder data environment. The cards below show what each one tends to surface, where each one stops, and why the two are usually combined rather than chosen between.
Segmentation test findings
A segmentation test starts from out-of-scope networks and tries to reach the cardholder data environment. Typical findings include unexpected routes left by old change tickets, firewall rules that allow more than the documented design, flat VLANs where a compromised workstation can see payment hosts, and jump hosts or management servers that bridge both sides. Each finding should name the source segment, the destination in the CDE, the port and protocol, and the rule or route responsible. Ask the tester to show the traffic that succeeded and the traffic that was blocked, so you can confirm the control works as designed.
Network test findings
A full internal network penetration test looks at what an attacker inside the network can exploit. Typical findings include unpatched services on internal hosts, default or weak credentials on administrative interfaces, and lateral movement chains that combine several low-severity issues into access to sensitive systems. The value lies in the chain, not in any single finding. Ask for the attack path narrative, the privileges gained at each step, and whether the tester validated each issue manually. NIST SP 800-115 treats this kind of validation as the purpose of penetration testing, separate from passive review or scanning.
What segmentation testing misses
Segmentation testing answers one question: can traffic cross the boundary? It does not test application logic inside the CDE, such as broken authorization, insecure direct object references or flawed payment workflows. It also cannot find systems that nobody placed in scope. An unknown server on an out-of-scope network that holds cardholder data is outside its view. Before the engagement, ask the tester to confirm the list of in-scope and out-of-scope networks, and ask the client to confirm the asset inventory used to build that list.
What a network test misses
A network penetration test is a time-limited sample of attack paths, not a guarantee that the CDE boundary holds. Testers work within an agreed window and a rules of engagement document, so a route that opens after the test or a path the team did not try can stay hidden. Testing from one inside vantage point may also miss paths that only appear from a different segment. Ask the provider to state the coverage limits in the report, and schedule segmentation validation again after significant changes, as PCI DSS requires.
Automated tools alone do not suffice
Vulnerability scanners and automated segmentation checks are useful for frequent coverage, but the PCI SSC guidance says that simply running an automated tool does not satisfy the penetration testing requirement. A scanner can report that a port is open. It cannot decide whether that port leads to the CDE or whether a chain of access is exploitable. Confirm that the engagement includes manual exploitation and validation by a tester, and that the report explains what was attempted, not just what a tool flagged.
What each report must show and what you receive
This table compares what the PCI SSC suggested outline asks a penetration test report to contain against what a full internal network test typically adds. Read the left column as the minimum a segmentation report must carry for PCI DSS evidence, then check the right columns for what the wider engagement can add. Confirm the exact format and evidence standard with your provider and your assessor before testing starts.
| Report element | Segmentation test report | Full internal network test report |
|---|---|---|
| Executive summary | States whether segmentation controls isolated the cardholder data environment from out-of-scope networks, in plain language for management | Summarizes overall risk posture, major attack paths and business impact across the internal network |
| Statement of scope | Lists each segmentation boundary tested, the CDE and the out-of-scope networks on each side, and any excluded systems | Lists in-scope address ranges, hosts and domains, and any exclusions agreed in the rules of engagement |
| Methodology and limitations | Describes the approach used to attempt access across each boundary and states what the test could not reach | Describes the attack methodology, phases, access levels used and testing limits such as time windows or unavailable hosts |
| Testing narrative | Walks through attempted routes from out-of-scope segments into the CDE, including what was blocked and what succeeded | Covers the full sequence of exploitation, lateral movement and privilege escalation, often as a chronological account |
| Segmentation test results | Required core section: pass or fail per boundary with evidence showing the controls that enforced isolation | Usually included as one section among many, with less detail per boundary unless segmentation was specified |
| Findings with CVE and CWE references | Lists only findings that weaken segmentation, with CVE and CWE references where they apply | Lists all validated vulnerabilities with severity, CVE and CWE references, affected hosts and reproduction steps |
| Attack paths and remediation priorities | Often limited to the route that breaks isolation and the change needed to close it | Typically shows chained attack paths and ranks remediation by exploitability and business impact |
| Tools used and environment clean-up | Names the tools and accounts used and confirms that test artifacts, rules and access were removed | Names tools and accounts used and confirms clean-up, with the same expectation for removal of test artifacts |
| Ask your provider and assessor | Confirm the required report format, the evidence each boundary needs and whether a separate segmentation report is accepted | Confirm whether one report can serve both purposes and how findings will be tracked for retesting |
How to combine segmentation and internal network testing in one engagement
Run the work in a fixed order: define the cardholder data environment (CDE) and its boundary first, then validate segmentation from each out-of-scope zone, then run the internal network test against the CDE and the trusted and untrusted internal networks that can reach it. Start by writing down every connection that crosses the boundary: firewall rule sets, VLAN and subnet assignments, jump hosts, shared identity services, management networks and any cloud or hosted component that can route into the CDE. Each of these becomes a test case. A segmentation test that starts without this list tends to prove only the controls the team already knows about.
Next, test segmentation from the inside of each out-of-scope zone, not only from the outside. PCI DSS requirement 11.4.5 asks for testing that confirms segmentation isolates the CDE from all out-of-scope systems, and the testers should attempt the paths an attacker would use: routed access, DNS and name resolution, shared credentials, and administrative protocols. Requirement 11.4.1 separately requires internal and external penetration testing, so the same engagement should also cover the internal viewpoint into the CDE and the external perimeter. Confirm with your assessor whether the segmentation results and the internal network results can sit in one report or need separate sections, because the PCI SSC suggested report outline includes a segmentation test results section.
Record segmentation findings in the same report as the network findings, with each result tied to the rule, zone pair and date it was tested. Retest after any firewall, routing, VLAN or identity change that touches the boundary, because requirement 11.4.5 requires testing after changes. Keep a change log that links each boundary change to the retest that followed it. Ask the provider to state how the engagement counts as a separate segmentation test under the annual cycle, and confirm the exact frequency with your qualified security assessor, since the every-six-months rule in requirement 11.4.6 applies only to service providers.
What drives cost and effort for each engagement
Cost in a segmentation test or network penetration test is mostly the tester's time spent on validation, exploitation and reporting, plus any retesting. The cards below show which scope factors move that time up or down, so you can compare written quotes on the same basis. No prices or durations are given here, and a quote should follow from a written scope.
Segments and out-of-scope zones
Each segment boundary between the cardholder data environment (CDE) and an out-of-scope network is a path the tester must try to cross, and each out-of-scope zone must be checked from the CDE side and from the outside. A flat network with many zones multiplies that work. Ask the provider to list every segment and out-of-scope zone by name in the quote, with the tests planned against each one.
Size and change rate of the CDE
A larger CDE with more hosts, services and integrations takes longer to map and validate, and a CDE that changes often means more of the scope is new each cycle. Ask how the provider will confirm the asset inventory at the start of testing and whether they will reconcile it against your change records.
Number of trust boundaries
Trust boundaries such as jump hosts, management networks, vendor connections and shared services are where segmentation most often fails. Each one adds rule sets to review and paths to attempt. Ask whether the quote covers every boundary you list, including third-party connections that reach into the CDE, and whether any are excluded.
Retest triggers and terms
PCI DSS requires segmentation tests after significant changes, so a change to firewall rules, network design or CDE membership can start a new test. The retest terms decide whether that work is included or billed separately. Ask which change types trigger a retest, how many retests are included, and how long a retest window stays open after the first report.
Depth of manual exploitation
Segmentation proof depends on a tester attempting real routes across the boundary, not only running a scanner. Manual exploitation of pivot paths, credential reuse and misrouted traffic takes the most tester time. Ask what share of the hours goes to manual validation of each boundary and what tools are used for discovery.
Report and remediation support
The report must show segmentation test results, scope, methodology, limitations and findings with references, so the reporting hours depend on how many findings there are and how much evidence each one needs. Ask whether the quote includes a walkthrough with your team, support answering assessor questions, and a retest of fixed findings.
Questions buyers ask before hiring outside help
Can we run segmentation testing in-house instead of hiring an outside firm?
Yes, a qualified internal team can run segmentation testing, but the tester must be independent of the controls under test and the work must follow a documented methodology. PCI DSS requirement 11.4.1 asks for an industry-accepted approach, and the PCI SSC Penetration Testing Guidance v1.1 (September 2017) stresses that the tester needs skills and an objective view of the segmentation design. Ask whether the internal team can show independence from the people who built the firewall rules. If it cannot, an external tester is usually the simpler route to evidence an assessor will accept. Check the approach with your Qualified Security Assessor before you decide.
What do we need to give the tester before segmentation work starts?
Expect to supply current network diagrams, an asset inventory that marks which systems sit in the cardholder data environment (CDE), the list of out-of-scope networks, firewall and access control rule sets, and the change calendar. Test accounts for each relevant network zone are also needed so the tester can attempt connections from both sides of a boundary. Clear rules of engagement, a named contact for each system owner and a window for disruptive testing shorten the setup. Missing or out-of-date diagrams are the most common reason a segmentation test finds gaps nobody had documented, so verify them against the live environment first.
How long does segmentation testing take, and what makes it longer?
Duration depends on how many segmentation boundaries exist, how many out-of-scope networks must be proven unreachable, and how well documented the environment is. Each boundary needs testing from the untrusted side and the trusted side, so more zones and more cloud or hybrid links add work. Remediation cycles extend the calendar, because a retest is needed after each fix. Ask the provider for a schedule that lists setup, testing, reporting and retest as separate phases, and confirm which dates depend on your change approvals. The governing timing rule is in PCI DSS requirements 11.4.5 and 11.4.6, not in any vendor estimate.
Does a segmentation test satisfy the full internal network penetration test?
No. A segmentation test answers one question: whether networks out of scope can reach the cardholder data environment. PCI DSS requirement 11.4.1 expects a broader internal test covering the CDE perimeter, critical systems, and both application-layer and network-layer testing from inside the network. The two can be combined in one engagement, and the PCI SSC suggested report outline includes a segmentation test results section alongside the rest of the report. Ask the provider to show which findings belong to segmentation and which belong to the wider internal test, so your assessor can trace each requirement to evidence.
How often must segmentation testing and penetration testing be repeated?
For most merchants and service providers, requirement 11.4.5 requires segmentation penetration tests at least every 12 months and after changes to segmentation controls. Service providers fall under requirement 11.4.6, which raises the segmentation test frequency to every six months. Requirements 11.4.2 and 11.4.3 cover internal and external penetration tests at least every 12 months and after significant changes. A combined engagement can be scheduled to meet the earlier deadline, but the change-triggered tests still apply between cycles. Confirm your service provider status with your acquirer or assessor, because that status determines which frequency applies to you.
What happens after a segmentation test fails?
A failed segmentation test means at least one out-of-scope network reached the CDE, or a control expected to isolate it did not. Expect the report to list the finding, the path used and the affected systems, with references such as CVE and CWE where they apply. Your team then fixes the rule, firewall or design, and the segmentation test must be repeated after the change, as requirement 11.4.5 requires testing after changes. Document the fix, the retest result and any compensating measures in the evidence pack. Ask the provider whether the retest is included in the quote, since a retest is a separate piece of work in most scopes.
Can an ASV scan replace the segmentation or penetration test?
No. A quarterly external scan by a PCI SSC Approved Scanning Vendor and the internal and external vulnerability scans required under requirements 11.3.1 and 11.3.2 check for known vulnerabilities. They do not establish that segmentation holds under an attacker's manual exploitation. The PCI SSC guidance says simply running an automated tool does not meet the penetration testing requirement. Scans are useful between tests, and they can show that a rule change introduced a new exposure. The segmentation and penetration test evidence still has to come from a manual, documented test.
How should we scope a quote for a combined segmentation and network test?
Ask for a written scope that lists each in-scope network segment, each CDE boundary to be tested, the number of test accounts and network zones, the internal and external viewpoints, and whether application-layer testing is included. The quote should also state the deliverables, including the report sections, the retest terms and who attends the closing meeting. Ask which cost components are one-time, such as the setup and the first test, and which recur, such as the annual or six-monthly cycle and any change-triggered retests. Compare quotes on the same boundary list and deliverables, because a lower price often reflects a narrower scope. DeployOpen does not publish a price list, so a quote follows from the written scope agreed before work starts.
How DeployOpen scopes and delivers segmentation and internal network testing
DeployOpen runs segmentation testing and internal network penetration testing as separately defined work inside one written scope, so the segmentation evidence and the broader internal findings can be read side by side. The engagement is planned, tested, documented and handed over inside your own infrastructure, with ongoing support available as a retainer.
How we scope
- Each engagement starts with a written scope that lists the CDE boundary, out-of-scope networks and the segmentation controls to be tested.
- We agree which internal viewpoints apply, including testing from trusted and untrusted internal networks into the CDE, before any work begins.
- Rules of engagement, test windows, production or staging decisions and named contacts are recorded in writing before testing starts.
How we build
- We set up test access and accounts inside your environment, with the access level and credential handling agreed in the scope document.
- Segmentation tests try to reach CDE systems from each out-of-scope network, and we record every path attempted and its result.
- Manual exploitation of internal hosts and services is combined with automated discovery, so tool output is validated by a tester before it is reported.
How we hand over
- Reports follow the structure PCI SSC suggests, with a separate segmentation test results section, scope statement and stated limitations.
- Findings reference affected systems, reproduction steps and CVE or CWE identifiers where they apply, so your team can retest them directly.
- We document the methodology used, the tools run and the environment clean-up performed, so auditors can trace how each result was produced.
How we support
- Retesting of remediated findings can be included in the written scope or added later as a separate fixed-scope piece of work.
- Ongoing support, upgrades and continuous testing are available as retainers, which can cover the recurring segmentation and internal test cycle.
- Confirm with us during scoping which retesting and retainer terms apply, since the timing and cost depend on your environment and agreed scope.
