You Reap What You Retain
The incident-response team has contained the compromised account. Leadership has been notified, legal is assessing reporting obligations, and investigators are trying to determine what the attacker reached.
Then the scope begins to grow.
The affected environment contains not only current customer records, but years of outdated information, forgotten exports, old backups, test copies, and duplicate data spread across several systems. The attacker entered through one weakness, but the organization’s earlier data decisions turned that access into a much larger incident.
Many of the consequences of a cyber incident are determined long before the incident itself. They are shaped by decisions about what data the organization collects, where it copies that data, who can access it, and how long it remains stored after its original purpose has disappeared.
An organization may respond quickly, escalate correctly, communicate clearly, and still face a much larger crisis than necessary because attackers reached years of obsolete records, forgotten exports, unrestricted backups, or duplicated data spread across multiple systems.
This is where data minimization becomes part of cyber resilience. It does not replace access controls, monitoring, incident response, or recovery planning. Instead, it changes what is at stake when those controls fail. The less unnecessary data an organization holds, the less there is to steal, encrypt, expose, investigate, notify, recover, and explain.
The Data You Keep Becomes the Risk You Carry
Organizations spend heavily on protecting data while continuing to collect, copy, and retain information they no longer need. Every additional record must be classified, protected, backed up, governed, monitored, and eventually deleted. If attackers gain access, that same record may also need to be investigated, reported, recovered, and explained to customers, regulators, and leadership.
Data minimization means collecting, using, accessing, sharing, and retaining only the personal information necessary for a defined purpose. That definition matters because minimization is often reduced to retention and deletion. In reality, the decision begins much earlier. Organizations must ask whether a particular field needs to be collected, whether another system needs a copy, how long the information must remain identifiable, and who still needs access once the original process is complete.
Recent academic research shows that data minimization is implemented through concrete decisions about what information a system is allowed to access, how much it collects, what it transmits, where it stores that information and how long it retains it. These decisions are made in system design and code, not only in retention policies. When systems request unnecessary permissions, retrieve more fields than they need or preserve data in logs and backups, they create additional paths through which sensitive information can be exposed.
Data minimization is therefore more than a legal obligation. It is an exposure-management decision.
You Cannot Lose Data You Never Collected
Cybersecurity strategies naturally focus on preventing attackers from entering. Those controls remain essential, but they do not answer another important question: what will attackers find if they get through?
A 2026 study of 9,875 Android applications found data-minimization-related signals in 76.44% of the applications analysed. These included unnecessary permissions, overly broad data retrieval, transmission of sensitive information, unrestricted backups, sensitive logging and weak retention practices. Although the study focuses on mobile applications, its findings demonstrate how routine technical decisions can create unnecessary exposure long before an incident occurs.
The difference becomes visible after a breach. An incident involving active customer records required for current operations is already serious. An incident involving those records plus ten years of out-of-use customer data, forgotten exports, old backups, test copies, and duplicates is something else entirely.
The attacker may have entered through the same weakness. The consequences are larger because the organization gave the attacker more to find. Data minimization does not prevent unauthorized access, but it can limit the damage once access occurs.
The Data You Keep Becomes the Risk You Carry
Organizations spend heavily on protecting data while continuing to collect, copy, and retain information they no longer need. Every additional record must be classified, protected, backed up, governed, monitored, and eventually deleted. If attackers gain access, that same record may also need to be investigated, reported, recovered, and explained to customers, regulators, and leadership.
Data minimization means collecting, using, accessing, sharing, and retaining only the personal information necessary for a defined purpose. That definition matters because minimization is often reduced to retention and deletion. In reality, the decision begins much earlier. Organizations must ask whether a particular field needs to be collected, whether another system needs a copy, how long the information must remain identifiable, and who still needs access once the original process is complete.
Recent academic research shows that data minimization is implemented through concrete decisions about what information a system is allowed to access, how much it collects, what it transmits, where it stores that information and how long it retains it. These decisions are made in system design and code, not only in retention policies. When systems request unnecessary permissions, retrieve more fields than they need or preserve data in logs and backups, they create additional paths through which sensitive information can be exposed.
Data minimization is therefore more than a legal obligation. It is an exposure-management decision.
You Cannot Lose Data You Never Collected
Cybersecurity strategies naturally focus on preventing attackers from entering. Those controls remain essential, but they do not answer another important question: what will attackers find if they get through?
A 2026 study of 9,875 Android applications found data-minimization-related signals in 76.44% of the applications analysed. These included unnecessary permissions, overly broad data retrieval, transmission of sensitive information, unrestricted backups, sensitive logging and weak retention practices. Although the study focuses on mobile applications, its findings demonstrate how routine technical decisions can create unnecessary exposure long before an incident occurs.
The difference becomes visible after a breach. An incident involving active customer records required for current operations is already serious. An incident involving those records plus ten years of out-of-use customer data, forgotten exports, old backups, test copies, and duplicates is something else entirely.
The attacker may have entered through the same weakness. The consequences are larger because the organization gave the attacker more to find. Data minimization does not prevent unauthorized access, but it can limit the damage once access occurs.
“Just in Case” Is Not a Policy
Organizations rarely make a formal decision to keep everything forever. Indefinite retention usually develops quietly. A department keeps an export in case someone needs it again. A legacy application continues storing records because deletion was never built into the workflow. A SaaS platform preserves inactive accounts by default. Backups accumulate without a clear expiry rule. Employees duplicate files across email, collaboration tools, personal folders, and shared drives.
Eventually, the organization no longer knows which copy is authoritative, which copy remains necessary, or who is responsible for deleting it.
These are not merely administrative weaknesses. They create security exposure.
A retention policy that exists only on paper does not change what a system stores. Retention limits must be translated into expiry rules, automated cleanup and deletion routines that apply to the actual locations in which information is kept.
The important question is not simply whether a retention policy exists, but whether the systems are designed to enforce it.
Data Minimization Starts Before Deletion
Deleting outdated records is important, but waiting until the end of the data lifecycle leaves much of the exposure untouched. A mature minimization programme considers the entire journey of the information. It does not eliminate every risk, but can reduce the value of exposed data to an attacker.
Collect less
Every data element should have a defined purpose. Registration forms, customer onboarding processes, internal applications, analytics tools, and AI workflows should not collect information merely because it might become useful later.
Copy less
Sensitive information often spreads far beyond the system in which it was originally collected. As it moves across teams, systems, and third-party environments, each additional copy becomes another location that must be discovered, classified, restricted, monitored, and eventually deleted. Minimization therefore requires controls over replication, not only over initial collection.
Expose less
Some information must be retained, but that does not mean everyone needs access to it.
Least privilege is part of data minimization because access itself is a form of exposure. Restricting access through role-based controls, just-in-time privileges, entitlement reviews, and nonhuman identity governance can reduce the number of pathways through which sensitive information may be misused or compromised.
Retain less
Retention periods should reflect legal obligations, operational requirements, and genuine business needs. They should also be technically enforceable.
Whenever possible, deletion should be triggered automatically by time, event, or status rather than depending on someone to remember to perform a manual cleanup.
Identify less
Sometimes the business needs the analytical value of data without needing the identity of every individual behind it. Aggregation, anonymization, pseudonymization, masking, and tokenization can allow organizations to keep information useful while making it less identifiable.
Scatter less
Information becomes harder to minimize when it is scattered across systems, repositories, backups, collaboration platforms, and unstructured files. Data discovery and classification must therefore be ongoing capabilities rather than one-time exercises. The organization must know where sensitive information exists, what business purpose requires it, who owns it, who can access it, where it has been duplicated, how long it should remain, and what will eventually delete or de-identify it.
Everyone Agrees Until It Becomes Personal
The technical problem is often easier to describe than the organizational one. Data minimization cannot be assigned to security alone because different teams may have competing reasons for retaining information.
A workable programme must bring together security, privacy, legal, IT, cloud operations, data governance, application owners, records management, and business leadership. The goal is not to make security responsible for every data decision. It is to ensure that every retained dataset has an accountable owner, a documented purpose, a valid retention basis, and an enforceable end-of-life process.
Where teams disagree, the disagreement should become a risk decision – not indefinite retention by default.
The Annual Data Cleanup Theatre
A one-time deletion campaign may remove some stale data, but it does not address the processes that created the accumulation. Without changes to collection forms, application requirements, SaaS configurations, access rules, backup policies, and deletion workflows, the same information will gradually return.
Meaningful measurement must therefore go beyond file counts. Organizations should look at whether stale sensitive data was removed, duplicate repositories were closed, automated retention was introduced, unnecessary privileges were reduced, ownership gaps were resolved, and deletion exceptions were reviewed.
Minimization becomes credible when the organization can demonstrate not only what its policy says, but what changed because of it.
Less Data Does Not Mean Less Business
The purpose of data minimization is not to delete valuable information indiscriminately, but to distinguish necessary value from unmanaged accumulation.
The decision should consider the sensitivity of the information, the consequences of misuse, the number of copies and access paths, the cost of protecting it, and whether the same purpose could be achieved with less data.
Some information must be retained, and some records must remain identifiable. Longer retention may sometimes be justified, but “it could be useful someday” cannot be the end of the analysis.
Turning Minimization into Action
The challenge is rarely recognizing that unnecessary data creates risk. The harder part is turning that understanding into decisions that have owners, deadlines, follow-up, and evidence.
CISOteria helps organizations connect identified data risks with the controls and actions needed to address them. Responsibilities can be assigned to the relevant owners, remediation can be tracked, exceptions can be documented, and leadership can see what has changed and what risk remains.
This helps move data minimization beyond a policy statement or one-time cleanup exercise. It becomes part of an ongoing governance process in which decisions are recorded, actions are followed through, and risk reduction can be demonstrated.
Conclusion: Retention with Intention
By the time a cyber incident begins, many of its consequences have already been determined. They were shaped by earlier decisions about what data to collect, where to copy it, who could access it, how long to retain it, and whether obsolete information would ever be removed.
Security controls determine how difficult it is for an attacker to gain access. Data minimization helps determine how much damage is possible once they do.
The question, therefore, is not only how the organization protects its data, but how much of that data should still exist to be protected.
For Further Reading
This blog post is based on insights and analysis from:
- Liao, Dianshu, et al. “Many a Little Makes a Mickle: A Code-Centric Empirical Study of Data Minimization Principle in Android App Development.” arXiv preprint arXiv:2606.02960 (2026).
https://doi.org/10.48550/arXiv.2606.02960
