How the tools discover personal data, how they classify it, and why the discovery method decides everything downstream.
Personal data mapping software builds and maintains a picture of what personal data your organisation holds, where it lives, where it moves and who receives it. The discovery method is the decision that matters: questionnaire-based mapping records what people remember, scanning production data finds what exists today but says nothing about intent, and deriving the map from source code and infrastructure captures the system as built and updates when it changes. Everything downstream — the Article 30 register, DPIA scoping, transfer records, retention enforcement — inherits the accuracy of the map, so evaluate discovery before you evaluate features.
Questionnaires are cheap and immediately out of date. Scanning production databases finds real data but requires access to it and cannot explain purpose. Deriving from source code and infrastructure describes the system as engineers built it and updates on the same cadence as releases. Most tools do one well; know which one you are buying.
A proprietary taxonomy locks your annotations into one vendor. An open standard means the same description of personal data can be reused across regimes and survives a change of tooling. Ask what happens to your classifications if you leave.
A list of systems holding personal data is not a map. You need to see where data moves — between services, to subprocessors, across borders — because that is what transfer assessments and Article 30 recipient fields depend on.
Hosting region, subprocessor location and onward transfer are the fields most likely to be wrong and most likely to be asked about. Check whether the tool derives them from infrastructure or asks a human to assert them.
The value of a data map is what it makes possible. Check that it actually populates the Article 30 register, scopes DPIAs and drives retention rather than existing as a separate diagram that has to be reconciled by hand.
Four shapes of vendor, described by category rather than by name. Which one fits depends on how fast your systems change and how much judgement you need to buy in.
Large, modular GRC platforms that cover most regimes through separately licensed modules, usually with a long implementation and a dedicated administrator.
Best fit: Large organisations with a compliance team big enough to own configuration, and budget that tolerates a multi-module licence.
Focused products that do one job well — consent, DSAR intake, cookie scanning, vendor questionnaires — and integrate loosely with whatever else you run.
Best fit: Teams with one acute, well-bounded problem, who accept that the register tying everything together lives somewhere else.
People rather than software: an external DPO or advisory retainer that produces the documentation on your behalf, often in documents you then own.
Best fit: Organisations without in-house expertise who need judgement more than tooling, and who can accept that the output is a snapshot.
Systems that connect to what you already run, derive the records from live signals, and keep them current between audits rather than regenerating them before one.
Best fit: Teams whose systems change faster than documents can be maintained by hand, and who need to evidence a current state on demand.
Noru builds the map from source code and infrastructure: personal data is annotated where it is defined, classified against an open privacy taxonomy, and pushed from CI so the map changes when the system does.
Because the vocabulary is an open standard rather than a proprietary schema, the same annotations serve GDPR, CCPA and other regimes without being re-derived per law.
The map is not a deliverable in itself — it populates the Article 30 register, scopes assessments, and surfaces transfers and subprocessors as governed facts rather than fields someone has to remember to update.
Identifying and documenting what personal data an organisation holds, where it is stored, how it flows between systems and third parties, and where it goes across borders. It is the factual foundation the GDPR's documentation obligations are built on.
Not by name. What is required is the Article 30 record, DPIAs where risk is high, transparency about recipients and transfers, and the ability to honour data subject rights. All of them presuppose that you know what data you hold, which is what a data map is.
Discovery finds where personal data exists. Mapping adds the context that makes it useful — purpose, lawful basis, recipients, retention and transfers. Discovery alone tells you that a column holds email addresses; mapping tells you why, for whom and for how long.
As often as the systems change. In a business shipping continuously, a quarterly refresh means the map is wrong for most of the quarter. That is the argument for deriving it from code rather than re-surveying teams.
The structural layer can be — systems, fields, flows, vendors and hosting regions are all observable. Purpose and lawful basis are human judgements about intent, which no scanner can infer, and should be reviewed and attributed rather than generated.
Regulatory references on this page were last checked on .
A 45-minute walkthrough against your frameworks, your integrations and your evidence.
