A number of years ago, I wrote a post on how to diagram for your QSA. While my original post still has validity, there have been a few changes have occurred so I thought it was a good time to update everyone so that diagrams meet what your QSA needs for documentation.
One of the changes that came with v3 of the PCI DSS was with requirement 1.1.3 that now explicitly calls out that the data flow diagram be overlaid on the network diagram. The purpose of this was twofold. First, such an approach allows the organization being assessed to further refine their scope for their PCI assessment. Second, it allows the QSA an easier time to confirm that the scope of the PCI assessment is accurate.
Prior to v3, organizations had a tendency to deliver data flow diagrams that had no basis in reality as to how they were physically implemented. A lot of this was due to the fact that developers and networking types never communicated between one another. As a result, QSAs would hear comments such as, “All I know is it just works”, “You’ll have to ask the developers …” or “You’ll have to ask the networking people …”. This obviously resulted in a lot of discussions (i.e., arguments) over scope accuracy between QSAs and their clients. Under the new v3 requirements, hopefully all of those discussions will go a lot easier and faster.
Regardless of what requirement 1.1.3 states, QSAs are still encountering data flow diagrams that look more like cubist or surrealist paintings. This situation seems to be driven by the fact that a lot of organizations either do not want to or cannot get their developers and networking folks together to come up with a data flow diagram that can marry up to the network diagram. Let me tell you that going through this exercise greatly reduces the issues surrounding scope because scope becomes very clear once everyone can “see” how data flows through the network. However, it is not surprising when organizations come back and say they found the exercise too daunting. Lots of organizations operate in such a siloed structure, that: (1) it takes an act of God to get everyone necessary together for such a discussion, (2) everyone agrees on the flows and networks used and (3) somewhere there is a flow that no one knows about or knows how it works. All of this can be resolved, but it takes time and information to work out and can end up being incredibly tedious particularly in a complex environment.
Unfortunately, while the scope becomes much clearer once the dataflow is overlaid on the network, the scope also tends to end up much larger than anyone realized. That is because systems that were thought to not have any connectivity (Category 3) to the cardholder data environment (CDE) end up as connected systems that could impact or influence the security of the CDE (some form of Category 2). It is then that there is a “mad dash” to minimize the number of these systems that need connectivity, i.e., reduce scope. It is during these scope reduction efforts that we encounter twisted and contorted arguments regarding systems that are clearly in-scope, but the client does not want to be in-scope and will do anything and everything imaginable to remove them from scope. Some of these discussion become so tortured in their logic as to be laughable, e.g., “Can’t we just ignore them?” and my personal favorite, “If I paint these servers “blue” will they then be out of scope?”.
But to further confirm scope, v3 introduces us to a revised requirement 11.3 that went into effect on July 1, 2015. As part of that change, the penetration test methodology now requires that the penetration testing exercise prove that network segmentation is in place as documented and therefore further prove that the scope for PCI compliance is accurate. This basically requires the penetration tester to confirm that your network diagram overlaid with the dataflow in fact fully documents your organization’s scope for PCI compliance. Therefore, if your dataflow and network diagrams are junk, do not be surprised if your penetration tester and/or QSA come back and tell you that your scope is larger than you thought.
Behind the scenes, there has been a change made by the PCI SSC through their reviews of QSAs’ ROCs under their quality assurance program. The Council is concerned that the diagrams put in ROCs are not always legible to readers. While organizations provide the original diagrams, the Council wants diagrams in reports to be legible for the banks and processors when they review the reports. As a result, QSAs and ISAs have been informed that their ROCs need to break out or section large diagrams so that they are legible on standard paper (i.e., 8.5”x11” or A4). As a result, a lot of ROCs are exponentially increasing in size to accommodate the network and data flow diagrams that now require many additional pages to ensure that the diagrams are legible in the ROC.
This should bring us all back up to date on network and dataflow diagrams.
PCI Guru 
Oh no – it’s not – this is for the QSA – my bad.
Great post. Under 2.0, I’ve had QSAs actually tell me to REMOVE IP addressing information. And yes, you probably know the company where these QSAs worked.
You can never tell where these reports end up. However, given all of the other information in these reports, removing IP addresses from diagrams is the least of the problems.
Hi,
We are currenty under assesment but we were not required to overlay the flow on the network diagram, instead we are making one dataflow diagram per process, it this correct?
The requirement says:
Current diagram that shows all cardholder data flows across systems and networks
As you say i think the data flow should be overlay on the network diagram, do you have any sample?
I would love to give you a sample, but I cannot. However, I can describe what it should look like. Think of a fairly detailed network diagram (firewalls, routers, switches, load balancers, servers, appliances, etc.) and then putting dataflow arrows over it documenting ports/services and dataflow direction(s), i.e., directional arrows. I have clients use GREEN to designate flows that are secured in some way. I have them use RED to designate those flows that are in clear text or not encrypted. Typically, I have only one application per diagram but that might vary depending on application integration and other fators. For flows that are in-scope but not necessary for PCI compliance such as the return of a token, I use YELLOW or ORANGE to designate those. In all cases, I use callouts to document what the flow is related to, how the flow works (not encrypted or encrypted and the encryption method/strength), why of the flows so there is sufficient documentation on the flows. I also have the flows numbered in the order they work so that those can be further described in detail in a Word document or in the diagram itself whichever is easiest and clearest if the diagram gets too small.
Thanks for the information 🙂
Hi PCI Guru,
Great article – just one question, will this apply to organisations that only have to do SAQ A? as that just talks about high level description of the environment.
Are there any good practice documentation recommendations for such organisations that have to fill SAQ A?
Cheers,
Ash
Requirement 1.1.3 is not covered in the SAQ A, so the answer would be ‘No’.
Just curious – regardless of network diagram, and what SAQ is applicable – should all merchants have documented payment flows?
Regards,
Ash
Regardless of SAQ, yes, every organization should know how data flows through their network and applications. It’s just a good practice and can save you if issues come up or there is a breach somewhere. At a minimum, thsoe diagrams will provide some proof that you understand your environment and that you could or could not be the source of the breach.