Skip to main content


Data Flow Diagrams 101

Have you recently been through an audit or exam and received a recommendation to develop Data Flow Diagrams? Have you recently completed a Cybersecurity Assessment using the FFIEC’s Cybersecurity Assessment Tool (CAT) and noticed that the creation of Data Flow Diagrams is a CAT Domain 4: External Dependency Management requirement under the Assessment Factor of “Connections”? Creating Data Flow Diagrams is a Baseline Cybersecurity Maturity control, meaning that all financial institutions are expected to have them.

If either of these exercises left you confused and wondering what you’re supposed to do next you’re not alone. Financial institutions are struggling to develop and even determine the importance of developing a Data Flow Diagram (DFD). So what is a DFD? Quoting directly from the “Network Components and Topology” section of the FFIEC Operations Handbook (2004):

“Management should also develop data flow diagrams to supplement its understanding of information flow within and between network segments as well as across the institution's perimeter to external parties. Data flow diagrams should identify:

  • Data sets and subsets shared between systems;
  • Applications sharing data; and
  • Classification of data (public, private, confidential, or other) being transmitted.”

The “Network Components and Topology” section of the FFIEC Operations Handbook also discusses Network Diagrams, so no one should be faulted for incorrectly assuming their Network Diagram counted as a Data Flow Diagram. However, a DFD is a completely different requirement than a Network Diagram and serves a different, but very useful, purpose. Let’s break DFDs down a little bit.

A Data Flow Diagram should:

  • Supplement an institution'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

Domain 4: External Dependency MangementWhy 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 pretty 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 of 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 most institutions don’t know where to start. Having already defined what a DFD entails, the next step is to identify 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, third parties)
  • Whether or not that actor stores, transmits, or processes customer information
  • The points at which customer information enters or exits the institution’s network perimeter
  • How the information flows between each actor through the course of the business process

Following this model your Data Flow Diagram(s) will:

  • Help you understand where your customer information is flowing across the institution's 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 parties 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 institution 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. Simply ensure you’re consistent in your approach and ensure it’s well grounded in solid risk assessment data (Business Impact Analysis / IT Risk Assessment). 

Data Flow Diagram


Written by: Cody Delzer 
Senior Information Security Consultant
SBS CyberSecurity, LLC

SBS Resources:

  • {Hacker Hour} Creating a Data Flow Diagram: According to our research, the development of a Data Flow Diagram (DFD) is one of the most common missing baseline statement in the FFIEC Cybersecurity Assessment Tool. Many financial institutions struggle with finding value in the DFD or have a hard time getting started. Join SBS as we discuss the guidance around DFDs and walk through examples of ways you can create a DFD for your organization - and get value from it.

Hacker Hour webinars are a series of free webinars hosted by SBS CyberSecurity. Unlike paid webinars, Hacker Hours are aimed to meet on a monthly basis to discuss cybersecurity issues and trends in an open format. Attendees are encouraged to join the conversation and get their questions answered. SBS will also offer products and services to help financial institutions with these specific issues.

Posted: Wednesday, July 11, 2018
Categories: Blog