Take Your Data Map from Promise to Practice

Picture yourself in a product meeting for a new feature that you want to add to your offering, and someone turns to you with a perfectly reasonable question.

“Where does this data go after we collect it?”

Unfortunately, the simple questions often have really hairy answers. Your colleagues don’t want to know where the data is supposed to go or where it goes according to that one diagram someone who’s no longer with the company drafted during a 2021 compliance sprint.  They want to know where the data goes right now, in systems that exist today, with vendors you use today, and from the trackers that your marketing team added last Thursday.

Everyone looks at you. You look at the outdated diagram from 2021. Someone suggests you “ask engineering.” Engineering suggests you “ask the vendor.” The vendor suggests you “check the documentation.” The documentation suggests you “contact support.” Support instructs you to “open a ticket.” And thus, it becomes that your data map isn’t a really a data map at all—it’s a scavenger hunt with no prize, just more meetings.

That’s the moment a privacy team realizes the truth about data mapping.  It’s not optional. It’s not nice-to-have. It’s the difference between being able to answer questions with confidence and being forced to perform interpretive dance in front of auditors.

Remember when the news was about what happened, not how to feel about it? 1440's Daily Digest is bringing that back. Every morning, they sift through 100+ sources to deliver a concise, unbiased briefing — no pundits, no paywalls, no politics. Just the facts, all in five minutes. For free.

Read the newsletter trusted by 4.5 million fact-seekers.

Teams sometimes avoid creating data maps because there is this idea that it must be perfect, comprehensive, and visually gorgeous. For some reason, it becomes better to procrastinate for perfection than ships something useful.

That’s why I always advise clients to aim for sensible, rather than resplendent. A sensible data map has a different goal than one that exist for the purpose of mapping every piece of data in your organization. It creates a working model of your data reality designed to help you make decisions faster. Sensible data maps support privacy operations, such as incident response, vendor reviews, DSR workflows, retention, and even public notices, and it is able to do all of this because it answers the same three questions for each of these operations:

If you can answer those three questions for your core systems, you’re already ahead of most companies that can quote legal requirements but can’t point to the systems that implement them. If not, believe me, this is a doable goal. Also, it has a lot of great benefits that you can tout when you need to find budget and resources to get it done.

Data maps reduce privacy tax, which is the cost of transactional friction associated with privacy considerations. When you can show the flow, you spend less time re‑explaining context. You can onboard new stakeholders faster. You can do faster risk reviews. You can respond to customer and partner due diligence without a panic spiral.

Another benefit, one that’s often underrated, of the data map is that it makes your internal conversations less abstract. Instead of debating whether something is “personal data” in the philosophical sense, you can point to where it is collected, where it is stored, and what the business actually does with it. And if you’re in a business with complex distribution models such as dealers, franchisees, resellers, and contractors, data mapping is the only way to see where responsibility and control get blurry. The blurry edges are where incidents, complaints, and audits tend to live.

Your data map will fail if you treat it like a static deliverable, not a living artifact. The only thing worse than doing a bunch of hard work is doing a bunch of hard work and resulting in something that’s not useful. For example, bad data mapping might look like:

The goal in creating your data map is to design it like an operational tool, not just pump effort into mapping until the team throws up their hands and decide it has other priorities. Worse is when teams treat the map as a one-time deliverable for a specific law or a specific audit. The map gets built to satisfy a request, not to support the way the organization actually works. When the request goes away, so does the motivation to maintain it.

If you want your map to survive, tie it to recurring pain. Every time you get asked a question you can’t answer quickly—“Where is this stored?”, “Which vendor receives this?”, “Can we delete this?”, “Does this leave the country?”—add that question as a map requirement. Let your map earn its keep.1. Start with inventory, because inventory is your map to the rest of these issues

A common post-merger mistake is to assume the acquired company’s practices are “basically similar” to your own. Maybe they are mature. But mature is not the same thing as aligned.

Their systems are different. Their vendors are different. Their subprocessor lists are different. Their collection points are different. Their defaults are different. Their internal names for systems are probably different. Even if both organizations are reasonably sophisticated, they almost certainly made different decisions over time, which means that discovery has to come before assumptions.

You need a merged view (at least for critical systems) of what personal data is collected, where it lives, what it is used for, who can access it, where it flows, and which vendors touch it. You do not need a mural-sized masterpiece by day 10, but you want enough inventory clarity to answer the following practical questions: what is in scope for integration, what will change upon integration, and where do the highest-risk unknowns live.

Think of inventory as your map. Without it, everything else is guesswork.

Think of your data map as a subway map, not a satellite image. A subway map is intentionally simplified. It’s designed to help you navigate under time pressure. It shows major stations and connections, not every building on the route.

A sensible data map focuses on the paths that matter: sources, core systems, key vendors, and meaningful outputs. It captures where data crosses a boundary (e.g., between systems, teams, or companies) because boundaries are where risk and obligations show up, but it’s not a complete database schema. It is not a security network diagram. It is not a replacement for detailed architecture docs. It’s a privacy-operational lens on data movement.

Another way to frame it is to think of a privacy data map as a communication tool. It’s designed to help privacy, security, engineering, and business teams share the same mental model. If your diagram is only legible to the person who built it, it’s a journal, not a map.

