Practical guide · 2026
How to Draw a Working Data Map for a Live Product
Start with one event, follow every copy and put decisions beside the route. A practical data map is an operating instrument, not a decorative diagram.
- Reading time
- 3 minutes
- Published through
- Astana Hub
- Topic
- Systems and Implementation
- Series
- The system around the product
About this edition. Originally published in Russian on Astana Hub. This English site edition is adapted for an international product and governance audience.
Product history looks backward: how did this system come into being? A data map asks what happens now when a person presses a button, contacts support or connects a new service.
From the outside, a journey may look like one screen and one action. Inside the organisation, it quickly branches across product infrastructure, email, support, vendors, logs, exports, screenshots and working habits.
Begin with an event, not a data inventory
The question "what data do we have?" often produces a list such as name, email, telephone number and technical information. The list is useful, but it does not show what the company does with the data.
Choose one event instead: registration, support, payment, recruitment, analytics or the activation of an AI feature. An event gives the map a boundary and lets the team follow a real route from beginning to end.
This is a first pass, not the complete corporate record. Once the method works on one meaningful route, it can expand.
Walk the route through the eyes of the data
Take a support request. What can the user enter? Where does the form go? Does it create a ticket, send an email copy or appear in a task tracker? Can an employee forward it to a developer or paste part of it into an AI assistant?
Then ask who has access, which external providers participate, where the infrastructure sits, what remains in logs and backups and what happens when the request closes.
One small process may cross the interface, support, engineering, cloud infrastructure, vendor agreements and team habits. The map should show that whole route.
Show the copies, not only the systems
Architectural diagrams usually show primary systems and integrations. Data also remains in places the diagram did not intend:
- email notifications and task comments;
- exports, screenshots and local files;
- event logs and backups;
- contractor chats and support threads;
- AI prompt histories, memories and generated outputs.
Not every copy is a breach. An invisible copy cannot be deliberately protected, restricted, retained or deleted.
Record decisions beside the route
For each route, make the following visible: purpose, people affected, data used, basis or instruction, systems and recipients, access, location, retention trigger, protection, evidence, owner and open questions.
Empty cells are expected in the first version. An honest "not established" is more useful than a precise-looking answer no one verified.
Before a new process launches, however, the questions about purpose, authority, transfer and protection need to become decisions.
Give the route an owner and the map a curator
The process owner sees operational change first. A data-governance, privacy or other appointed curator keeps the method consistent and connects changes across processes. Neither role can replace the other.
Update the map when a feature, field, vendor, AI tool, access role, retention rule or incident changes the route. A map becomes operational when people know which events send them back to it.
Start with one table, one event and two people who see the route from different sides. If their answers differ, the map has already done useful work.