Limiting data to what is necessary for the purpose; GDPR Art. 5(1)(c) anchor.
In advertising and audience-measurement practice, data minimization means running campaigns and analytics on the least identifying signal that still supports the commercial decision: contextual placement instead of individual behavioural profiles; cohort, clean-room, or panel-based reporting instead of user-level logs; and short retention windows for raw event streams. Agencies and publishers operationalize it as a design choice made at briefing time — deciding which measurement questions genuinely require person-level tracking — because collecting identifiable audience data triggers consent obligations under GDPR and ePrivacy rules, platform-policy exposure, and audience-trust costs that aggregate measurement avoids.
In practice: Decide at campaign design which measurement questions genuinely require person-level data, and default to contextual, panel, or aggregate alternatives wherever they answer the brief.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
For bank privacy and compliance functions, data minimization is a purpose-limitation control implemented through data inventories, retention schedules, and access tiers: each stored customer attribute must trace to a documented processing purpose and lawful basis, and be deleted when the purpose lapses. The control operates in permanent tension with anti-money-laundering and record-keeping mandates that require holding extensive customer data for years, so minimization work in practice consists of arbitrating between deletion duties and retention duties, purpose by purpose, and documenting that arbitration in a form defensible to both data-protection and financial supervisors.
In practice: Trace each stored customer attribute to a lawful purpose and retention period, and resolve conflicts between deletion duties and AML retention mandates in documented, supervisor-defensible form.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
For credit-model developers, data minimization is an empirical property of the final model rather than an ex-ante constraint on exploration: candidate features are assembled in a controlled development environment, their marginal predictive contribution is measured, and features that do not demonstrably improve performance — or that add instability, explainability burden, or discrimination risk — are pruned before deployment. On this reading a variable is 'necessary' when ablation shows the model materially degrades without it, and the minimized feature set is evidence produced by the development process, not an input to it.
In practice: Measure each candidate feature's marginal contribution through ablation, document why every retained feature is necessary, and prune variables whose predictive value does not justify their privacy cost.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
In hospital data-protection practice, data minimization is the requirement that each clinical or research processing purpose be mapped to the narrowest set of patient variables that can fulfil it, with special-category health data under GDPR Article 9 demanding the strictest cut. It is operationalized through data-protection impact assessments and ethics submissions that must justify every requested field; a collection form holding 'possibly useful later' items fails review. Necessity is judged against the declared purpose, not against the open-ended value of richer records for future research, and unjustifiable fields are stripped or aggregated before collection begins.
In practice: Justify every patient-level variable in a collection instrument against a documented purpose, and strip or aggregate fields whose necessity cannot be demonstrated before collection starts.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
In administrative case handling, data minimization is a legality requirement applied before any collection: an authority may demand from citizens only the data items for which the statute governing the specific task provides a basis, and forms, registers, and inter-agency queries are reviewed field-by-field against that basis. Because authorities can rarely fall back on consent given the imbalance of power over applicants, the statutory basis carries the whole weight: if the task can be met without an item, the item is unlawful to collect regardless of its plausible future usefulness, and reuse for another task requires its own legal basis, not an appeal to administrative efficiency.
In practice: Verify a statutory basis for every field on a form or register query before collection begins, and refuse items the governing task does not strictly require.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
The communities disagree about when and how 'necessary' is established. Administrative lawyers, hospital data-protection officers, and ethics boards treat necessity as an ex-ante legal test that must be satisfied before any collection occurs: an item without a demonstrable basis is unlawful to gather, whatever its potential utility. Model developers treat necessity as an empirical property demonstrated during development: candidate data is explored under controls, and the minimized feature set is the output of ablation and pruning rather than a precondition of exploration.