11.2 Data Minimization & Retention

Every piece of personal data an organisation holds is a liability as well as an asset. Data that serves no current purpose still sits in databases, attracts attackers, exposes the organisation to regulatory scrutiny, and costs money to store and secure. The principles of data minimisation and storage limitation exist to cut this liability at its root.

GDPR Art. 5(1)(c) — Data minimisation

GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." In plain terms: collect only what you actually need for the stated purpose. If your organisation runs a newsletter, you need email addresses. You do not need users' dates of birth, phone numbers, or browsing history — so you should not collect them.

The principle sounds obvious, but it runs against the instincts of many data teams, who tend to collect now and decide later what is useful. That "collect everything" mindset is exactly what Art. 5(1)(c) is designed to correct.

GDPR Art. 5(1)(e) — Storage limitation

Article 5(1)(e) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Once the purpose is fulfilled, the personal data must be deleted, anonymised, or at minimum de-identified.

Practical implementation: four steps

1. Define a retention schedule. For every category of data you hold, document how long you need it and why. A purchase transaction may need to be kept seven to ten years for tax and accounting purposes. The customer's personal email address may only be needed until they unsubscribe. These are different answers to different questions.

2. Automate deletion. Manual deletion is unreliable. Build deletion into your systems: scheduled jobs that purge records when their retention period expires, automated anonymisation when full personal data is no longer needed, and audit logs that record what was deleted and when.

3. De-identify or anonymise when possible. If you need aggregate data for analytics — for example, the total number of purchases in a region — strip personal identifiers and keep only the aggregate. Do not retain personal data when anonymised data serves the same purpose.

4. Review and enforce your schedule. A retention schedule filed and forgotten is not compliance. Assign ownership, review annually, and verify that automated systems are functioning correctly.

A concrete example

Consider a subscription service. The user's email address is needed while they are subscribed. When they cancel, it may be retained briefly for re-engagement — but if no legitimate purpose remains, it should be deleted. Tax records (purchase amounts, dates, payment confirmations) may need to be kept for up to ten years in many jurisdictions. But those records can be de-identified of the user's personal contact information once the subscription has lapsed.

The cost of over-retention

Keeping data longer than necessary creates two compounding problems. First, it enlarges the breach surface: more data means more exposure if attackers gain access. Second, it creates regulatory exposure. Supervisory authorities regularly fine organisations not for breaches alone, but for the volume of unnecessarily retained data exposed in those breaches — because over-retention itself violates Art. 5(1)(e).

Your takeaway

Data minimisation and storage limitation are not just legal obligations — they are good operational practice. Holding less data for shorter periods protects your organisation and the individuals whose information you process.