If you cannot answer the above questions, you cannot write an accurate privacy notice, answer an access request on time, or tell a regulator what a breach exposed. Data mapping is how you answer them, once, in a form you can keep up to date.
What a data map is
A data map records, for each part of the organisation, the personal data it handles and the facts around it:
- whose data it is (employees, job applicants, customers, suppliers)
- why it is used (the purpose)
- the legal basis for each purpose
- what data is involved, including any special category data such as health information
- where it is stored
- which suppliers process it and who else receives it
- where it came from
A data map is not an IT inventory. Systems change every few years. Purposes rarely do. A useful map is organised around the business: HR uses job applicants’ CVs to recruit, Finance uses supplier contact details to pay invoices, Sales uses prospect details to follow up enquiries.
Why privacy laws expect one
Few privacy laws use the words “data map”. Most of their obligations assume you have one.
Records of processing. Article 30 of the GDPR, and the same article of the UK GDPR, requires a written record of processing activities: purposes, categories of people and data, recipients, transfers outside the country, retention periods and security measures. There is a limited exemption for organisations under 250 employees, but it does not apply to processing that is more than occasional.
Payroll and HR processing are not occasional, so in practice nearly every employer needs the record. Brazil’s LGPD (Article 37) and South Africa’s POPIA (section 17) set similar documentation duties.
Legal basis. Every purpose needs a legal basis (GDPR Article 6). Special category data needs an additional condition (Article 9). You can only show this purpose by purpose, which is exactly how a data map is structured.
Transparency. Privacy notices must tell people what you collect, why, on what basis and who receives it (GDPR Articles 13 and 14, POPIA section 18, and the notice at collection under California’s CCPA). Where data comes from someone other than the individual, the GDPR also requires you to name the source. Your notice is only as accurate as the record behind it.
Rights requests. An access request normally has to be answered within one month. You cannot do that if you do not know which departments and systems hold the person’s data.
Breaches. Where a breach must be reported, the GDPR gives you 72 hours and asks for the categories and approximate number of people and records affected. The data map tells you what the affected system held and whose data it was.
Suppliers and transfers. Processors need contracts that meet Article 28, and transfers outside the EU need a valid mechanism. Both start with knowing which suppliers handle which data, and where they are based.
Risk assessments. A DPIA is required for high-risk processing. A good map makes that processing visible: special category data, large volumes, children’s data, new technology.
Accountability. The GDPR requires you to be able to demonstrate compliance, not just achieve it (Article 5(2)). A current, versioned data map is the core of that evidence.
Why most data maps fail
Most organisations have tried. The usual result is a spreadsheet that was accurate for one month.
- It was built for a project and never maintained.
- One person owned it, and that person has left.
- Cells say “various”, “IT systems” or “as required”, which no auditor will accept.
- It lists systems, not purposes, so legal bases are missing.
- Nobody can see the gaps until the auditor finds them.
How PrivIQ Data Mapping helps
PrivIQ Data Mapping is built around how a business actually works, and it shows you what is missing before anyone else does.
Start from what you have, or from a template. Import an existing map from Excel or JSON, or start from a sector template. The Mid-Size+ Trading template, for example, covers 14 departments, their typical groups of people and over 100 purposes, ready to switch on or off. You choose which departments to bring in, and nothing you do not need comes with them.
Department, people, purpose. For each department you confirm the groups of people it deals with, then the purposes for each group. Suggested purposes arrive with a suggested legal basis, which you confirm or change. You are describing your organisation, not filling in a legal form.
Detail where it belongs. Personal data types, special category data, storage locations, processors and sharing parties are recorded against each purpose, not lumped together at department level. Special category data cannot be left without a condition for processing.
Where the data comes from. For every data element you record the collection source and whether it came from the individual or from a third party, and which third party. That is the information Article 14 notices require, captured once.
Checks before you publish. The Review step lists every gap with its location: purposes without a legal basis, special category data without a condition, data with no recorded source, purposes with no storage location. You fix them or publish with a recorded warning.
Versions and full history. Every save creates a new version, and every version is kept. You can work on a draft while the published map stays in place, compare versions, go back to an earlier one, and show exactly what the map looked like on any date. That history is what proves your record was maintained, not written the week before an audit.
See it and share it. The visualisation shows the map by department, by group of people or by processor. The processor view lists every purpose a supplier touches, which is the starting point for contract reviews and vendor assessments. Excel and PDF exports give auditors, boards and colleagues the same view.
Why PrivIQ’s approach works better
Most organisations choose between two options. A spreadsheet is cheap and flexible, but it has no structure, no checks and no history. Questionnaire-based privacy tools add structure, but they send long forms to department heads who do not know what a lawful basis is, and the answers come back late, vague or not at all. PrivIQ takes a different route.
You edit a map, not a blank page. A sector template means most of the work is already done. Reviewing a suggested purpose and switching it on takes seconds. Writing it from scratch, with the right wording and the right legal basis, takes far longer and is done differently by every person who tries. Templates give you speed and consistency at the same time.
It asks business questions. HR knows who it hires and what it needs from them. It does not know Article 6. PrivIQ asks about departments, people and purposes, and does the translation into legal categories itself. The people who know the facts can supply them directly, and the privacy lead reviews rather than chases.
Precision by purpose. Many tools record suppliers and systems at department level, so every HR purpose appears to share data with every HR supplier. That overstates your exposure and makes your notices wrong. PrivIQ links each processor, sharing party and storage location to the specific purposes that use it, so the record says exactly what happens.
The gaps find you. In a spreadsheet, a missing legal basis is an empty cell nobody notices. In PrivIQ it is a named check that stays open until it is fixed, with the department and purpose next to it. You see the same list your auditor would produce, before the audit.
The map is checked against reality. A data map records where personal data should be. Through a specialist discovery partner, PrivIQ can also scan file shares, mailboxes, cloud storage and databases to find where it actually is.
Personal data turning up somewhere the map does not mention is a gap you can fix before it becomes a finding.
Your data stays yours. You can import a map from Excel or JSON and export it again in a standard format, complete and unchanged. Bring in only the departments you want. Move a map between entities or clients. Nothing is locked inside the platform.
One map, many laws. The map is built in neutral terms and applied to the framework you need: GDPR, UK GDPR, POPIA, LGPD, CCPA and more. A group operating in several countries maintains one record, not one per law.
It is connected, not standalone. A data map on its own is a document. In PrivIQ it is the source for ROPA, privacy notices, DPIAs, access requests, breach response and supplier oversight, all in the same platform. Change it once and the records that depend on it follow.
| SPREADSHEET | QUESTIONNAIRE TOOLS | PRIVIQ | |
|---|---|---|---|
| Starting point | Blank sheet | Long forms sent out | Sector template or your existing map |
| Who can complete it | The privacy lead | Respondents, slowly | Anyone who knows the department |
| Suppliers and systems | Free text | Often department-wide | Linked to each purpose |
| Gaps | Invisible | Unanswered questions | Named checks before publishing |
| History | File copies | Varies | Every version kept, full history |
| Moving your data | Easy, but unstructured | Often limited | Full import and export |
| Rest of the programme | Copied by hand | Separate modules | Feeds ROPA, notices, DPIAs and more |
Access requests and breaches: where a data map pays for itself
Ask any privacy team what costs them the most time and the answer is usually the same: data subject access requests. Breaches are rarer, but they are the moment an organisation finds out whether it really knows its data. Both run against a deadline, and both depend on the data map.
Why DSARs hurt
Requests are rising every year. Under the GDPR you normally have one month to respond, usually free of charge. A complete response is more than a copy of the data. Article 15 also requires the purposes, the categories of data, the recipients, the retention period and, where the data was not collected from the person, its source.
Without a data map, the process tends to look like this:
A. An email goes to every department asking “do you hold anything on this person?”
B. Some reply, some do not, and nobody is sure the list of systems is complete.
C. Suppliers holding the data are forgotten.
D. The explanatory part of the response is written from scratch, every time.
E. The deadline approaches, and a late or incomplete answer becomes a complaint to the regulator.
Erasure and objection requests add to the work. You have to tell recipients when data is erased, and you have to know which rights apply at all: the right to object depends on the legal basis, and portability only applies to data processed on consent or contract.
How PrivIQ Data Mapping helps with DSARs
Start from the person, not the department. Because the map is organised by group of people, you can view it from the requester’s side. A request from a former employee or a customer shows straight away every department and purpose that handles that group, the data involved, where it is stored and which suppliers process it. That is your search list, complete, on day one.
The explanation is already written. Purposes, categories of data, recipients and sources are recorded for that group of people. The Article 15 information that usually takes hours to assemble is already in the map.
Suppliers are not forgotten. Every processor and sharing party is linked to the purposes that use it, so you know exactly which ones to contact, and which recipients to notify after an erasure.
You know which rights apply. The legal basis is recorded for each purpose, so you can see where an objection or a portability request applies and where it does not, without a legal review for every request.
Find every copy, not just the expected ones. The map tells you where to look. Automated discovery, available through PrivIQ’s specialist partner, then searches file shares, mailboxes, cloud storage and databases for the requester’s data, including copies saved outside the systems you mapped: the spreadsheet on a shared drive, the CV attached to an old email. The search that used to take days of manual work takes hours, and the response is complete.
Same platform, same record. PrivIQ’s DSAR workflow runs alongside the map, from intake to resolution, so the team works from one source rather than a spreadsheet and an inbox.
Why breaches hurt
When a breach must be reported under the GDPR, the regulator expects notice within 72 hours of you becoming aware of it. The notice must describe the categories and approximate number of people and records affected, the likely consequences and what you are doing about it. If the risk to people is high, you must tell them too. Other laws, such as POPIA, require notice as soon as reasonably possible.
The first hours are usually spent answering basic questions. What did that system hold? Whose data was it? Was any of it health or other special category data? Which other processes use the same system? Many breaches start at a supplier, and the supplier’s first message rarely tells you which of your processes are affected.
How PrivIQ Data Mapping helps with breaches
From system or supplier to impact, in minutes. The processor view lists every department, group of people and purpose that a supplier touches. Storage locations are linked the same way. When a supplier or system is compromised, you see the scope immediately instead of reconstructing it.
Real numbers, not estimates. The map shows which processes and groups of people are in scope. Automated discovery, through PrivIQ’s specialist partner, then scans the affected files, mailboxes or systems to identify exactly which individuals and which types of data were exposed. The notice gives the regulator accurate figures, and you have the list of people you may need to contact.
Risk is visible. Special category data is recorded against each purpose with its condition, so you can tell quickly whether the breach is likely to be high risk and whether individuals need to be told.
The right regulators. Departments and suppliers carry their countries, so a group operating in several jurisdictions can see where notification may be needed.
Evidence of what you knew, and when. Version history shows what the map recorded on the day of the breach. That supports the notice, the internal investigation and any later questions from the regulator. PrivIQ’s breach response workflow then records the incident, the assessment and the communications in the same platform.
The map feeds the rest of the programme
In PrivIQ the data map is the source record. The rest of the privacy programme draws on it rather than repeating it:
- ROPA: the record of processing comes from the same structured data.
- Privacy notices: purposes, legal bases, recipients and sources are already recorded.
- DPIAs: high-risk processing is identifiable from the map.
- Access requests: you know which departments and systems to search.
- Breach response: you know what an affected system held and whose data it was.
- Third-party risk: you know which suppliers handle which data, and in which country.
Update the map when the business changes, and every record that depends on it stays accurate.
Where to start
Pick one department that handles a lot of personal data, usually HR. Map its groups of people and purposes, fix what the review flags, and publish the first version. Then move to the next department. A complete, current map built this way takes weeks, not a year, and it stays useful because it reflects how the organisation really works.
Tai Chesselet – Co-Founder and Chief Technology Officer, PrivIQ