Every security team has the same list. Encrypt the database. Patch the servers. Rotate the keys. Turn on two-factor login. Run a penetration test once a year and fix what it finds.
All of that is good work. But there is one control that beats every item on the list, and it costs almost nothing: don’t have the data in the first place.
A database that does not exist cannot be stolen. A field you never stored cannot appear in a leak. A log you deleted last month cannot be read by the person who breaks in next month. This sounds too simple to count as a security strategy, so most companies skip it. They collect first and plan to protect later.
Every row is a liability
Engineers like to say data is an asset. On a balance sheet it may be. In a breach report it is the opposite.
IBM’s 2026 Cost of a Data Breach study puts the global average cost of a breach at $4.99 million. That money goes to lawyers, regulators, customer notices, credit monitoring and lost business. None of it depends on how good your encryption was. It depends on what was taken and how many people it belonged to.
Equifax is the classic example. In 2017 attackers got in through an unpatched web application and walked away with personal data on about 147 million people. Names, birth dates, national ID numbers. The patch was the immediate failure. The size of the damage came from something else: one company held that much sensitive data about that many people in one place.
Here is the uncomfortable math. Your defences have to work every day, against every attacker, for as long as you keep the data. The attacker has to succeed once. If you keep a record for ten years, it has to survive ten years of new bugs, new staff, new vendors and new mistakes. If you keep it for thirty days, it only has to survive thirty days. If you never collect it, there is nothing to survive.
Linked data leaks in chains
The 2023 breach at a genetic testing company shows a quieter problem. Attackers logged into about 14,000 accounts using passwords people had reused from other sites. That alone was bad. But the service had an opt-in feature that showed each user their genetic relatives, with names, family trees and ancestry details. Through those 14,000 accounts the attackers reached profiles of about 6.9 million people.
Most of those 6.9 million did nothing wrong. Their passwords were fine. Their data leaked because a distant relative they had never met had a weak password, and because the service had linked their profiles together.
This is the part that is easy to miss. Every link between two records makes a leak bigger. A contact list that syncs to the server exposes your friends, not just you. A shared workspace exposes the whole team. Features that join data together are often the most popular ones, and they are also the ones that turn a few thousand stolen accounts into millions of exposed people.
“We might need it later”
So why does everyone collect so much? From the inside, it rarely feels like a decision. It feels like a series of small, sensible defaults.
The analytics SDK records every screen and tap, because maybe the product team will want a funnel one day. The signup form asks for a birth date, because marketing might segment by age. Server logs keep full IP addresses forever, because nobody set a retention period. Support tickets keep the attachments users sent in 2019. Backups keep all of it again.
Each choice is cheap when it is made. Storage is cheap. The cost shows up years later, all at once, on the worst day of the company’s life.
European law already names the principle. The GDPR says personal data must be “adequate, relevant and limited to what is necessary” for the purpose, and kept no longer than needed. Most people read this as a compliance rule. I read it as the best security advice in the whole regulation.
What minimisation looks like in practice
It is not about collecting nothing. Some apps really need an account, an email or a payment record. It is about asking a plain question for every field: what breaks if we don’t store this?
Often the answer is “nothing”. A few patterns that come up again and again:
- Keep data on the device. If a feature works with the data on the phone, it does not need a copy on a server. A to-do list, a habit tracker or a timer can live entirely on the user’s device. There is no central database to breach because there is no central database.
- Count, don’t record. If you need to know how many people use a feature, you need a number, not a log of who used it when.
- Store less precise data. A city is enough for most features that ask for a location. A birth year is enough for an age check. A shortened IP address is enough to spot abuse.
- Delete on a schedule. Logs, sessions and temporary files get a retention period on day one, and a job that actually deletes them. A rule nobody enforces is a wish.
- Don’t add the SDK. Many leaks start in third-party code nobody on the team reads. Every tracking or ad library is one more company holding your users’ data. We wrote about this in why we don’t track users.
There is a side effect developers enjoy: less data means less code. No consent banner for data you don’t take. No export tool for a profile that does not exist. No deletion request to process for an account you never created. Deleting a dependency is one of the small joys of the job, and deleting a whole category of data feels even better.
The tradeoff, honestly
Minimisation has a cost. You know less about your users. You cannot run every experiment the growth playbook suggests. Some features, like cross-device sync or sharing, need a server and need careful design to stay small. When something goes wrong on a user’s phone, you have fewer logs to look at. You fix bugs by asking people and testing on real devices, not by searching a pile of events.
For an ad-funded business this cost is too high, because the data is the product. For most other software it is a good deal. You give up some insight and get a smaller attack surface, smaller breach costs, simpler compliance and a promise to users you can actually keep.
The question to ask
Security reviews usually ask “how do we protect this data?” It’s a good question, but it comes second. The first one is “do we need this data at all?”
Every “no” removes a risk for good. No firewall rule or encryption key gives you that. Next time a form gets a new field or a log gets a new column, ask what happens on the day it leaks. If the honest answer is “nothing would break if we never had it”, don’t collect it.