A field-level data inventory can reveal unnecessary collection

A field-level inventory can reveal a privacy problem that a system-level inventory misses. “Customer relationship management” tells you where information lives. It does not explain why a newsletter form asks for a full date of birth or why an order note contains a family member’s medical details.

Review the fields where the information first enters the workflow. The goal is to identify what the task needs, what could be collected more narrowly and what the organisation cannot currently justify.

Ask what decision each field supports

For every field, ask: who uses this value, for which action, and what would fail if it were absent? A specific answer is more useful than “analytics” or “future personalisation”.

Consider a hypothetical community bookstore’s event-registration form. A name may help manage attendance. An email address may support event updates. A home address might have no role if the event is online and no physical item is being sent.

Do not remove a field merely because it appears sensitive. First understand the task and applicable requirements. Equally, do not keep it merely because someone might find it useful later.

NIST IR 8062 encourages designers to examine exposure that is not essential to system operation. That provides a useful engineering question: can the authorised task be completed with less information or less identifying information?

Distinguish necessary detail from convenient detail

If the bookstore needs to know whether a participant can attend an evening session, it may not need an unrestricted description of their daily routine. If it needs an accessibility accommodation, a focused question may be more appropriate than a broad request for medical history.

The right design depends on the service and the person’s needs. Avoid forcing a narrow multiple-choice field when it would prevent someone from explaining an essential requirement. The review should preserve useful access to the service while limiting unrelated collection.

Document alternatives. Could an age band answer the actual planning question? Could a delivery region replace a full address for an early availability check? Could the system compute a result and discard an intermediate value after applying the approved policy?

These are design options to evaluate, not declarations that aggregation automatically produces anonymous data.

Inspect free text separately

A field labelled “notes” can contain almost anything. It may include useful delivery directions, copied identity numbers, passwords or details about another person. A column inventory that lists only the label will understate that variability.

Review authorised samples through a controlled process, or use synthetic examples to test likely patterns. Define what staff should put in the field and what should go elsewhere through a more appropriate route.

Automated detection can assist this review, but it has limits. Presidio’s documentation explicitly warns that automated recognition cannot guarantee that all sensitive information will be found. A clean scan therefore does not settle whether the field is appropriately designed.

Try changing the collection prompt before adding another scanning layer. A specific question can reduce unnecessary disclosure at the point where it would otherwise enter every downstream copy.

Trace the field beyond collection

Removing a field from a screen is only part of the change. Check imports, APIs, mobile forms, staff templates and integrations that may continue supplying it. Then identify reports and downstream processes that depend on it.

In the bookstore example, an address field removed from registration might still arrive through an older spreadsheet upload. An old export template may also preserve the column even when new rows leave it blank.

Plan the transition deliberately. Decide what happens to existing values under the approved retention and processing policy. Update the documentation and tell the operating teams why the field changed. Do not silently break a legitimate workflow and encourage staff to recreate the missing information in a notes column.

Make the decision reviewable

A useful field register records the purpose, user, source, required detail, recipient and retention decision. Add the proposed change and its owner.

Use this decision sequence:

• Identify the action enabled by the field.
• Check whether that action remains part of the service.
• Test a narrower or less identifying alternative.
• Review effects on accessibility and legitimate operations.
• Trace imports, exports and integrations using the field.
• Agree how existing values will be handled.
• Verify that the removed collection has not moved elsewhere.

After the change, inspect a complete synthetic record through the workflow. Confirm that the service still works and that the unnecessary field no longer appears in the expected outputs.

A good inventory review produces a reasoned collection decision. It should help a future colleague understand why a field exists, why its detail is limited and what would justify changing it.