Data retention vs minimization: keeping history without excess personal data

What is the difference between retention and minimization?#

Data retention sets how long a company keeps a record; data minimization limits the personal data in that record to what its purpose needs. Retention is a clock and minimization is a filter, and a sound records policy uses both.

The confusion comes from treating deletion as the only privacy tool. Deleting a whole support history removes the personal data, but it also removes the product knowledge, fixes and outcomes the company may need for operations, disputes or analysis. Minimization offers a middle path that keeps the history and sheds the excess.

Why the two seem to pull in opposite directions#

Retention and minimization seem to conflict because different parts of the company want different things. Operations and finance want long history, privacy rules that may apply ask companies not to keep personal data longer or in more detail than needed, and litigation holds and tax rules can require keeping specific records.

Tax shows the keep side clearly. Rev. Proc. 98-25 treats machine-sensible records in a company's accounting systems as records that must be retained while their contents may become material to tax administration, at a minimum until the limitation period for assessment expires. A retention schedule has to honor obligations like this before minimization trims anything.

This is general information, not legal advice. Which privacy and records laws apply depends on where the company and the people in its records are, and it is assessed with counsel.

The working rule: keep the event, reduce the person#

The working rule is to keep the business event and remove or reduce the personal detail. Applied record family by record family, it preserves what happened and why while shrinking what is known about who.

Techniques that reduce personal detail#

Several techniques reduce personal detail, and they are not equal. Choose by how much identifiability must go and what analysis the business still needs to run.

Pseudonymization alone does not end the obligation. GDPR Recital 26 says pseudonymised data that could be attributed to a person with additional information should be treated as information on an identifiable person, while anonymous information falls outside data protection principles.

US definitions add process. Under Cal. Civ. Code 1798.140(m), as amended by the CPRA, deidentified information cannot reasonably be linked to a particular consumer, and the business must take reasonable measures, publicly commit not to reidentify it and contractually require recipients to follow the same rules.

• 1Deletion of fields with no remaining purpose, such as phone numbers on long-closed tickets.
• 2Redaction of names and identifiers inside free text, including transcripts and email bodies.
• 3Generalization, such as replacing a street address with a city or region.
• 4Pseudonymization, replacing names with consistent codes so related records stay linked.
• 5Aggregation, keeping counts and patterns instead of individual rows.
• 6De-identification, combining these steps with governance so records cannot reasonably be linked back to a person.

Check the retention settings in your tools#

Retention settings in business tools often delete permanently, so read them before changing anything and export what you need first. The settings below show how differently vendors handle it.

Questions that turn the rule into a schedule#

A short set of questions turns the keep-the-event rule into a written schedule. Ask them for each record family, record the answers, and revisit them whenever a system, a contract or a law changes.

The answers usually split a record into two parts with different clocks: the event fields, kept for as long as the business or the law needs them, and the personal fields, reduced or deleted much sooner.

• 1What business purpose does this record serve, and for how long?
• 2Which legal, tax or contract obligations require keeping it, and which fields do they cover?
• 3Which personal fields does the purpose actually need?
• 4Can the record keep its value with names replaced by codes or details generalized?
• 5Is any of it under a legal hold that overrides the schedule?
• 6Who approves deletions, and how is each change logged?

Illustrative: a staffing firm keeps placement history without keeping candidates#

Illustrative: a fictional IT staffing firm has many years of requisitions, submittals and placements in its ATS. Its privacy lead wants to stop holding contact details for candidates who were never placed, while sales leadership wants to keep the history of which roles were filled, how quickly and with what skills.

The firm keeps each requisition, the stages candidates moved through and the outcome. It replaces candidate names with codes, keeps the key in a separate restricted table, and deletes contact details and resumes for unplaced candidates once the agreed period ends. Interview feedback is kept as skill themes rather than verbatim notes about individuals.

The outcome: the firm can still analyze time to fill and skill demand by client industry, and its privacy exposure is lower. Because the codes stay personal data while the key exists, counsel sets a date to destroy the key for older records, which moves them closer to deidentified.

How SourceX applies minimization#

SourceX applies minimization in the Preparation step of the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery). Personal and confidential details are removed before anything leaves the company, and the company approves the prepared result.

In the SourceX Enterprise Data Value Framework, privacy burden reduces net value and human-generated signal raises value, so records that already follow the keep-the-event rule tend to need less preparation. The privacy record in the SourceX Evidence Packet documents what was removed or reduced, and how.