Body
Data Flow Diagram Overview
Purpose
The primary purpose of a Data Flow Diagram (DFD) is document 1) what data is being used, 2) where data is being sent to/from, and 3) how the data is being transferred between systems. This information is to help support compliance and troubleshooting efforts by providing contextual information of where an issue may be occurring. This also assists security teams during reviews, and auditors during assessments, to allow for quick understanding of what level of security is needed on what systems as well as what potential control points may be available for use. Fundamentally, the diagram should be spatial and architectural and be simple enough to explain to an auditor.
Required elements
- Data types
- Data classification (including if regulated elements are involved)
- Example: 'High Risk - HIPAA', 'low risk', 'Moderate Risk - FERPA'
- For CUI environments, include FIPS 199 Categorization
- For high risk, please include a reference for the specific data elements being processed that make it high risk
- Systems
- Specific servers, workstations, applications, or containers that process or store information
- Example: 'User workstation', 'my.uidaho.edu', 'app container'
- Where data is stored, protections should be noted: 'AES256 encrypted at rest'
- Data flows
- Protocols, methods, protection controls, or any other relevant information
- Example: 'REST API POST request over TLS 1.3', 'SFTP', '
- Environment boundaries
- Relevant network/infrastructure boundaries that change the context of the security implementation including all entry and exit points
- Example: 'UI network boundary', 'Container(s) running on OKE', 'Oracle Cloud', 'Public/Internet-facing', 'DMZ', 'Internal'
Data Flow Diagram examples:
The following examples are DFD formats that are known to be acceptable. Other formats may be done as long as they accurately and clearly convey the information listed in the required elements.
Example 1:
Example 2:
Example 3:
Example 4:
Example 5:
