Before you can protect your organization from a payment card data breach, you must first know the different locations, methods, and systems by which you are accepting payments. What kind of equipment is used, who are your third-party service providers, what applications or solutions are being used, is any information being stored, and how, exactly, do all of these pieces fit together?
Requirement 1.1.3 of the PCI DSS calls for a current diagram showing all cardholder data flows across systems and networks, and dictates that organizations have a process in-place to keep the diagram current.
A data flow diagram should identify where cardholder data is stored, processed, or transmitted within the network, and between individual systems and devices. If done right, these diagrams help organizations see the full scope of their cardholder data environment (CDE) and can help to identify potential areas of improvement through consolidation or segmentation.
Requirement 1.1.3 only appears in SAQ D and SAQ A-EP, where it falls under the requirement for firewall and router configuration standards, and it is there to ensure that any network segmentation is effectively isolating the CDE. However, it is a good information security best practice to have all merchants go through the process of outlining their payment card environment with a simple diagram as a way to educate them and ensure they understand their compliance footprint. These merchant-level diagrams do not need to be as detailed as the network diagrams, but should include key devices, networks, third-party partners, etc. In order to streamline the diagrams and eliminate unnecessary confusion, it may be easier to create a separate diagram for each payment process, i.e. card present, e- commerce, telephone payments, etc.
Your merchants should be able to answer the following questions with their diagrams:
- How, and in what ways, does the department receive cardholder information?
- Is it entered into a POS system? If yes, document the vendor, system name and version, and details about the device used.
- Is it entered into an e-commerce website? If yes, document the vendor, who hosts the site, and system / application name and version.
- Is it received via mail orders and/or telephone orders? If yes, document what that flow is, how the orders are received, and any other departments involved (i.e. the Mailroom).
- Is the data received or written down on paper? If so, where is that paper stored and how is it destroyed?
- Do staff enter the data into a device, a standalone terminal, or into their workstations? If yes, document where they originally receive the data, what equipment is being used, and where it goes (i.e. to another department or to the shredder).
- If they are using an e-commerce website, is the site hosted at their location or through a third- party?
- Is the cardholder information shared or sent outside the department? If yes, document the other areas that also receive the data.
- Is it transmitted to the processor through analog lines, or through an IP-based or cellular connection? Indicate the type of connection between systems to clearly show the method of communication.
- Is information stored on any internal servers or systems? Even if only stored for a short time, all involved systems should be included in the diagram.
Consider making the data flow diagram part of your annual merchant review. By including this document review as part of a robust checklist that includes their inventory list, departmental procedures, device inspection logs, staff training, etc., you can be confident that the diagram is being kept relatively current. A current data flow diagram allows the PCI Team to understand the process for accepting payment cards at each merchant location, and determine if any changes need to be made. For those departments requesting the ability to accept payment cards, requiring a data flow diagram will ensure that you know where and how they plan to accept cardholder data, confirm that they are following your organization’s policies, and minimize your exposure to potential compliance gaps.
Please reach out to us if you would like additional examples for use with your merchants.
Some additional guidance from the Security Advisor Team below:
[Campbell]: One important thing to keep in mind, as noted above, is that the data flow diagram is not limited to technology. Paper matters. People and processes matter. Remember that your cardholder data environment is the combination of people, processes, and technologies that interact with cardholder data or could affect its security. Therefore, a well-crafted data flow diagram will include all “touchpoints” for all formats of cardholder data. That desk tray that forms sit in for 15 minutes? It should be on the diagram. The person who opens mail and forwards forms with cardholder data to other staff members for processing? She should be on the diagram as well.
Finally, when we consider that a data flow diagram represents all of the ways cardholder data enters and moves through your environment, from the moment you take responsibility for it until it is deleted/destroyed, resist the temptation to “dump” this task on your IT or networking staff. While they might contribute, only the merchant is fully familiar with all of the steps and touchpoints that should be depicted on the diagram.
