3 MIN READ
Data minimization has been a GDPR requirement since 2018. The rule is straightforward: collect only the personal data the purpose needs, keep it only as long as the purpose requires, and only let the people whose role requires it see it. Most organisations have done almost nothing about it in the eight years since, because enforcement was patchy and interpretation was generous. The 2026 environment is changing that calculation. The EU AI Act, DORA, and the wave of US state level privacy laws are turning a soft obligation into a hard one, and the legal teams that treated GDPR as a European problem are now hearing from their US colleagues. Here is what actual data minimization looks like when an organisation does it.
What data minimization actually means
It starts with collection. What personal data does the organisation actually gather, and for what purpose? The honest answer usually takes a working afternoon to assemble, because most data stores were built up over years without anyone asking. The question is worth asking at the design phase of a new system, before the database schema gets locked in. The audit phase of an old one is more painful and rarely changes much, because the cost of ripping out a field that has been in production for a decade is much higher than the cost of not putting it in.
How long should the data be kept, and is the retention window justified by the purpose? A marketing lead is not a regulatory record. A support ticket is not a financial transaction. The data the role does not need should not be kept past the role’s window, and the window should be written down so the privacy office can show it to a regulator without a long pause to look it up.
Access is the third question, and the one that lands most often. Who inside the company can see the personal data, and does the role actually require it? Support sees what support needs. Marketing does not see the support team’s records. The IAM configuration enforces the boundary; the HR policy sits alongside, but the IAM is what actually decides, and the IAM is what the auditor is going to ask to see a screenshot of.
What it looks like in practice
The work starts with a data inventory. The company has to know what data it holds before it can do anything else. The discovery tools (Collibra, OneTrust, BigID, the open source alternatives) scan the data stores and produce a catalog: the data type, the location, the volume, the retention period, the access pattern. Without this catalog, the rest of the work is guesswork, and the regulator is going to be the one pointing that out.
Retention enforcement comes second. The data stores get configured with the retention window. The data older than the window gets deleted. The deletion runs on a schedule. The schedule gets audited. The work is mechanical, which is probably why most organisations never get around to it, and which is exactly why the regulator is willing to fine them for not having done it.
Access review closes the loop. The IAM policies get tightened. The role permissions get re evaluated. The data outside the role’s scope stays outside the user’s reach. The review runs quarterly, and the review is documented, so the privacy office can hand the regulator a packet of evidence rather than a screenshot of a Jira ticket.
What the company gets out of it
The regulatory benefit lands first. The organisation that has done the work has the documented evidence to show the regulator when the regulator asks. The fine is lower. The disclosure obligation is smaller. The investigation closes faster, often without a public statement, which is what the legal team actually wanted from the start.
Security is the less obvious one, and probably the bigger one. Data the company does not hold, the attacker cannot steal. A breach of a data store that holds less data is a smaller breach, with a smaller notification list, a smaller bill from the incident response firm, and a smaller hit to the brand. Most of the cost of a breach scales with the volume of data the attacker walks away with, and the simplest way to make the breach smaller is to hold less data in the first place.
Cost is the third benefit, and the one the finance team will care about most. The data store that holds less data costs less to store, less to back up, less to scan for sensitive content, less to monitor. The work typically pays for itself in storage and tooling costs within 12 to 18 months on most enterprise data sets, before any of the breach savings get added.
The bottom line
Data minimization has been on the GDPR books since 2018, and the 2026 enforcement environment is turning the soft obligation into a hard one. Build the inventory, enforce the retention, tighten the access. The regulatory benefit, the security benefit, and the cost benefit all land together when the work is done, and the work is what the regulator is going to ask for first when the next investigation opens.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
