Category: Network Security

Network Diagram

Also known as: Network Topology Diagram, Network Map

Simply put

A network diagram is a visual map that shows how computers, servers, and network devices such as routers and switches connect to one another within a network. It helps teams document and understand the layout of their systems by representing devices as shapes or nodes and the connections between them as links.

Formal definition

A network diagram is a visualization that documents the components of a network and the relationships between them, typically representing entities such as servers, computers, routers, and switches as nodes and the connections between them as links. Standard diagramming templates provide shapes for common network devices to illustrate how they connect within a network, and the technique is also applied to cloud and architecture documentation. Note that the specific content, level of detail, and validation expectations for a network diagram in a compliance context are governed by the applicable standard's current requirements, which should be confirmed against the published standard rather than assumed from this general definition.

Why it matters

A network diagram is foundational to defining and defending the scope of a cardholder data environment. Without an accurate visual map of how systems connect, teams cannot reliably identify which components store, process, or transmit cardholder data, nor which systems are connected to or could affect the security of that data. Scoping errors frequently originate in incomplete or outdated documentation, and a network diagram is often the first artifact an assessor examines to understand where account data flows and where controls such as segmentation are applied.

In a PCI DSS context, the diagram supports several related objectives: confirming the boundaries of the environment under assessment, validating that segmentation is implemented as claimed, and giving reviewers a way to trace connectivity between in-scope and out-of-scope systems. Because the specific content and level of detail expected for a network diagram are governed by the applicable standard's current requirements, teams should confirm what must be depicted against the published standard rather than assuming a fixed format. Requirement numbering and wording differ between PCI DSS versions, so the exact expectations should be verified against the current release.

A network diagram is a documentation and scoping aid, not a control in itself. It does not enforce segmentation, encrypt data, or prevent unauthorized access; it only describes the intended layout. Its value depends on accuracy and currency. A diagram that no longer reflects the deployed environment can create a false sense of assurance and may cause reviewers to overlook in-scope systems, so it should be maintained alongside the environment it represents.

Who it's relevant to

Compliance officers and QSAs

Those responsible for scoping and validating a PCI DSS assessment rely on the network diagram to understand the boundaries of the cardholder data environment and to check that segmentation is implemented as claimed. They should confirm the expected content and validation requirements against the current published standard, since these differ between versions.

Security engineers and network architects

Teams who design and maintain the environment use network diagrams to document how servers, computers, routers, switches, and cloud components connect. Keeping the diagram aligned with the deployed environment helps ensure that scoping and segmentation decisions rest on an accurate representation rather than an outdated one.

Merchant and processor risk teams

Teams accountable for demonstrating and reviewing environment layout use network diagrams as a starting point to trace connectivity between in-scope and out-of-scope systems. Because the diagram is a documentation aid and not an enforcement control, they should treat it as one input into scoping rather than as evidence that controls are functioning.

Inside Network Diagram

Cardholder Data Environment (CDE) Boundaries

The network diagram should depict the systems, components, and network segments that store, process, or transmit cardholder data, along with the boundaries that separate the CDE from out-of-scope networks. Accurate boundary depiction is central to defining PCI DSS scope.

Connections and Data Flows

All connections into and out of the CDE, including connections to other internal networks, wireless networks, and third parties. A network diagram is distinct from a data-flow diagram, though both are typically required; the network diagram shows connectivity while the data-flow diagram shows how account data moves.

Segmentation Controls

Firewalls, routers, and other controls used to isolate the CDE from out-of-scope systems. Segmentation is intended to reduce scope, but its effectiveness depends on configuration and validation rather than on being drawn in a diagram.

In-Scope System Components

Servers, network devices, security appliances, and endpoints that are connected to or could affect the security of the CDE, including systems that provide security services and connected support systems.

Wireless and Remote Access Paths

Any wireless networks and remote access entry points that connect to or could reach the CDE, which are relevant to scope and to identifying potential exposure of cardholder data.

Third-Party and Service Provider Connections

Points where external service providers, processors, or other entities connect to the environment, which affect scope and responsibility boundaries for the controls governing account data.

Common questions

Answers to the questions practitioners most commonly ask about Network Diagram.

Does a network diagram alone define my PCI DSS scope?

No. A network diagram is a supporting artifact that helps illustrate connectivity, but it does not by itself define scope. Scope is determined by where cardholder data is stored, processed, or transmitted, and by any systems connected to or that could impact the security of the cardholder data environment. The diagram should reflect that scope accurately, but reviewing the diagram is not a substitute for the scoping analysis itself, which should be confirmed against the current published PCI DSS.

Is a network diagram the same thing as a data-flow diagram?

No, they are distinct artifacts that PCI DSS treats separately. A network diagram depicts systems, network segments, and connections, while a data-flow diagram traces how cardholder data moves across those systems and networks, including where it enters, is stored, is processed, and leaves the environment. Both are typically expected, and one does not replace the other. Confirm the specific requirement wording against the current published standard, as numbering and phrasing differ between versions.

How often should a network diagram be updated?

A network diagram is intended to remain current, which generally means updating it whenever the environment changes in ways that affect connectivity or scope, and confirming its accuracy on a defined periodic basis. Rather than relying on a fixed interval, tie updates to your change-management process so that new systems, segments, or connections are reflected. Confirm the exact frequency expectations against the current published PCI DSS version.

What should a network diagram include to support a segmentation claim?

To support a segmentation claim, the diagram should clearly show the boundaries between the cardholder data environment and out-of-scope networks, including the controls that enforce that separation and the connection points between segments. The diagram helps document the intended segmentation, but it does not by itself validate that segmentation is effective; that is confirmed through testing. Whether segmentation reduces scope depends on implementation and validation, not on how the diagram is labeled.

Who should be responsible for maintaining the network diagram?

Responsibility is typically assigned to roles that have authoritative knowledge of the environment and its changes, such as network engineering or infrastructure teams, working with security and compliance stakeholders who confirm the diagram reflects the assessed scope. The key point is that ownership is defined and tied to change management so the diagram stays accurate. Confirm any documentation and roles-and-responsibilities expectations against the current published standard.

How does a network diagram support an assessment or audit?

During an assessment, a network diagram helps the assessor understand the environment, verify scope, and identify systems and connections that require testing. It is intended to be an accurate reference that can be corroborated against the actual environment and other evidence, such as data-flow diagrams and configuration reviews. An inaccurate or outdated diagram can undermine confidence in the assessment, so it should be reconciled with what is observed rather than accepted at face value.

Common misconceptions

A network diagram and a data-flow diagram are the same thing and one can substitute for the other.

They serve different purposes. A network diagram shows systems, segments, and connectivity, while a data-flow diagram shows how cardholder data moves through and across the environment. PCI DSS typically expects both; readers should confirm the specific documentation expectations against the current published standard, as requirement wording differs between versions.

Drawing a segmentation boundary on the diagram reduces PCI DSS scope.

A diagram documents intended segmentation but does not itself reduce scope. Scope reduction depends on segmentation controls being properly configured and validated. Depicting a boundary without effective, tested controls does not remove systems from scope.

Only systems that store cardholder data need to appear on the network diagram.

Systems that store, process, or transmit account data, as well as connected systems and those that could affect the security of the CDE, are relevant. Remember that sensitive authentication data must not be stored after authorization even when encrypted, so a complete diagram should reflect all account-data touchpoints, not just storage.

Best practices

Maintain the network diagram as a current, dated document and update it whenever the environment changes, so it accurately reflects the CDE boundaries and connections in place.

Depict all connections to and from the CDE, including internal networks, wireless networks, remote access paths, and third-party or service provider connections.

Keep the network diagram and the data-flow diagram as complementary documents rather than treating one as a substitute for the other, and reconcile them so systems and flows are consistent between the two.

Clearly identify segmentation controls on the diagram, but validate their effectiveness through testing rather than relying on the diagram alone to justify scope reduction.

Ensure the diagram distinguishes in-scope from out-of-scope segments and includes connected systems and security-affecting components, not only systems that store cardholder data.

Confirm documentation content and expectations against the current published PCI DSS version, since requirement numbering and wording differ between versions.