Data minimization documentation

Description

Data minimization is the GDPR Article 5(1)(c) principle that has propagated into LGPD, CPRA, the Quebec Law 25 framework, and the contemporary read of FTC Section 5 unfairness: collect only what is necessary for the stated purpose, and keep it only as long as that purpose is live. The principle reads as a single sentence in the statute and translates into a non-trivial operational program because the necessity case has to be made per data category against the stated processing purpose, and the case has to survive a regulator's counterfactual test rather than a self-serving justification. Operationalizing the principle requires per-data-category documentation. For each field collected (each form field, each event property, each identifier, each derived attribute), three pieces of analysis have to land: why the data is needed for the stated purpose, what would happen if it were not collected (the counterfactual is the regulator's preferred test and the part that distinguishes a real necessity case from a "we wanted it for future flexibility" rationalization), and what the lawful basis for the collection is under the applicable regime. The trade-off pressure is structural: product teams want maximum collection because data they have today is data they can act on tomorrow, but the minimization principle reads necessity as a today test rather than a future-optionality test. Minimization is read against a moving target: regulators evaluate necessity against current state-of-the-art, so a field that was justifiable when the product launched may stop being justifiable as alternative architectures (privacy-preserving analytics, on-device processing, differential-privacy aggregation, federated learning, edge computing) become standard practice. Annual review of the minimization documentation against the current architecture tends to be the operative cadence; programs that file the document once at launch and never revisit it are the recurring pattern in enforcement actions, and the gap between the documented necessity case and the architecturally-available alternatives is what regulators interrogate. The statutory anchors layer multiple regimes onto the same data field. GDPR Article 5(1)(c) sets the minimization principle and Article 25 sets the privacy-by-design requirement that operationalizes minimization at the architecture level rather than at the operational-policy level. LGPD Article 6 § III sets the necessity principle for Brazil. UK GDPR carries the GDPR minimization principle into the UK. PIPEDA (S.C. 2000, c. 5) sets the limiting-collection principle for Canada. The California AADC at Cal. Civ. Code §§1798.99.28-1798.99.40 layers stricter child-specific minimization expectations on top of CCPA. Maryland MODPA at Md. Code Ann., Com. Law §§14-4601 to 14-4616 sets one of the strictest US-state minimization standards, with the statute requiring data collection to be limited to what is reasonably necessary to provide the service. PIPA Korea (Act No. 10465 as amended through Act No. 19234) sets the parallel Korean obligation. Singapore PDPA imposes the equivalent through the consent and purpose-limitation obligations. Evidence formats that satisfy a regulator inquiry include the data inventory itself, the purpose-by-field mapping documenting necessity per field, and the design-review notes capturing the architectural counterfactual analysis.

Required by (8 regulations)

• CA AADC

  Cal. Civ. Code §§1798.99.28-1798.99.40 (AB 2273, 2022)

• GDPR

  Article 5(1)(c) — data minimization principle; Article 25 — privacy by design.

  Regulation (EU) 2016/679 of the European Parliament and of the Council

• LGPD

  Article 6 § III — necessity principle.

  Lei nº 13.709, de 14 de agosto de 2018 (as amended by Lei nº 13.853/2019 and Emenda Constitucional nº 115/2022)

• MODPA

  Md. Code Ann., Com. Law §§14-4601 to 14-4616

• PIPA

  Personal Information Protection Act (Act No. 10465, enacted March 29, 2011; last wholly amended by Act No. 19234, effective September 15, 2023)

• PIPEDA

  S.C. 2000, c. 5 (Personal Information Protection and Electronic Documents Act)

• Singapore PDPA
• Washington MHMDA

  Documents that collection is limited to what is necessary — the threshold above which separate MHMDA consent is required.

  Washington My Health My Data Act (HB 1155, 2023)

  Source →

Fulfilled by (4)

• In-house build · medium effort
• onetrust · partial · medium effort · $$
• bigid · partial · medium effort · $$$
  Data discovery + classification for minimization assessment.
• securiti · partial · medium effort · $$$
  Privacy-ops platform with data-minimization workflows.

Magist does not accept payment from vendors. Methodology.

Evidence formats

• data inventory
• purpose-by-field mapping
• design-review notes