What Is Data Minimization?

What does Article 5(1)(c) actually require?

Three words carry the weight.

Adequate. Enough to achieve the purpose. Under-collecting to the point where you cannot do the job is also a failure.

Relevant. Connected to the purpose. A field collected because it might be useful someday is not relevant to any stated purpose.

Limited to what is necessary. The strictest of the three. If the purpose can be achieved without the field, the field should not be there.

All three are relative to a purpose. That is the part that makes minimization hard: you cannot answer "is this necessary" without first answering "necessary for what".

Why does this stall in most organisations?

Because the purpose was never written down per field.

A mature Salesforce org has hundreds of custom fields. Some were added for a campaign that ended in 2019. Some were added by an integration that has since been decommissioned. Some duplicate a standard field. Almost none carry a documented purpose.

Faced with "minimize your data", a team looks at that field list, cannot determine which are necessary, and does nothing. The principle is clear and the work is impossible without an inventory.

That is why minimization projects almost always start with discovery rather than deletion. You need to know which objects and fields hold personal data, and what each one is for, before the test can be applied at all.

How does minimization differ from storage limitation?

They are adjacent principles that solve different halves of the problem.

Minimization applies at the point of collection and continuously afterwards. Storage limitation applies over time and is what retention policies operationalise.

A field can pass minimization at collection and fail storage limitation two years later, when the purpose has been fulfilled and there is no longer a reason to keep it in identifiable form.

What does minimization look like in practice?

Four moves, in rough order of return.

Stop collecting what you do not use. Audit your web-to-lead forms and integrations. Every field on a form is a collection decision, and forms accumulate fields the way orgs accumulate custom objects.

Inventory what you already hold. Which objects and fields contain personal data, including the long-text fields, attachments and abandoned custom objects where it hides. Personal Data Discovery scans standard and custom objects to produce this.

Apply a purpose and a retention period per category. Not just "seven years" but "seven years, SOX §802". The justification is what makes the decision defensible later.

De-identify rather than delete where a record must persist. This is the move that is consistently under-used. Retention obligations usually attach to the transaction record; minimization obligations attach to the identifiable person. Removing the identifying fields while keeping the record satisfies both at once.

Does minimization conflict with retention obligations?

It appears to, and the conflict mostly dissolves once you separate the record from the person.

SOX may require you to keep a financial record for seven years. GDPR requires you not to keep personal data in identifiable form longer than necessary. Both can be true. Keep the transaction, strip the identifiers, and document which regime drove each decision.

Where a genuine conflict remains, a legal obligation to retain generally provides the lawful basis to keep the data. What it does not provide is a reason to keep everything else attached to it.

What does this mean in Salesforce?

Three capabilities, and they are the same three that most privacy work in a CRM reduces to.

Find it. Personal data hides in `Notes__c` long-text fields, attachments, description fields written by integrations, and custom objects nobody remembers commissioning. Personal Data Discovery produces the inventory that makes minimization answerable.

Enforce it on a schedule. A retention policy that nothing executes is not a control. Data Retention Manager applies policy-based deletion and de-identification across standard and custom objects, cascade-aware so deleting a parent does not orphan its children.

Evidence it. Under Article 5(2) you must be able to demonstrate compliance, not merely achieve it. The deliverable is a record of what was assessed, what was removed, when and under which policy.

One limit worth stating plainly: a discovery scan finds candidates, not answers. It can tell you a field holds something that looks like a national insurance number. It cannot tell you whether that field is necessary for a purpose, because only the people running the process know what the purpose is. The inventory makes the question answerable. Somebody still has to answer it.