Collect only the data necessary to deliver the function
Aliases: collection limitation · necessity principle · data minimisation
What it is
Data minimization limits processing to information that is necessary, relevant, and proportionate for a defined function. “Potentially useful later” is not necessity: a team should be able to show why the function fails, or becomes materially riskier or costlier, without the datum. Minimization concerns not only field count but precision, sampling rate, population coverage, and linkability.
Why it happens
Each additional dimension creates more routes for breach, insider misuse, mistaken inference, and cross-purpose linkage. Collection also creates institutional gravity: available data invite secondary analysis and propagate into logs, warehouses, and models. Constraints applied before generation shrink the attack surface and governance burden directly. Access controls applied later can limit readers, but cannot remove the risk created by the data's existence.
Studying it
A task–data matrix can test dependencies between functional steps and fields, while ablation studies compare task performance after removing inputs, coarsening precision, or moving computation on-device. Measures include functional utility, error, transfer volume, identifiable-record proportion, and affected population. Evaluations should cover failure and recovery paths and should not misclassify analytics convenience, hypothetical model improvement, or an unspecified anti-fraud interest as a user-function requirement.
Where it stops holding
Minimization is not a universal field-count threshold, nor does it prohibit all security telemetry. Fraud prevention, auditability, and emergency services can justify additional signals when tied to a concrete threat and periodically reviewed. Collapsing sensitive inputs into a score may reduce exposure while making inference less visible. Removing names alone does not establish anonymity when external datasets permit linkage.
Applying it
- Build a data-input inventory for every function and justify field, precision, frequency, and upload scope separately.
- Test non-collection, local computation, ephemeral tokens, bucketed values, and user-supplied inputs before requesting richer data.
- Separate optional analytics from the core service so declining them does not break the primary task.
- Run ablations with fields disabled and sampling reduced; when key-task quality does not materially decline, remove the datum from collection protocols, logs, and schemas.