Data flow mapping means documenting where data comes from, which systems and code touch it, how it's transformed, where it's stored and who it's shared with. In privacy work it mostly covers personal data (PII) and other sensitive data such as health data (PHI). The goal is to answer GDPR Article 30, CCPA and HIPAA questions with evidence. A good data flow map works at the field level and covers application code and pipelines, not only databases. It also has to stay current as code changes.
What a data flow map includes
For each type of personal or sensitive data, a usable map records:
- Source: the app, form, API or vendor where the data enters.
- Processing: the services, jobs and pipelines that read, copy or transform it, down to the field.
- Storage: the databases, warehouses, lakes and files where it lands, and for how long.
- Consumers: dashboards, reports, ML models and AI tools that use it.
- Transfers: third parties and cross-border destinations.
- Purpose and owner: why it's processed and who's accountable.
Data flow mapping vs. data inventory vs. data lineage
A data inventory lists what personal data you hold and where it's stored. A data flow map adds movement, meaning how that data travels between systems and vendors. Data lineage is the technical version of the same idea. It traces how each column is produced from upstream columns through code and transformations. For privacy, field-level data lineage keeps a data flow map accurate. The lineage is generated from the systems themselves instead of from interviews.
Why it matters for GDPR, CCPA and HIPAA
- GDPR Article 30 requires a record of processing activities (ROPA): categories of data, purposes, recipients, transfers and retention. Most of the ROPA is built on top of a data flow map. See GDPR.
- CCPA and CPRA give consumers the right to know, delete and opt out. To delete someone's data, you first have to know where every copy is. See CCPA.
- HIPAA expects covered entities to know where electronic PHI is created, stored and sent, as part of their risk analysis.
- DPIAs and audits use the map as the starting point for spotting high-risk processing.
How to build a data flow map
- Start with data categories. List the personal and sensitive fields you care about, such as email, SSN, card number or diagnosis code.
- Find where each field enters. Look at application code, forms, APIs and vendor feeds.
- Trace it through code. Follow each field through services, ORMs, ETL jobs, dbt models, Spark jobs and into the warehouse. Manual maps usually go stale at this step, because most of the movement happens in code.
- Follow it downstream. Check BI dashboards, exports, ML features and AI tools.
- Add purpose, owner and retention for each flow, and record third-party transfers.
- Keep it current. Re-check the map when code changes, ideally in the pull request, so a new copy of personal data is caught before it ships.
Manual vs. automated data flow mapping
Manual mapping means interviews, spreadsheets and questionnaires. That's fine for a first pass, but the map drifts as soon as code changes. Automated approaches fall into three groups:
- Privacy management platforms (for example OneTrust, TrustArc, DataGrail) manage ROPA workflows, assessments and vendor records.
- Data discovery and classification tools (for example BigID) scan stored data to find where sensitive fields sit.
- Code-based tools read source code to see how data moves before and after it's stored. Foundational is one of them. It builds column-level lineage from application and pipeline code (Java, Python, Scala, SQL, TypeScript, Go, Spark, dbt, Airflow, ORMs and more) through the warehouse into BI. You can follow a PII field from the service that writes it to the dashboards and models that read it. Pull request checks show a change's downstream impact before it merges.
A common setup combines a privacy platform for the ROPA workflow with a code-based lineage source that keeps the technical map accurate.
How Foundational helps with data flow mapping
- Field-level tracing across layers: follow a personal data field from application code and ORMs through pipelines and the warehouse to BI. More on this in PII governance across application layers.
- Checks in pull requests: see which downstream tables and dashboards a code change affects before it merges. Compliance rules can also be defined as code and checked at build time.
- Access: most teams connect their code repositories plus warehouse and BI metadata, and constrained teams can start with code access only. Customer data is accessed only if data observability checks are turned on.
See Compliance and privacy for how teams use it.
FAQ
What is data flow mapping in GDPR?
It means documenting how personal data moves through your organization, from collection to processing, storage, sharing and deletion. The map feeds the Article 30 record of processing activities and DPIAs.
What's the difference between a data map and a data flow map?
A data map or inventory shows where personal data is stored. A data flow map also shows how it moves between systems, code and vendors.
Can data flow mapping be automated?
Yes. Discovery tools scan stored data and privacy platforms manage the records. Code-based tools like Foundational trace how fields move through application and pipeline code, so the map updates when the code does.
How often should a data flow map be updated?
Whenever processing changes. In practice that's every code change that touches personal data. That's why a check in the pull request works better than a yearly review.
Is data lineage the same as data flow mapping?
They overlap. Data lineage traces how each column is produced through code and transformations. Data flow mapping takes that technical view and adds business context such as purpose, owner and transfers.
<script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/3.8.0/gsap.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/3.8.0/ScrollTrigger.min.js"></script>
<script>
// © Code by T.RICKS, https://www.timothyricks.com/
// Copyright 2021, T.RICKS, All rights reserved.
// You have the license to use this code in your projects but not to redistribute it to others
gsap.registerPlugin(ScrollTrigger);
let horizontalItem = $(".horizontal-item");
let horizontalSection = $(".horizontal-section");
let moveDistance;
function calculateScroll() {
// Desktop
let itemsInView = 3;
let scrollSpeed = 1.2; if (window.matchMedia("(max-width: 479px)").matches) {
// Mobile Portrait
itemsInView = 1;
scrollSpeed = 1.2;
} else if (window.matchMedia("(max-width: 767px)").matches) {
// Mobile Landscape
itemsInView = 1;
scrollSpeed = 1.2;
} else if (window.matchMedia("(max-width: 991px)").matches) {
// Tablet
itemsInView = 2;
scrollSpeed = 1.2;
}
let moveAmount = horizontalItem.length - itemsInView;
let minHeight =
scrollSpeed * horizontalItem.outerWidth() * horizontalItem.length;
if (moveAmount <= 0) {
moveAmount = 0;
minHeight = 0;
// horizontalSection.css('height', '100vh');
} else {
horizontalSection.css("height", "200vh");
}
moveDistance = horizontalItem.outerWidth() * moveAmount;
horizontalSection.css("min-height", minHeight + "px");
}
calculateScroll();
window.onresize = function () {
calculateScroll();
};let tl = gsap.timeline({
scrollTrigger: {
trigger: ".horizontal-trigger",
// trigger element - viewport
start: "top top",
end: "bottom top",
invalidateOnRefresh: true,
scrub: 1
}
});
tl.to(".horizontal-section .list", {
x: () => -moveDistance,
duration: 1
});
</script>
See How Personal Data Moves Through Your Code
Book a demo to trace a PII field from the service that writes it to the dashboards that read it.
See How Personal Data Moves Through Your Code
Book a demo to trace a PII field from the service that writes it to the dashboards that read it.
See How Personal Data Moves Through Your Code
Book a demo to trace a PII field from the service that writes it to the dashboards that read it.
