PCI DSS Network Diagrams – 5 Requirements That Determine Your Audit Outcome

Updated: 2nd April 2026

What is a PCI DSS network diagram? A PCI DSS network diagram is a documented, up-to-date visual representation of your IT environment that shows all networks, systems, and data flows within and around the Cardholder Data Environment (CDE). PCI DSS version 4.0.1 mandates two specific diagrams under requirements 1.2.3 (network diagram) and 1.2.4 (data flow diagram). Without accurate diagrams, your organisation cannot confirm the scope of certification – and your QSA cannot complete the assessment.

PCI DSS network and data flow diagrams – in brief:

1. PCI DSS v4.0.1 requirements 1.2.3 and 1.2.4 explicitly mandate both a network diagram and a data flow diagram
2. Diagrams must be reviewed at least once a year and updated after every significant infrastructure change
3. A correct diagram reduces QSA queries during report writing and accelerates assessment delivery
4. The diagram must clearly distinguish CDE from non-CDE environments using visual markers (colours, frames, labels)
5. Based on 200+ completed PCI assessments, the most common diagram failure is missing data flow for non-card data
6. One diagram is not always sufficient — complex environments often require separate network and data flow diagrams
7. Your diagram can simultaneously serve ISO 27001, EBA, and KNF compliance programmes

Why does PCI DSS require a network diagram?

PCI DSS v4.0.1 is explicit: your organisation must maintain an accurate network diagram (requirement 1.2.3) and a separate data flow diagram (requirement 1.2.4). These are not optional documentation artefacts — they are audit prerequisites.

The purpose is twofold. First, the diagram forces the organisation itself to understand which networks form part of its architecture and how cardholder data moves through them. Second, it gives the QSA an independent reference point to verify the scope of assessment, confirm that penetration tests and vulnerability scans covered the right systems, and identify gaps in card data processing (for example, data appearing in cleartext where it should be encrypted).

From our experience across 200+ PCI assessments, organisations that arrive with a clear, current diagram save an average of several working days in QSA queries and report revision cycles. A complete diagram means your assessor can independently verify ASV scan coverage, internal network segmentation, and IP address ranges — without needing to ask you.

In practice this means: a well-prepared diagram is not just a compliance checkbox. It is the foundation of a faster, lower-cost audit.

What must a PCI DSS data flow diagram include?

The data flow diagram must show how cardholder data — and other sensitive data — enters, moves through, and exits your environment. According to PCI DSS v4.0.1 requirement 1.2.4, this includes the origin and destination of all data flows, the transmission method (explicit or encrypted), and the systems or individuals that handle the data at each stage.

What the diagram must show:

• Entry points — where card data first arrives (POS terminals, payment gateways, e-commerce front ends)
• Transmission method — whether data is transmitted in cleartext or encrypted (TLS, P2PE)
• Storage locations — databases, log systems, backup environments that touch card data
• Exit points — processors, acquirers, third-party service providers
• Non-card data flows — PCI DSS v4.0.1 broadens the requirement to include all sensitive data, not only PANs

A common mistake: organisations document only the card data path and omit related data flows (authentication data, transaction logs). This creates scope gaps that QSAs must flag.

How do you build a clear and readable PCI DSS diagram?

Clarity is not a stylistic preference — it is a functional requirement. A diagram that a reader cannot interpret within 60 seconds is not serving its purpose. Based on our project work, here are the five elements that consistently produce readable, audit-ready diagrams:

1. Icons over labels — Use standard symbols for firewalls, routers, databases, and servers. An icon communicates faster than a text label alone.
2. Colour coding — Use distinct colours or frames to separate CDE from non-CDE zones, and to distinguish encrypted from unencrypted data flows.
3. Brief, human-readable labels — DBSVRLAN321 is meaningless to a QSA. Use Cardholder DB — DMZ instead, and attach a key or legend.
4. Appropriate level of detail — Avoid mapping every individual server if a group or role suffices. Overloaded diagrams become unreadable. A concise diagram is not a sparse diagram — it is a well-structured one.
5. Version and date marker — Every diagram update must be noted directly on the diagram (version number, review date, author). This allows you and your QSA to confirm you are reviewing the current, final version.

