GDPR data mapping: what to map, what Article 30 requires and how to reuse it
GDPR data mapping is how you find out where personal data comes from, where it goes and who touches it on the way. See what the regulation actually requires, a field-by-field template, and how one data map feeds eight GDPR duties.
Ask a DPO what slows down an access request, a breach assessment or a supplier review, and the answer is usually the same. Nobody knows exactly where the data is. The HR system is known, the CRM is known, but the shared drive with old recruitment files, the payroll bureau's subprocessor in another country and the marketing tool someone signed up for last spring are not.
GDPR data mapping closes that gap. This article explains what the regulation actually requires, sorts out the terms that get mixed up, walks through a field-by-field template and shows with a worked example how one data map serves eight obligations. Every legal reference points to an article of Regulation (EU) 2016/679 or to guidance from the European Data Protection Board (EDPB).
The short answer: what is GDPR data mapping?
GDPR data mapping is the work of identifying which personal data your organisation processes, why, about whom, in which systems, with which recipients and for how long. The regulation never uses the words "data map". What it requires is the record of processing activities in Article 30, plus the ability to demonstrate compliance under the accountability principle in Article 5(2). In practice you cannot produce either without mapping your data first.
A good data map is built once, around processing activities rather than systems, and then reused for privacy notices, access requests, processor agreements, security, breach handling, DPIAs and international transfers. A map that only serves the Article 30 record delivers a fraction of its value.
Five terms that often get mixed up
Searches for GDPR data mapping mix several things that belong to different categories. Some are legal duties, some are working methods and some are technologies. Sorting them first makes the rest of the article easier to follow.
| Term | What it is | Required by GDPR? |
|---|---|---|
| Record of processing activities (RoPA) | The written record of processing activities, with the fields listed in Article 30(1) for controllers and Article 30(2) for processors | Yes, Article 30, unless the Article 30(5) derogation applies |
| Data map | The working documentation behind the RoPA: activities linked to systems, data categories, recipients, legal bases and retention | Not by name. It is how you meet Articles 5(2), 24 and 30 in practice |
| Data inventory | A list of systems, databases and files that hold personal data, usually owned by IT | No, but it is a useful input to the data map |
| Data flow diagram | A visual of how data moves between systems, teams and external parties | No. Helpful for DPIAs and transfer assessments |
| Data discovery | Technical scanning that finds personal data in systems and file shares | No. A technique that can feed the inventory, not a substitute for the record |
A scanner can tell you that a file share contains national insurance numbers. It cannot tell you why the organisation holds them, on which legal basis or for how long. That is a business question, and it is the part of data discovery that always needs a human answer.
What GDPR actually requires
Article 30: the record of processing activities
Article 30(1) requires each controller, and where applicable its representative, to maintain a record of processing activities under its responsibility. The record must contain:
- (a) the name and contact details of the controller, any joint controller, the representative and the data protection officer
- (b) the purposes of the processing
- (c) a description of the categories of data subjects and of the categories of personal data
- (d) the categories of recipients, including recipients in third countries or international organisations
- (e) transfers to a third country or international organisation, including its identification and, for transfers under the second subparagraph of Article 49(1), documentation of suitable safeguards
- (f) where possible, the envisaged time limits for erasure of the different categories of data
- (g) where possible, a general description of the technical and organisational security measures referred to in Article 32(1)
Processors have their own, shorter record under Article 30(2): the processor's details and those of each controller it acts for, the categories of processing carried out on behalf of each controller, third-country transfers and, where possible, a description of security measures. The record must be in writing, which includes electronic form (Article 30(3)), and must be made available to the supervisory authority on request (Article 30(4)). You can read the full text on EUR-Lex.
Two details catch many organisations out. The duty sits with the controller, not with the DPO. The DPO advises and monitors, but the organisation owns the record. And the legal basis for each activity is not one of the Article 30(1) fields, even though almost every serious data map includes it. You need it anyway for the privacy notice (Article 13(1)(c)) and to show compliance with Article 6, so it belongs in the map. Our guide to the record of processing activities goes deeper on the record itself.
Accountability and the rest of the regulation
Article 5 sets out seven principles, and the seventh, accountability in Article 5(2), requires the controller to be able to demonstrate compliance with the other six. Article 24 adds the duty to implement appropriate measures and be able to show that processing complies. Neither mentions data mapping, but both assume you know what you process. Without a map you cannot show data minimisation (Article 5(1)(c)) or storage limitation (Article 5(1)(e)).
Data protection by design and by default is a separate duty in Article 25, not part of Article 5, and both elements are mandatory. A current data map is what lets you check new systems against it before they go live. See our article on privacy by design and by default for how that works in practice.
The Article 30(5) derogation and the proposal to widen it
Article 30(5) exempts enterprises and organisations with fewer than 250 employees from keeping a record. The exemption falls away if the processing is likely to result in a risk to the rights and freedoms of data subjects, if the processing is not occasional, or if it includes special categories of data (Article 9(1)) or data on criminal convictions and offences (Article 10). The Article 29 Working Party's position paper on the Article 30(5) derogations, endorsed by the EDPB, explains that a smaller organisation only has to record the processing that is not occasional, such as payroll and HR. In practice almost every employer has some.
On 21 May 2025 the European Commission proposed, as part of its fourth simplification omnibus, to raise the threshold to fewer than 750 employees and to keep the exemption unless the processing is likely to result in a high risk within the meaning of Article 35. In their joint opinion of 9 July 2025 the EDPB and EDPS welcomed the simplification but asked why 750 rather than 500, and asked that public bodies stay outside the exemption. At the time of writing the amendment is still going through the legislative process, so Article 30(5) applies in its current form. Check EUR-Lex for the adopted text before relying on the new threshold.
What to capture: a GDPR data mapping template, field by field
The most common mistake in a data mapping GDPR template is to start with systems. A system list tells you what software you run. The regulation asks about processing activities: recruitment, payroll, customer support, newsletter, CCTV. One activity often spans several systems, and one system often supports several activities. Start with the activity and link the systems to it.
The table below is the column set we recommend. The first group mirrors Article 30(1). The second group is not required by Article 30 but is what makes the map reusable.
| Field | Legal source | Example (recruitment) |
|---|---|---|
| Processing activity and owner | Art. 30(1), structure | Recruitment of staff, owned by Head of HR |
| Purpose | Art. 30(1)(b) | Assess and select applicants for vacancies |
| Categories of data subjects | Art. 30(1)(c) | Applicants, referees |
| Categories of personal data | Art. 30(1)(c), flag Art. 9 and 10 data | CV, contact details, interview notes, test results. Health data only if disclosed for adjustments |
| Recipients | Art. 30(1)(d) | Hiring managers, recruitment platform (processor), testing provider (processor) |
| Third-country transfers and transfer tool | Art. 30(1)(e), Arts. 44 to 49 | Testing provider hosts in the US, certified under the EU-US Data Privacy Framework |
| Retention period | Art. 30(1)(f) | Six months after the position is filled, unless the applicant agrees to longer |
| Security measures | Art. 30(1)(g), Art. 32(1) | Role-based access, MFA, link to the security policy |
| Legal basis | Art. 6(1), Art. 9(2), Art. 13(1)(c) | Art. 6(1)(b), steps prior to entering a contract |
| Systems and storage locations | Art. 15, Art. 32, Art. 33 | Recruitment platform, HR mailbox, shared interview folder |
| Source of the data | Art. 14(2)(f), Art. 15(1)(g) | The applicant, referees, public professional profiles |
| Processor agreement in place | Art. 28(3) | Yes for both processors, reviewed March 2026 |
| Risk flags | Art. 35(1) and (3) | Automated test scoring, consider DPIA screening |
Keep fields short and structured, because free text cannot be filtered. Record categories, not individual data points. And give every activity a named owner in the business, since the business knows when the process changes.
If you are starting from a spreadsheet, the supervisory authorities publish usable starting points. The UK Information Commissioner's Office offers documentation templates for controllers and processors, which follow the same Article 30 structure retained in the UK GDPR. We also keep a set of GDPR templates you can adapt.
One data map, eight GDPR obligations
This is where GDPR data mapping earns its keep, and it is the part most guides skip. The same fields answer questions that arrive from very different directions. The table shows which fields each obligation draws on.
| Obligation | Article | Fields it reuses from the map |
|---|---|---|
| Record of processing activities | Art. 30 | All Article 30(1) or 30(2) fields |
| Privacy notices | Arts. 13 and 14 | Purpose, legal basis, recipients, transfers, retention, source |
| Access and other data subject rights | Arts. 15 to 22 | Systems, data categories, recipients, retention, source |
| Processor agreements | Art. 28 | Recipients marked as processors, agreement status |
| Security of processing | Art. 32 | Systems, data categories, special category flags, measures |
| Breach assessment and notification | Arts. 33 and 34 | Systems, data subjects affected, data categories, processors involved |
| DPIA screening | Art. 35 | Risk flags, special categories, scale, new technology |
| International transfers | Arts. 44 to 49 | Recipient country, transfer tool, transfer impact assessment status |
Take a breach as an example. Article 33(1) requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk. Article 34 requires communication to the data subjects without undue delay when the breach is likely to result in a high risk. Both assessments depend on knowing, within hours, which activities used the compromised system, which data categories it held and how many people are affected. With a current map that is a filter. Without one it is an investigation. Our article on handling a security breach covers the process after that first question.
Access requests work the same way. Article 15 gives the data subject the right to know the purposes, categories, recipients, retention period and source of their data, and to receive a copy. Those are the map's fields, row for row. The data subject access request guide explains the one-month deadline in Article 12(3) and when it can be extended.
International transfers need particular care
The transfer field is where old data maps are most often wrong. Transfers to a country covered by an adequacy decision under Article 45 need no further transfer tool. That currently includes the United Kingdom, whose adequacy decisions the Commission renewed in December 2025 until 2031, and US organisations certified under the EU-US Data Privacy Framework, adopted on 10 July 2023 and upheld by the General Court in Latombe v Commission (T-553/23) on 3 September 2025. An appeal to the Court of Justice has been lodged, so keep an eye on it. The Commission keeps the current list of adequacy decisions.
Where there is no adequacy decision and you rely on an Article 46 tool such as standard contractual clauses, the Schrems II judgment (C-311/18) and the EDPB's Recommendations 01/2020 on supplementary measures require you to assess whether the law and practice of the destination country undermine the safeguards. That assessment is usually called a transfer impact assessment. It is tied to Article 46 tools, not to every transfer outside the EEA. Your map should record which tool applies to each recipient so you know where an assessment is needed. More in our article on third-country transfers.
How to carry out GDPR data mapping in seven steps
This order works well in organisations with 50 to 1,000 employees. It keeps legal questions with the people who can answer them and technical questions with IT.
1. Set scope and ownership
Decide which legal entities are in scope (each controller keeps its own record) and who owns the map. In most organisations the DPO or privacy lead coordinates, while each department head owns the activities in their area. Write that down, because the map will decay the moment ownership is unclear.
2. List processing activities by department
Go department by department: HR, finance, sales, marketing, customer service, IT, facilities. Ask what the team does with personal data, not which systems it uses. Start from a template list and delete what does not apply, which is faster than starting from a blank page.
3. Link systems and storage locations
For each activity, record where the data lives. Include the unglamorous places: shared mailboxes, file shares, local spreadsheets and paper archives. This is where IT's system inventory, and if you have it a data discovery scan, adds real value.
4. Record recipients and classify them
List everyone the data is disclosed to and classify each one as processor, independent controller, joint controller or public authority. Only processors need an agreement under Article 28(3). An external auditor or a bank receiving salary payments is usually an independent controller, not a processor. See our guide to the data processing agreement for the classification test.
5. Add legal basis, retention and transfers
This is the legal layer. Pick one of the six legal bases in Article 6(1) for each purpose, and an Article 9(2) condition where special categories are involved. Consent is only one of the six and often the wrong one in an employment context. Set a retention period or the criteria used to determine it, and record the transfer tool for any recipient outside the EEA. Our article on legal bases for non-sensitive personal data helps with the choice.
6. Flag risks and gaps
Mark activities that involve special categories, large-scale monitoring, profiling or new technology for DPIA screening under Article 35. Mark missing processor agreements, missing retention periods and transfers without a documented tool. These flags become your action list.
7. Generate the record and schedule reviews
Produce the Article 30 record from the map rather than maintaining it as a separate document. Then schedule reviews: a light annual check of every activity, and an event-driven update whenever a new system, supplier or purpose is introduced. The event-driven update is the one that keeps the map true.
A worked example: one supplier change, three questions answered
Northmoor Logistics BV and Anna de Vries are fictional. We created them for this article, and they are not customers or a case study.
Northmoor Logistics is a Dutch freight forwarder with 420 employees across three EU countries. Anna de Vries is its privacy lead and part-time DPO. In spring 2026 she finished the company's first structured data map: 46 processing activities, 58 systems and storage locations, 27 processors and 6 recipients outside the EEA.
In June, HR proposes replacing its payroll bureau with a new provider that uses a support subprocessor in India. Before the data map existed, Anna would have spent a week emailing HR, IT and procurement. This time she filters the map by the payroll system and gets three answers in an afternoon.
- Which activities are affected? Four: payroll, pension administration, sickness absence administration and expense reimbursement. Sickness absence involves health data, so Article 9 applies and the security bar is higher.
- What has to change on paper? A new Article 28 agreement with the provider, including its subprocessor list. Four rows in the Article 30 record. The employee privacy notice, because recipients and transfers change under Article 13(1)(e) and (f).
- Is a transfer assessment needed? Yes. India has no adequacy decision, so the provider's standard contractual clauses under Article 46(2)(c) apply, and Recommendations 01/2020 require an assessment of whether supplementary measures are needed.
The map did not make the legal decisions for her. It told her which decisions she had to make, and it did so before the contract was signed rather than after. The screening also showed that sickness absence data was being stored in a shared HR folder with broader access than needed, a finding she added to the security action list under Article 32.
A data map rarely pays off on the day it is finished. It pays off the first time something changes.
Spreadsheet or data mapping software?
Both can meet Article 30. The regulation only asks for a record in writing, including electronic form. The difference shows up in maintenance, reuse and collaboration, and it grows with the number of activities and people involved.
| Aspect | Spreadsheet | Data mapping software |
|---|---|---|
| Cost to start | Low, you already have it | Licence, although free entry tiers exist |
| Structure | One flat sheet, systems and recipients repeated in every row | Activities, systems and recipients linked once and reused |
| Collaboration | Version conflicts, unclear who changed what | Delegated ownership per activity, change history |
| Article 30 record | The sheet is the record, maintained by hand | Generated from the map for controller and processor |
| Group companies | One copy per entity, drifts apart quickly | Shared activities with a separate record per entity |
| Reuse for other duties | Copy and paste into notices, DPIAs and supplier reviews | Same data feeds vendor reviews, risk and tasks |
| Best fit | Under about 20 activities and one owner | Several departments, entities or frequent changes |
A spreadsheet is a legitimate choice for a small organisation with a handful of stable activities. Once several people maintain the map, it usually becomes the reason the map is out of date. We compare the two routes in more depth in GDPR in Excel or software.
What a data map does not do
A data map describes processing. It does not make processing lawful. Choosing the right legal basis, balancing a legitimate interest or deciding on a retention period are legal judgements that the map records but cannot replace.
A data map is also a snapshot of what people tell you. It will miss the processing nobody mentions, which is why technical data discovery and a periodic check against the IT system list are worth doing. And a map is not a security measure. Knowing that a file share holds health data is the start of protecting it, not the protection itself.
Finally, the map is about personal data as the regulation defines it in Article 4(1). The Court of Justice's judgment of 4 September 2025 in EDPS v SRB (C-413/23 P) confirmed that pseudonymised data may not be personal data for a recipient that has no reasonable means of re-identifying the individuals, while it remains personal data for the controller that holds the key. The EDPB's Guidelines 01/2025 on pseudonymisation explain the practice. For the data map this means you record pseudonymised data sets as personal data on your side, and note the recipient's position separately rather than dropping the row.
How .legal supports GDPR data mapping
Our data mapping tool is built around processing activities. You register whom you process data about, what data, why, on which basis and how long you keep it, and link the systems and recipients involved. Templates developed with the law firm Bech-Bruun cover common activities in HR, finance and operations, so you start by editing rather than writing from scratch.
Data sharing is registered through a sharing flow, where each recipient is classified, and the platform alerts you to things that need attention, for example a processor in a third country without adequacy. When the map is maintained, the Article 30(1) and Article 30(2) records are generated from it and can be exported to Excel. Group companies can share activities while each entity keeps its own record.
Because the map lives in the same GDPR compliance platform as vendor management and compliance task management, the processors you register are the same ones you audit, and the annual review becomes a recurring task with an owner. The platform does not decide your legal bases or retention periods for you. It keeps the answers in one place and tells you where answers are missing.
You can get started free, or book a demo to see a data map generate a record of processing activities.
.legal compliance platform
Automate your GDPR data mapping today
-
Automated processing activity records (ROPA)
-
Visual data flow mapping across systems
-
Streamlined data subject request handling
-
Built-in vendor and third-party management
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=68&height=52&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png)
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=493&height=57&name=KAUFMANN%20(1).jpg)
