When you think of PCI DSS, you probably don’t automatically think of drawing diagrams. But diagrams are vital to understanding your scope, understanding your environment, and are two of the PCI requirements that may apply to you.
PCI DSS requires three types of diagrams:
- High-level network diagrams.
- Detailed network diagrams.
- Cardholder data flow diagrams.
In this article we’ll talk about what what each of those diagrams are and the kinds of details that they need. While this page focuses on the details from the Report on Compliance (RoC) template, the same approach should be taken even if you are using a Self-Assessment Questionnaire (SAQ).
High-Level network Diagrams
The Report on Compliance (RoC) template details the exact types of information that are expected in a high-level network diagram on page 11. A high-level network diagram is expected to show:
- The overall architecture of the environment being assessed
- A summary of all:
- Key systems, and
- Boundaries between the above
- All connections into and out of the network, including the CDE to other networks, VLANs, or zones
- Includes all critical components within the CDE, such as:
- POS / POI devices
- Other components (as applicable)
- Includes all other necessary payment components.
The high-level network diagram should be the 10,000 foot view of your environment showing all the possible connections into and out of the environment to help you and your assessor to understand how things fit together. This means your high-level network diagram should include things like where your test and development environments are to understand any connectivity to the CDE / production environments.
Detailed Network Diagram
The detailed network diagram takes the high-level view and zooms in to the CDE and the supporting environments with a focus on the environments that are in-scope for PCI. The detailed network diagram needs to show:
- All boundaries of the CDE
- Network segmentation points the tare used to reduce the scope of the assessment
- Boundaries between trusted and untrusted networks
- Wireless and wired networks
- Any other connection points that are applicable to the environment.
While this may seem similar to the high-level network diagram, the diagram is expected to have much more detail to it so that you and your QSA can understand how each communication point functions and how it is secured. This may include detail such as:
- The type of device(s)
- The device interfaces
- Network technologies
- Security controls
With the amount of detail that is required here, you may find that some of this information needs to be in supporting documents. However, if you do use a supporting document, make sure that it is kept up to date and referenced in your network diagram.
It may be possible that your detailed and high level network diagrams are the same if your environment is small. The important thing is to make sure that you have all the required detail in your network diagrams.
Below is an example of a network diagram that may get you started when trying to diagram your own network.
As you can see, it includes information about the servers, the ports and how they connect, the network devices providing segmentation and the wireless networks.
Cardholder Data Flow Diagrams
Cardholder data flow diagrams need to exist for every process where you store, process, or transmit cardholder data so that it is possible to understand the lifecycle of a payment. This means that your cardholder data flow should include everything from the time a customer is able to provide you with a payment, through any processes where you use that card number (for example tokenisation), and when it leaves your environment for further processing, settlement, or fraud activities.
By understanding your cardholder data flows, you can better understand and explain your scope. To understand and explain your cardholder data flows, you need to be able to show not only where cardholder data flows (e.g. where is it stored, processed, or transmitted internally or externally)but also what parts of the cardholder data are involved in the flow (e.g. PAN, SAD, Name, Expiry, etc.) and how it is protected (e.g. TLS, VPN, truncation, application layer encryption, etc.).
This diagram shows an example of one way you can illustrate your cardholder data flows.
It contains information about how data is protected at rest, where it is stored, and what is stored. It also shows how cardholder data is sent from the time a customer provides a credit card number through the transaction process including transmitting the cardholder data out to the payment gateway.
Remember to Include Supporting Systems
PCI DSS is not just the systems that store, process, or transmit cards. It is also the systems that support the PCI DSS requirements. This means you should ensure that your network diagrams also include systems used for patching, antivirus, log servers, file integrity monitoring, admin workstations, and other systems that support PCI. Even though these are not part of the cardholder data environment (or CDE), they are still part of your in-scope environment and your assessor will want to see these on your diagram so they know what systems they will need to review.
Confide can help you with not only understanding your scope, but making sure that your documentation clearly reflects your scope. Contact us to find out how Confide can help.