Less Personal Data, Only What You Need

The lifecycle from collection to deletion

Part 8 of 12 in "Databases for Non-Developers". This part covers why personal data is a responsibility to manage, not just an asset to accumulate — the entire journey from collection to deletion.

---

Imagine a service whose sign-up form asks for your date of birth, gender, occupation, address, and family relationships all at once. Even if none of it is needed today, you might be tempted to collect it anyway — "just in case we need it later." But personal data is not an asset that simply becomes more valuable the more you hoard.

As the data you keep grows, so does the scope of what you must protect, the chances of it being misused, and the damage if it is breached. Personal data is an asset and a liability at the same time — used well, it creates value; used badly or leaked, it comes back as fines, lawsuits, and shattered trust.

Personal data and sensitive data

Personal data doesn't mean only information that reveals identity directly, like a name. It can also include material that identifies someone when combined with other information — an email address, phone number, device identifier, location history, or purchase records.

Health, financial, biometric, precise location, and government-issued ID numbers cause greater harm when exposed. What legally counts as sensitive data varies by region and industry, so check the laws that apply to you (in Korea, the Personal Information Protection Act, the Network Act, the Credit Information Act, and so on) along with your contracts.

Security and privacy are not the same thing

• Data security focuses on stopping unauthorized people from viewing, altering, or destroying data.
• Privacy protection goes further, covering why data is collected, how it is used, and what impact it has on individuals.

Even data stored very securely can still be a privacy problem if you collected more than necessary or used it for a different purpose than the one you disclosed. And even data collected legitimately and minimally can still be breached if security is weak. The two areas overlap, but they are not the same. That's why Part 9 covers security while this part covers privacy.

The data lifecycle: from the moment it comes in to the moment it leaves

Personal data goes through the following stages.

1. Plan: decide why it is needed and what becomes impossible without it
2. Collect: gather it within the necessary scope, using appropriate methods
3. Store: manage where it lives, how it is encrypted, and who can access it
4. Use: work within the originally stated purpose and permitted scope
5. Share: define the scope of transfer, responsibilities, and deletion conditions with external vendors
6. Retain: keep it only as long as legal and business requirements demand
7. Delete or anonymize: safely remove data whose purpose has ended, or transform it so it can no longer be linked to an individual

There's a trap people often miss here. Pressing a delete button in an app does not make data vanish instantly from every copy and backup. You need a deletion process that accounts for where copies remain — operational systems, analytics stores, logs, external services, and backups. "Is a withdrawn member's data deleted?" deserves a better answer than "Yes, it disappears from the screen."

Data minimization: what you don't have, you don't have to protect

Data minimization is the principle of collecting and retaining only what is needed to achieve your purpose. The UK's privacy regulator (the ICO) advises defining your purpose first, then holding only the minimum personal data that is adequate, relevant, and necessary for it.

Before collecting anything, ask:

• What feature becomes impossible to provide without this field?
• Is it needed now, or are we collecting it vaguely "for the future"?
• Could the same goal be met with less sensitive information?
• Could we store an age bracket or a region instead of the exact value?
• When will it be deleted automatically?

The practical power of this principle is simple. Personal data you never collected cannot be leaked, cannot be misused, and cannot be fined over. The most reliable security is simply not having it.

Anonymization is harder than deleting names

Removing names and email addresses doesn't automatically make data anonymous. Combine a postal code, age, occupation, and a rare disease, and you can single someone out again. This is called the re-identification risk.

There are also two concepts that must not be confused:

• Pseudonymization: replacing direct identifiers with other values. With a separate linking key, the data can be reconnected to a person, so it is still treated as personal data.
• Anonymization: processing data so that a specific individual can no longer be identified. Done properly, it falls outside personal data regulation.

Treating the two as the same thing leads to incidents where people assume data is "anonymized" and handle pseudonymized data carelessly.

External services are part of your data flow too

When you hand payments, email, customer support, analytics, or AI features to external services, data moves outside your organization. Before signing a contract, confirm:

• What data is being transferred?
• For what purposes does the service provider use the data?
• Where is it stored, and is it passed on to sub-processors?
• When and how is it deleted after the contract ends?
• How quickly will you be notified if a breach occurs?
• Can you export and move your data?

Outsourcing the work does not outsource the risk or your responsibility to customers. If a partner leaks your customer data, you are the one who has to explain it to those customers (this connects to the supply-chain breaches in Part 10).

Key takeaways Privacy protection is broader than locking things up well. You must manage the purpose of collection, the scope of use, sharing, retention, and deletion. The most reliable way to reduce risk is not to collect personal data you don't need, and "keep it just in case" is a dangerous habit in the age of regulation.

Questions to think about

• What personal data are we collecting today that we never actually use?
• How many external services does our personal data flow into?
• When, where, and through what process is a withdrawn user's data deleted?
• Is the data we call "anonymized" truly anonymous — or only pseudonymized?

Next: We explore the basics of security — how data's confidentiality, integrity, and availability are protected, and why a single lock isn't enough as we look at layers of defense.

References: NIST Privacy Framework, ICO guidance on data minimisation

---

Series contents

1. What is a database — and how is it different from an Excel file?
2. How databases keep data accurate
3. What kinds of databases are there?
4. Databases, data warehouses, and data lakes
5. Why choosing the right database matters
6. Data models and data quality
7. What is data governance?
8. Less personal data, only what you need ← You are here
9. The basics of data security
10. Why do data breaches happen, and what should you do when one does?
11. Cloud and serverless databases
12. Databases in the AI era