I have a lot of opinions about data maps, but one important one is that you should have multiple maps at different levels, and you should not aim to craft a data map that is one size fits all (or none). You typically need a high-level map for executives and auditors, and a slightly more detailed map for operators who need to take action. You do not need a single mega-diagram that satisfies everyone. That way lies madness.

These terms get used interchangeably, and that’s part of the confusion.

A data inventory is usually a list: systems, data categories, purposes, owners, vendors, locations, and retention. It’s great for coverage and governance.

A data map is usually a picture: it shows movement and boundaries. It’s great for understanding how things connect and where obligations get triggered.

A register (like an evidence index or a PIA register) is usually about lifecycle: what exists, who owns it, and what the current status is.

You don’t need all of these on day one. But over time, mature programs converge on a pattern, and that pattern looks like the inventory as your backbone, the map as your visualization, and the registers to help you operate and prove what you’re doing.

If you only build one version, build the version that answers questions during an incident, a DSR request, and a vendor review. That usually means mapping:

Then add owners, because that’s what takes it from drawing to system.

If you’re not sure where to start, start with boundaries. List every point where personal data crosses from one system to another, or from your organization to a vendor. Those handoffs are where you need to understand purpose, permissions, retention, and contractual constraints.

Also, don’t ignore internal sharing. A lot of privacy drift happens when data collected for one purpose starts being used for another because you already have the data… so it’s yours, right? Your map should make that visible, even if it’s uncomfortable.

Level 1: The Executive Map. One page. Major systems. Major vendors. Regions. Key data categories. This is what you show leadership, auditors, and business stakeholders who want clarity without the plumbing.

Level 2: The Operator Map. Still readable, but with enough detail to drive action. It includes the top data streams (collection → storage → use → sharing), the decision points (consent, retention, cross‑border), and named owners.

Level 3: The Deep Dive. This is a limited-scope, system-specific map created (as needed) for a specific purpose, such as a high-risk feature, a sensitive dataset, a major incident, or a regulatory request. It should not be your default for everything.

If you try to build Level 3 for your entire organization, you will create a beautiful museum piece that nobody updates. Start with Level 1 or 2.

This the part nobody wants to hear. You won’t map your way out of uncertainty by doing it alone. Data mapping is a coordination exercise.

The quickest path is to start from a small set of high‑impact systems and expand. Pick 5–10 systems that collectively touch the most personal data inside your organizations, such as identity/auth, CRM, HRIS, support ticketing, data warehouse, analytics/tag manager, and your marketing automation platform. Add core infrastructure if you have it (e.g., cloud storage buckets, file shares, email platforms). Then run short “data path interviews” with system owners. Not a two‑hour workshop with 20 people. Fifteen minutes with the person who actually knows where data goes. Your goal is to capture what comes in, what goes out, and which vendor gets a copy.

Use your existing inventories if you have them. If you don’t, that’s okay—start with the map and let it become the seed inventory. A practical trick is to build your map from questions, not boxes. Before you open Visio or Miro, write down the top 10 questions you’re always asked. Then design the map so that the answers are obvious.

If the question is “Which vendors receive this dataset?”, your map should have a clear vendor boundary and labels. If the question is “Does this data leave the U.S.?”, your map should show regions or hosting locations.

Another trick is to treat mapping as a series of “walkthroughs.” Pick one user journey or one data stream and map it end-to-end. Then pick the next. The map grows like a set of stitched pathways, not like a massive upfront architecture plan.

The map becomes valuable when you treat it the same as you should be doing for other operational artifacts. That means assigning ownership, defining triggers, and maintaining evidence.

Ownership: Decide who owns the map overall (often privacy or security) and who owns each major system’s accuracy (system owners).

Cadence: A quarterly review for core systems is usually enough to catch drift before it becomes a trust problem.

Triggers: Add a lightweight “map update required” step to SOPs for events that create drift: new vendor onboarding, new SDK/tag added, new product feature that changes data collection, acquisitions/integrations, and incident post-mortems.

Evidence: Keep simple proof points that the map reflects reality, such as screenshots of CMP settings, vendor subprocessors lists, data inventory entries, and the last review date. Evidence turns your map into something you can defend when someone asks, “How do you know?”

If you have a change management process (even a lightweight one), use it. The map should be updated at the same time as the system changes. Otherwise you end up with the classic privacy paradox: a map that always seems to be accurate for the past and always wrong for the present.

Finally, don’t confuse “having a map” with “having governance.” The map tells you what exists. Governance tells you what you’re allowed to do and who decides. The two work together. If your map reveals a new data flow, your governance process decides whether that flow is acceptable and what controls must be added.

If your team has been staring at a blank canvas for six months, start smaller. The micro-tool included in this post is a 60‑minute “data path sketch” you can run for one system or one feature. It’s intentionally constrained because the first goal is to build momentum.

Once you can sketch a single path end‑to‑end, you can build the map out in layers. That’s how real programs mature; one artifact at a time.

Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the 60-Minute Data Path Sketch. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.

The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.

If that sounds like your kind of work, we’d love to have you.