Skip to content
The notification just landed in your inbox: the examiners are coming. For many community bank IT officers, this moment triggers a scramble to update policies, gather logs, and double-check vendor contracts.
But there is one document that often gets overlooked until the last minute—your network diagram. More specifically, your data flow diagram.
It’s easy to view this as just another box to check on the pre-exam request list. However, it shows regulators that you understand your environment, know where your sensitive information lives, and, most importantly, know how to protect it.
Let’s walk through how to build a diagram for community banking IT that doesn’t just satisfy the examiners but actively helps you manage risk.
Why Do Examiners Care About Squiggly Lines?
To an outsider, a data flow diagram might look like a mess of shapes and arrows. To an examiner, it’s a litmus test for your entire Information Security Program.
When regulators evaluate your institution’s technology environment, they are primarily assessing your risk exposure. They want to see representations of the IT environment because they need to know if you know what you are doing.
If you can’t visually demonstrate where customer Non-Public Personal Information (NPI) enters your bank, where it is stored, and who creates it, you cannot effectively protect it.
The data flow diagram helps them assess three critical areas:
- Architecture: Is the network designed securely?
- Operations: Does the data move efficiently and logically?
- Third-Party Risk: Are you sending sensitive data to vendors without adequate controls?
If your diagram is outdated or missing key connections, it signals to the examiner that your risk assessment might be flawed, which can lead to a much deeper, more painful dive into your operations.
Step 1: Start With Business Processes
Start by thinking about what your bank actually does. A good data flow diagram is rooted in business logic, not just hardware.
Think about a standard process, like opening a new checking account.
- How does the customer provide their information? (Online form? In-branch tablet?)
- Where does that information go first? (Your core processor? A document imaging system?)
- Who needs to see it? (The teller? The compliance officer for BSA checks?)
By mapping the business process first, you ensure you aren’t missing the “flow” part of the data flow diagram.
Step 2: Identify and Classify Your Data
Regulators expect institutions to identify and classify data assets based on criticality and sensitivity. You don’t need to map every single email sent about a potluck lunch. You do, however, need to map every instance of a Social Security number moving across your network.
Focus on data types that matter to risk:
- GLBA Data: Customer names, SSNs, account numbers.
- Strategic Data: Board minutes, strategic plans, merger info.
- Operational Data: Employee payroll, internal emails.
If your data flow diagram treats a marketing brochure the same way it treats a loan application, it’s not granular enough to be useful during an exam.
Step 3: Map the Journey (The Core of the Diagram)
Now, it’s time to draw. Standardizing your shapes helps examiners read the map quickly.
External Entities
These are the sources and destinations outside your direct control.
- Example: The Customer (Source), The Credit Bureau (Destination), The Federal Reserve (Destination).
Data Flow
The arrows represent the movement of data. Label these clearly.
- Example: An arrow from “Customer” to “Mobile App” labeled “Login Credentials / Bio-metrics.”
Processes
These are the systems or activities that manipulate the data.
- Example: Your Core Banking System, the Loan Origination System, or the Email Server.
Data Stores
Where does the data rest?
- Example: The SQL Database on Server A, the physical file cabinet in the loan department, or the cloud storage bucket for your backups.
Trust Boundaries
This is a critical visual element for security. A trust boundary indicates where the level of trust or security changes.
- Example: The line between your internal trusted LAN and the wild internet. Or the line between your employee Wi-Fi and the guest Wi-Fi.
Step 4: Show Third-Party Touchpoints
Community banks rely heavily on vendors. Your data flow diagram must reflect this reality. Examiners are currently hyper-focused on third-party risk management, so hiding your vendors behind a generic “Internet” cloud won’t fly.
Be specific about where data leaves your walls. You need to identify:
- The Core Provider: The heart of your operation.
- Cloud Systems: Microsoft 365, Azure, or AWS instances.
- Managed IT: If a partner manages your patching, show their connection.
- Fintech Integrations: That new peer-to-peer payment app you just launched? It needs to be on the map.
- Statement Vendors: Who prints and mails your monthly statements?
If a vendor is touching customer data, they earn a spot on the diagram.
Step 5: Overlay Security Controls
This is the step that turns a drawing into a compliance tool. A data flow diagram without security controls is just a plumbing schematic. You need to show how you keep the pipes from leaking.
Add indicators for controls at key points of the flow:
- Encryption: Is the data encrypted in transit (TLS 1.2) and at rest (AES-256)? Add a lock icon.
- MFA: Does accessing the core require Multi-Factor Authentication? Note it.
- Firewalls: Show where traffic is filtered.
Remember, examiners evaluate whether controls align with risk, not just whether controls exist. If you show NPI flowing to a vendor via unencrypted email, your data flow diagram has just successfully identified a finding for you (before the examiner does).
Step 6: Connect the Diagram to Risk Management
The ultimate goal is to make this document useful internally. When you look at your finished product, can you answer the scary questions?
- “What happens if this vendor fails?” You should be able to trace the flow and see exactly which business processes stop.
- “Where would ransomware spread?” If an employee’s PC gets infected, does the diagram show a segmentation line protecting the backup server?
- “Which systems require monitoring?” If a data store holds 10,000 SSNs, does it have the same logging requirements as the cafeteria menu server?
Good vs. Bad: What Does It Look Like?
A bad data flow diagram is often overly complex yet vague. It might show every single switch and cable (a physical network map), but fail to show where the loan applications actually go. Or, it simplifies too much, showing “The Bank” as one box and “The Internet” as another, with a single line connecting them.
A good data flow diagram tells a story. It is readable. It focuses on the data, not the wires. It clearly distinguishes between an internal employee accessing a file and a remote vendor accessing the network. It makes the examiner nod their head and say, “Okay, I see how you process a wire transfer.”
When Should You Update It?
A common exam finding is a “stale” diagram. A data flow diagram from 2019 does not account for the three new SaaS products you implemented last year or the shift to remote work.
You should update your diagram:
- After a Major System Change: New core? New firewall? Update the map.
- After Vendor Onboarding: Before you sign the contract, map the flow.
- After Security Incidents: If something went wrong, update the diagram to show the new controls you put in place.
- During the Risk Assessment Cycle: Use the diagram to inform the assessment, and use the assessment to refine the diagram.
- At Least Annually: Put it on the calendar.
Get a Fresh Set of Eyes
Building a data flow diagram can feel overwhelming, especially when you are in the weeds of daily IT operations. Sometimes, you need a partner who knows what examiners are looking for and can help you spot the gaps in your documentation.
At RESULTS Technology, we specialize in helping community banks navigate the complexities of IT compliance and security. We can help you assess your environment, identify your risks, and prepare for your next exam with confidence.
Ready to see where you stand?
Get a Free Assessment from RESULTS Technology