Your diagram should also be usable beyond PCI: a well-structured network and data flow diagram is directly reusable for ISO 27001 (Annex A.8), EBA ICT risk guidelines, and KNF requirements — reducing documentation overhead across compliance programmes.

How many diagrams does PCI DSS actually require?

PCI DSS v4.0.1 does not specify a fixed number of diagrams. Requirements 1.2.3 and 1.2.4 define what must be documented, not how many files must exist.

In practice:

• Simple environments (single DC, limited systems, one payment channel) — one combined network and data flow diagram is typically sufficient
• Complex environments (hybrid cloud, multiple payment channels, segmented networks across locations) — separate diagrams are strongly recommended: a high-level network diagram, a detailed data flow diagram, and additional segment-level diagrams as needed

The guiding principle is: your diagram set must allow any informed reader — including a new QSA, an auditor, or a regulator — to independently understand the scope of the CDE and the full journey of cardholder data. If a single diagram cannot achieve that without becoming cluttered, use multiple diagrams.

What does a correct PCI DSS network diagram look like?

Below are two reference examples from Patronusec, based on a physical DC environment without cloud components. Evaluate each against the five clarity criteria above.

Figure 1 — Network diagram for PCI DSS assessment

Figure 2 — Data flow diagram for PCI DSS assessment

Note: cloud environments (AWS, Azure, GCP) introduce additional diagramming considerations — shared responsibility boundaries, virtual network segments, and API-level data flows must all be reflected. If your environment includes cloud components, contact us for guidance specific to your architecture.

FAQ

What is the difference between a PCI DSS network diagram and a data flow diagram?

A network diagram (requirement 1.2.3) shows the physical and logical topology of your IT environment — networks, segments, firewalls, routers, and their interconnections. A data flow diagram (requirement 1.2.4) shows how cardholder data and other sensitive data moves through that environment — including entry points, transmission methods, storage locations, and exit points. Both are mandatory under PCI DSS v4.0.1 and serve different audit purposes.

How often must PCI DSS diagrams be updated?

PCI DSS v4.0.1 requires diagrams to be reviewed at least once per year and updated after any significant change to the environment. Each update should be recorded directly on the diagram — version number, date, and the nature of the change — so that both the organisation and the QSA can confirm the current version is being reviewed.

Can one diagram cover both network topology and data flow?

Yes, for simpler environments a combined diagram is acceptable. However, for complex environments with multiple payment channels, hybrid infrastructure, or extensive network segmentation, separate diagrams are strongly recommended to maintain readability. The standard does not prescribe a specific number of diagrams — what matters is that the documentation is accurate, current, and unambiguous.

What happens if our PCI DSS diagram is incomplete or outdated?

An incomplete or outdated diagram is a direct finding in the PCI DSS assessment. It signals to the QSA that the organisation may not have full visibility of its CDE, which raises questions about scope accuracy, segmentation controls, and the coverage of penetration tests and vulnerability scans. This can extend the assessment timeline and require remediation before the ROC or SAQ can be finalised.

Can the same diagram be used for ISO 27001 or EBA compliance?

Yes. A well-structured PCI DSS network and data flow diagram contains information directly relevant to ISO 27001 (Annex A.8 — asset management and network security), EBA ICT risk guidelines, and KNF requirements. Reusing a single, well-maintained diagram set across compliance programmes reduces documentation overhead and ensures consistency between assessments.

Does a cloud environment change diagram requirements?

Yes, significantly. Cloud environments introduce shared responsibility boundaries, virtual network segments, API-based data flows, and dynamic infrastructure that must all be reflected in the diagram. Standard DC-based diagrams are insufficient for AWS, Azure, or GCP environments. PCI DSS v4.0.1 guidance for cloud environments requires clear delineation of what is managed by the cloud provider versus the organisation.

PCI DSS diagrams — free consultation

Patronusec has completed 200+ PCI DSS assessments and consulting projects across fintech, retail, and financial services. If your diagrams are outdated, incomplete, or have never been reviewed by a QSA, we can assess them and recommend specific changes before your next audit.

Book a free consultation →