GDPR Data Mapping Diagram: How to Map Personal Data Flows Across Your Systems

Ask a privacy team where personal data lives and you get a spreadsheet. Ask engineering and you get an architecture diagram that never mentions personal data. Both are incomplete: the spreadsheet cannot show how data moves, and the architecture diagram does not say what moves or why.

A GDPR data mapping diagram is where the two meet. This guide covers what a data map must capture, a method for building one, and a worked map for a typical SaaS product. It is not legal advice; your privacy lead or counsel decides lawful bases, transfer mechanisms and retention.

Data map and record of processing

Article 30 of the GDPR requires each controller to keep a record of processing activities containing:

• the name and contact details of the controller and, where applicable, its representative and data protection officer;
• the purposes of the processing;
• the categories of data subjects and of personal data;
• the categories of recipients, including recipients in third countries;
• transfers to third countries and, for some, the documentation of safeguards;
• where possible, time limits for erasure;
• where possible, a general description of the security measures.

Processors keep a similar record of the processing they do for each controller. Article 30(5) exempts organizations with fewer than 250 employees, but only if the processing is unlikely to result in a risk to people's rights, is occasional, and includes no special categories of data or criminal records data. A SaaS company that processes customer data every day rarely qualifies. EU lawmakers have debated raising that threshold, so check the current text before relying on it.

The record is a table. The data map is how you find out what goes into the table, and how you check later that it is still true.

What to capture for each flow

A method that works

1. Inventory the systems. Start from what you can list: cloud accounts, databases, SaaS tools from single sign-on and from the finance team's vendor payments. Shadow tools show up there.
2. Follow one user journey at a time. Sign-up, billing, daily product use, a support ticket, a marketing email. Draw where the data enters, where it is stored and where it goes next.
3. Ask the owners. For each system: which fields, for what, who receives them, and how long they stay.
4. Mark processors and transfers. Note where each vendor processes data, whether a data processing agreement is in place, and which safeguard covers any transfer outside the EEA.
5. Add retention and deletion. A store without a retention period is a finding.
6. Review with the privacy team and derive the Article 30 record from the map.

Transfers outside the EEA

Chapter V of the GDPR, Articles 44 to 49, allows transfers to third countries only on certain grounds. The common ones for a SaaS company:

• An adequacy decision. The European Commission lists the countries whose protection it considers adequate. For the United States, the decision of July 2023 covers companies that participate in the EU-US Data Privacy Framework (DPF). The EU General Court upheld it in September 2025, and an appeal was lodged with the Court of Justice in October 2025, so check its status before you rely on it.
• Standard contractual clauses. The Commission's 2021 SCCs are the usual contract-based safeguard when no adequacy decision applies.
• Other safeguards and derogations, such as binding corporate rules or explicit consent, for narrower cases.

On the map, a transfer is an edge that leaves your region, labeled with the destination and the safeguard.

The worked example: a B2B SaaS product

The product runs in an EU cloud region: a web app, a PostgreSQL database and an analytics warehouse. Five vendors receive personal data: email delivery and payments in the EEA, and product analytics, a support desk and a CRM in the United States.

How to read it:

• Entry. Customer users create accounts, pay, use the product and write to support. Every flow from the web app is labeled with the categories of data it carries.
• Our systems, EU region. The app database holds account and workspace data. The warehouse receives usage events with pseudonymous IDs, not names.
• Processors in the EEA. Email delivery gets names, email addresses and message content; payments get billing contacts and invoices. No transfer is involved.
• Processors in the US. Each edge into this frame is a transfer and carries its safeguard: DPF for vendors certified under the framework, SCCs for the one that is not.
• The legend explains the labels and lists example retention periods per store.

Drawing conventions that help

• Label edges with data categories, not technologies. "Name, email, ticket content" helps a reviewer; "REST API" does not.
• Draw a boundary around your own systems, and put processors outside it, grouped by region.
• Mark every transfer with the destination and the safeguard.
• Highlight special category data with one consistent color, and say in the legend what it means.
• Write retention on each store. It is the item most often missing from records of processing.
• Keep purposes and lawful bases in the record, next to the diagram. The diagram shows where; the record states why.

Keep it current

A data map is out of date the day someone adds a vendor. Tie updates to the events that change it: vendor onboarding, new features that collect new data, and data protection impact assessments. Under Article 35, a controller must assess processing that is likely to result in a high risk before it starts, and the map is the natural starting point for that assessment. Review the whole map once a year and keep the previous version. Architecture diagrams that don't rot describes a workflow for exactly this, and embedding the live diagram in the privacy wiki keeps everyone on the same version.

How the map helps with data subject requests

An access or erasure request has to cover every place a person's data lives: the app database, the warehouse, backups, and every processor. With a current map, answering is a checklist rather than a search. Processors are contractually bound to help with these requests, and the map tells you which ones to ask.

For a security view of the same flows, see data flow diagrams for threat modeling.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a C4 Model Person for the customer user.
3. Add a Core Frame for your systems in the EU region, with a C4 Model Container for the web app, a Data pack Postgres for the app database and a Data pack Data Warehouse for analytics.
4. Add two more Core Frame nodes for processors, one for the EEA and one for the US, with a C4 Model External System node for each vendor role.
5. Label every edge with the data categories it carries, and add the safeguard on each edge into the US frame.
6. Add a Core Markdown block with the legend and retention periods.

The example uses 13 diagram nodes, within the Free plan. The GDPR data mapping use case shows more ways to lay out a map.

FAQ

Is a data map required by the GDPR? The GDPR requires the record of processing activities in Article 30, not a diagram. Most teams find they cannot build or maintain an accurate record without mapping the flows first.

Who should own the data map? Privacy owns the record and the decisions in it; engineering owns the systems. Give the diagram one owner on each side and review it together.

Should the map show individual database tables? No. Show stores and the categories of data in them. Table-level detail belongs in a data catalog.

How do I show a vendor that is both a processor and a controller? Draw it once and label its role per flow. Some providers, such as payment providers, act as controllers for parts of their processing; their contracts say which.

Can the diagram replace the Article 30 record? No. The record must contain specific information in writing, including purposes and security measures. Use the diagram to build and check the record.

Start free — one seat, no credit card.