Diagrams are a very extensive topic, and as many QSAs exist, there are as many approaches and options. What we present below is our vision and opinion, based on over 200 completed assessments and several hundred consulting projects. It’s also important to note that there’s no perfect diagram that will “fit” every QSA. 

It’s important that it reflects the sense and assumptions of the standard and is relatively easy to maintain. 

It’s a requirement of the PCI DSS standard, which clearly states that an organization must have an accurate network diagram and data flow diagram. This requirement is described in points 1.2.3 and 1.2.4 in PCI DSS version 4.0. 

Why do we need such a diagram at all? Put simply: so that the organization is aware of which networks are part of its network architecture and through which of these networks, in what way (explicit or encrypted), and where data (not just card data) flows to and from. 

Additionally, it’s to visualize the scope of certification and show that we have documented the entire flow of card data through the organization and identified the systems and individuals supporting the environment. This really helps in establishing and confirming the scope of certification – from the diagram, it’s very easy to determine whether the organization stores card data, where it does so, and whether there are any gaps in the card processing process (e.g., suddenly data appearing in clear text). 

Sometimes companies underestimate the importance of creating and having diagrams – this is a mistake right from the start of certification because a clear diagram reflecting the topology of IT resources and associated data is an important part of the PCI compliance assessment procedure. It not only confirms the scope but also clearly delineates what is within the scope and what is not. 

Such a diagram can be used not only for PCI certification but also for other programs such as ISO 27001, EBA (European Banking Authority) requirements and standards, and/or KNF (Komisja Nadzoru Finansowego). 

A little QSA hint – a complete diagram helps avoid questions after completing the assessment and during report writing – if it contains all the information, we don’t need to ask the client about the number of IP addresses, VLANs in the scope, etc. The diagram allows us to independently verify whether penetration tests, vulnerability scans, ASV scans, etc., have been performed correctly. This means fewer questions for you and a faster report delivery. 

Although ideal diagram does not exists here are some items and takeaways for you when you are preparing your next diagram.

1. Number of diagrams – None of the known standards specify the number of diagrams to be possessed. From experience, we can say that there is no single good answer. Sometimes one diagram is sufficient, sometimes it’s better to make more than one diagram (especially for complex IT systems).
2. Up to date- Quantity is not important – quality and currency are important. The diagram must be up-to-date – reviewed at least once a year and ideally after any major change – to reflect what is actually in the IT environment. Each update must be noted (ideally on the diagram) to be aware that you are reviewing the current, final version.
3. Clarity – the diagram must be clear. A too detailed diagram is not a good example – sometimes there’s no point in drawing all servers – a group or role is sufficient. The diagram should be easy to read and understand. Sometimes, too much detail and information saturation make it unreadable and incomprehensible. However, the purpose is for the person reading the diagram to be able to quickly and easily identify network elements, segments, data flows, distinguish between CDE and non-CDE environments, or areas covered or not covered by the scope of assessment. A concise diagram does not mean a “cluttered” diagram with unnecessary detailed information. The ideal diagram should be accessible and unambiguous to the recipient in its simplicity.
4. Legibility – Use symbols, pictures, colors, arrows, etc., to illustrate your company’s environment and the way cardholder data flows through it. It is very helpful to 
   1. use appropriate icons for types or groups of systems (e.g., a firewall symbol, router, server, database – just an icon is enough – no need to add a label), 
   2. use colors and/or frames (e.g., to distinguish network segment or data flow in an explicit or encrypted manner or to indicate whether it’s card data or other data). 
   3. Using brief descriptions of these elements (e.g., firewall, DB server, or DMZ network) is much more effective, although, of course, providing specific system elements and linking them to specific names, models, types, network names, is equally important. For the creator of the diagram, the name DBSVRLAN321 may be obvious, but not necessarily for the reader. Therefore, it’s worth including a key that is part of the diagram or a separate document linked to the diagram so that the recipient can easily decipher all names, colors, symbols.
5. Completeness – Depending on the complexity of the network and processes in your organization, you may combine network and data flow diagrams into one or there may be a need for multiple diagrams (separate network diagram, separate data flow diagram, additional lower-level network diagrams – more detailed). 

Below are examples of  diagrams for an environment hosted in a DC (physical environment) without cloud solutions. Pay attention to whether the diagram contains the 5 elements mentioned above and whether it’s clear and understandable to you. 

Should you have any questions regarding network diagrams or other elements of PCI please do not hesitate to Contact us. With over 15 years of experience working with the PCI standards, we are confident we can find a solution for your specific issue.