Have you recently been through an audit or exam and received a recommendation to develop data flow diagrams (DFD)? Have you recently completed a cybersecurity assessment using the FFIEC’s Cybersecurity Assessment Tool (CAT) and noticed that creating data flow diagrams is a CAT Domain 4: External Dependency Management requirement under the assessment factor of “Connections”? If either of these exercises left you confused and wondering what you should do next, you’re not alone.
So, what is a DFD? Although creating data flow diagrams is a Baseline Cybersecurity Maturity control, meaning that all financial institutions are expected to have them, organizations are struggling to develop and even determine the importance of developing a DFD. Quoting directly from the “IT and Business Environment Representations” section of the FFIEC Architecture, Infrastructure, and Operations Handbook (2021):
A data flow diagram is a graphical representation of the flow of data internally through the entity's network(s), business units, products, and software, and to third parties, as applicable. Data flow diagrams and network diagrams may include similar information (e.g., critical hardware) but have different purposes. Data flow diagrams show how the entity’s data flows between critical hardware on the network, not just where a piece of hardware resides.
In smaller or less complex IT environments, data flow diagrams and network diagrams may be combined. In larger or more complex IT environments, the entity generally has multiple data flow diagrams and network diagrams broken out in a variety of ways (e.g., lines of business, geographic locations, network segments, and business functions). Data flow diagrams may include the following:
- Storage locations of data (i.e., data at rest), especially sensitive data, and where data flow between equipment and systems (i.e., data in transit).
- Data sharing between applications.
- References to network diagrams for details of internal and external connectivity.
- Specific operational or business processes and any single points of failure.
- Data flow within the entity (e.g., operational or business process interaction and interdependencies) and between the entity and its third-party service providers.
The "IT and Business Environment Representations" section of the FFIEC Architecture, Infrastructure, and Operations Handbook (2021) also discusses network diagrams. No one should be faulted for incorrectly assuming their network diagrams counted as a data flow diagram. However, a DFD is an entirely different requirement and serves a different, but very useful, purpose.
Let’s break down a data flow diagram. A DFD should:
- Supplement an organization's understanding of information flow within and between network segments as well as across the institution’s perimeter to external parties.
- Identify data sets and subsets shared between systems.
- Identify applications sharing data.
- Highlight the classification of data being transmitted.
Why Data Flow Diagrams are Important
Keep in mind that the FFIEC CAT requirement for DFDs falls into Domain 4, which covers vendor management. Why would the requirement for a DFD fall into the vendor management category? The answer is simple: financial institutions are now more reliant than ever on vendors to perform day-to-day operations. More information is being stored, transmitted, and processed outside your network than inside. And the big question here is this: do you know where your data is going once it leaves your network?
How to Start Creating Your Data Flow Diagrams
The crux of the DFD problem is that most organizations don’t know where to start. Having already defined what a DFD entails, the next step is identifying which vendors are storing, transmitting, and processing your data outside your network. One of the most effective ways to begin creating a DFD is to look at your critical business processes, which you should (hopefully) have identified as a part of your business impact analysis.
Let’s take wire transfers as an example. It’s important to step through the flow of each process and identify where your customer information is being sent. There are typically numerous ways to initiate a wire transfer, whether it be in person, over the phone, via email, or through a business online banking platform. Where does your customer information go after the request is initiated? Through which entity or vendor does it pass? Where does it end up? This line of questioning will lead you to the DFD answers you seek.
Start by creating data flow diagram(s) that depict:
- The actors involved at different steps in a critical business process, as identified in your business impact analysis (including people, technology, and third parties).
- Whether or not that actor stores, transmits, or processes customer information.
- The points at which customer information enters or exits the network perimeter.
- How the information flows between each actor throughout the business process.
Following this model, your DFD(s) will:
- Help you understand where your customer information flows across the perimeter to external parties. Notably absent here are network segment flows; feel free to add those if you’d like, but one could argue they are covered in network diagrams).
- Identify to which external party's customer information (the data set discussed above) is being transmitted.
- Identify applications, systems, and vendors sharing your customer information.
There you have it! Data flow diagrams need not be difficult. In fact, a good DFD should help your organization have a much better understanding of where your data is actually going once it leaves your network and who is touching it along the way. Be consistent in your approach and ensure it’s well grounded in solid risk assessment data (business impact analysis / IT risk assessment).
