The Report on Compliance suggests that Cardholder data-flow diagrams may also be included as a supplement to the description of how cardholder data is transmitted and/or processed. Regardless they are great way to communicate and document the CDE and PCI DSS scope.
FAQ Article Number 1178 from February 2011
… An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes related to the storage, processing or transmission of cardholder data. Restricting cardholder data to as few locations as possible by elimination of unnecessary data, and consolidation of necessary data, may require reengineering of long-standing business practices.
Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment….
From the PCI DSS version 3.2.1
“Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment.”
1.1.3 Current diagram that shows all cardholder data flows across systems and networks
1.1.3 Examine data-flow diagram and interview personnel to verify the diagram:
-
-
-
- Shows all cardholder data flows across systems and networks.
- Is kept current and updated as needed upon changes to the environment.
-
-
Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network.
Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices.
Information required for version 3.2.1
If your dataflow diagram has enough information to complete the following table in the ROC, then it is above average (and your QSA will thank you).
| Cardholder data flows | Types of CHD involved (for example, full track, PAN, expiry, etc.) |
Describe how cardholder data is transmitted and/or processed and for what purpose it is used (for example, which protocols or technologies were used in each transmission) |
| Capture | Retail: Full Track
Ecommerce: PAN, expiry and CVV |
Retail: CHD is captured by magnetic stripe or dip read into the point of sale application.
Ecommerce: CHD is entered by cardholder onto encrypted webpage. |
| Authorization | Retail: Full Track
Ecommerce: PAN, expiry and CVV |
Retail: Transmitted via TLS encrypted network connection to <ACQUIRER>. Token value for PAN is received.
Ecommerce: Transmitted via TLS encrypted network connection to <ACQUIRER>. Token value for PAN is received. |
| Settlement | Retail: None
Ecommerce: None |
Retail: No cardholder data, tokenized values and authorization values.
Ecommerce: No cardholder data, tokenized values and authorization values. |
| Chargeback | Retail: truncated PAN (first 6 and last 4)
Ecommerce: None |
Retail: No cardholder data, tokenized values and authorization values.
Ecommerce: No cardholder data, tokenized values and authorization values. |
| Identify all other data flows, as applicable (add rows as needed) | ||
| Other (describe) N/A |
N/A | N/A |
| Other details regarding the flow of CHD, if applicable: | N/A | |
Other
On top of including the above information in your data flow diagram, I think its great to include information about your cryptographic architecture on your data flow diagram.
- Details of algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
- HSMs and other SCDs used for key management
Your QSA will thank you.
Ad below this line:
