A controller instructs a processor to collect forty optional fields ‘for future unknown projects’ with no current necessity. What principle does that instruction primarily conflict with?
Select an answer to reveal the explanation.
Short Explanation
‘Grab forty extra fields in case we invent a project later’ is a shopping spree, not data protection. Minimisation wants the shopping list tied to today’s purpose. Unknown future projects are not a blank cheque for speculative collection.
Full Explanation
Data minimisation requires that personal data be adequate, relevant, and limited to what is necessary for specified purposes. Instructing a processor to collect forty optional fields “for future unknown projects” with no current necessity primarily conflicts with minimisation: speculative collection for undefined future projects is the opposite of purpose-bound limitation.
Integrity and confidentiality do not require collecting every possible field by default; collecting less often reduces risk. Storage limitation concerns how long data are kept and is not the lead principle for speculative field design, nor does it apply only after fifty years. Transparency does not forbid processors from ever receiving personal data; it requires clear information when they do.
Exam caveat: “collect now for unknown later” fails minimisation and purpose limitation together. Operational check: specify current purposes, collect only needed fields, require change control before new fields, and delete unused speculative attributes. Municipal data programmes should resist inventory-building instincts, recording why vacuuming optional fields for hypothetical projects was rejected as disrespectful to residents.