THE FOUNDRA TAKE

Data minimisation is easier when every field has a purpose, an owner and a clear end to its useful life.

Map the information before the feature

List what the product receives, where it goes and which components can access it. Distinguish information needed to complete the task from data collected because it might become useful later. A hypothetical document assistant may need the file being processed but not every document in the customer’s account. That distinction should influence the integration and the user’s explanation of the feature.

Include copies and logs

The main database is only one part of the picture. Uploaded files, cached results, debugging logs and provider requests can create additional copies. Decide which are necessary and how long they remain useful. Avoid recording sensitive content in a general diagnostic log when a reference identifier or a narrower event record would be sufficient to investigate the problem.

FOUNDRA EXPLAINS

A purposeful data lifecycle

01

Purpose

Explain why the information is needed.

02

Flow

Identify systems and copies.

03

Retention

Set an appropriate useful lifetime.

04

Removal

Test the actual deletion process.

Foundra analysis: an explanatory decision framework, not measured company results.

Design deletion as an operation

A deletion request should have a defined path through the relevant systems, including derived records where applicable. State any practical boundaries clearly rather than promising an action the architecture cannot perform. Test the process with non-sensitive sample data. A product team learns more by tracing a real deletion through its components than by adding a broad sentence to a policy page.

NOIRLab HQ Server Racks (6V6A0402-CC)
NOIRLab HQ Server Racks (6V6A0402-CC) · NOIRLab/NSF/AURA/T. Slovinský · CC BY 4.0 · Context image

Review when the product changes

New integrations and features can expand the information flow without making that expansion obvious to existing users. Revisit the map during design reviews and assign ownership for each new use. The purpose is to keep the product’s data practices aligned with its actual service. Less unnecessary data can also mean less storage, less operational complexity and fewer places to investigate when something goes wrong.

Sources

  1. NIST Privacy Framework — source and reference material ↗ NIST Privacy Framework · Primary source

Have additional information? Request a correction.