NIST Privacy Framework Data Map: How to Build One (ID.IM-P8)

A NIST Privacy Framework data map illustrates the data actions a system performs, the data elements they act on, the components involved, the roles of every party in the ecosystem, and the individuals affected. It is the artefact every later step depends on.

The framework asks for it in ID.IM-P8, and the ordering is deliberate: you cannot assess privacy risk for processing you have not yet described. Programmes that skip straight to a risk register end up assessing what people believe the organisation does.

What this guide covers

• What a NIST Privacy Framework data map has to show
• The five things a NIST Privacy Framework data map must make visible
• Inferred data belongs on the map
• Logs and backups belong on the NIST Privacy Framework data map
• How much detail a NIST Privacy Framework data map needs
• Building a NIST Privacy Framework data map
• Keeping a NIST Privacy Framework data map current
• Who has to be in the room
• Reviewing a completed NIST Privacy Framework data map
• What the NIST Privacy Framework data map makes possible
• Frequently asked questions
• Templates for the map

What a NIST Privacy Framework data map has to show

Not a four-box diagram of “customers → application → database → reports”. Every interesting question lives inside those boxes. A usable map records, per system:

• Each data action — collection, retention, logging, generation, transformation, use, disclosure, transfer, sharing, disposal
• The data elements each action touches
• The purpose of each action
• The components performing it
• Every ecosystem party and its role in that action
• The categories of individuals whose data is involved
• Every boundary crossing, with the receiving party named
• Every store the data reaches

The five things a NIST Privacy Framework data map must make visible

1. Every point where data leaves your control. Including infrastructure providers whose staff can technically read it, whatever the contract says about intent.
2. Every action whose purpose differs from the collection purpose. This is where purpose drift becomes visible, and it is the single most valuable output of mapping.
3. Every action that generates data rather than collecting it — scores, segments, predictions, flags.
4. Every retention point, including logs, backups, caches, search indexes, warehouse extracts and machine-learning training sets.
5. Everyone who can read it, including support staff and analysts acting entirely within their duties.

Points 3 and 4 are the ones most often missing, and they are the two that cause the most trouble later.

Inferred data belongs on the map

A system that produces a churn score, a fraud rating or a propensity segment has created new data about an identifiable person. It collected nothing. It has still performed a data action, and frequently the highest-risk one in the estate — because the person never provided the attribute, does not know it exists, and it may be wrong.

If your NIST Privacy Framework data map only traces data inward from collection points, it will show none of this. Trace what the system produces as well as what it receives.

Logs and backups belong on the NIST Privacy Framework data map

Logs, backups, caches, warehouse extracts and training sets are all retention points holding data about individuals. They are omitted from maps more often than anything else, usually because logs are classified as a security control rather than as a data store.

This omission has a direct and expensive consequence. A deletion request can only reach stores the map records. An organisation that deletes from the primary database and leaves the record in the warehouse extract, the search index and the log archive has not deleted anything — it has moved it. The map is what makes those copies findable.

How much detail a NIST Privacy Framework data map needs

Map to the level at which a problematic data action becomes visible, then stop. There is a failure at each extreme.

A practical test: if two data actions in the same box have different purposes, different retention or different recipients, separate them. If they do not, leave them together. That rule produces a map fine enough to assess and coarse enough to maintain.

Building a NIST Privacy Framework data map

1. List the data actions the system performs, using the life-cycle categories.
2. For each, record the data elements it acts on.
3. Record the purpose of each action.
4. Identify the components performing each action.
5. Identify every ecosystem party and its role.
6. Identify the categories of individuals involved.
7. Mark every boundary crossing.
8. Review with the system owner and an architect, then approve.

Step 8 matters more than it looks. A map produced by the privacy function alone records what the documentation says the system does. An architect will tell you about the integration that was added last year and never written down.

Keeping a NIST Privacy Framework data map current

A NIST Privacy Framework data map is updated before a change goes live, not after. Attach it to your change process as a release condition — the alternative is a map that describes last quarter’s system and a risk register built on it.

Review every map at least annually even where the system has not changed, because the ecosystem around it may have: a supplier’s sub-processor list moves, a processing location changes, a partner starts combining your data with something new.

Detecting drift is worth doing deliberately. Compare the elements actually held against the catalogue, the actual recipients against the disclosure register, and recent releases against your change-gate records. Each comparison finds a different kind of divergence.

Who has to be in the room

Mapping fails as a desk exercise. The information needed sits with different people, and none of them holds all of it.

The data engineer is the one most often left out and the one most likely to name a store nobody else remembers. Extracts and derived tables are created to answer a question, then kept, and they rarely appear on an architecture diagram.

Expect a first mapping session to run to a couple of hours per significant system, and expect the second half of it to be more productive than the first — the useful disclosures tend to arrive once people stop describing the design and start describing what actually happens.

Reviewing a completed NIST Privacy Framework data map

Run this before the NIST Privacy Framework data map is used for anything. A map that fails the retention or generation row will produce a risk assessment with a predictable hole in it.

What the NIST Privacy Framework data map makes possible

Once it exists, several things become possible that were not before: identifying problematic data actions per action rather than per system; fulfilling access and deletion requests across every store; answering “where did you get this?” for any element; and building an honest Current Profile, since most Identify-P and Control-P outcomes are assessed against it.

For the framework as a whole see our NIST Privacy Framework guide. The framework is free at nist.gov/privacy-framework.

Frequently asked questions

Is a data map the same as a record of processing?

Related but not identical. A GDPR Article 30 record is a compliance artefact listing processing activities, purposes, categories and recipients. A NIST Privacy Framework data map is an analytical artefact showing data actions at a granularity that supports risk assessment — including inferred data and every store. The Article 30 record can be produced as a view of the map; the reverse does not work.

Do we need a map for every system?

For every system that performs a data action on data about people, yes — but the depth should scale with risk. A system holding sensitive attributes about a dependent population warrants element-level detail. An internal tool with a handful of employee records does not.

Can we automate it?

Discovery tooling helps with stores and flows, which is the part that ages fastest. It cannot supply purpose, and purpose is what makes the map useful — a tool can tell you data moved from A to B but not why, nor whether that reason still holds. Expect a hybrid: automated discovery reconciled against human-recorded purpose.

Where do most maps go wrong?

Two places. Omitting stores that are not thought of as stores — logs, caches, backups, warehouse extracts — and omitting data the system generates rather than collects. Both omissions are invisible until a deletion request or a risk assessment depends on them.

Templates for the map

Our NIST Privacy Framework Toolkit is 145 editable Word and Excel templates covering all 102 Subcategories of Privacy Framework 1.1. It includes the data mapping procedure and map template, plus separate registers for data actions, purposes, elements, processing environments and the individuals affected — the inputs a NIST Privacy Framework data map is assembled from.