Skip to main content
Handbook/Protect/Page 109 · Responsibility

You Own What You Collect

Share

Share this page

Pass it to someone who needs it.

Star on GitHub

Key takeaway: You own collected data

Chapter 12 of 15 · Protect

Handle user data responsibly and legally

The moment you hold real user data, it is your responsibility, legally and morally. This part is how you handle it right: collect less, guard what you keep, and be ready if the worst ever happens.

By the end of this part, you can:

  • Handle user data legally and responsibly
  • Collect only what you need and protect what you keep
  • Give users control over their own data
  • Have a plan ready before a breach, not after
Done:Secure·You are here: Protect·Next:Ship

12.1.1Their data is your responsibility

It is tempting to think of user data as an asset, a pile of value you are accumulating. Flip that. The moment it is real people's data, it is a liability: something you now have to protect, keep accurate, and be ready to hand back or delete.

That changes who a mistake hurts. A leak is not your inconvenience, it is a real person's home address in the open or their reused password in an attacker's hands. You are holding it on their behalf, so their exposure is your responsibility.

12.1.2Collect only what you need

Every field you collect is one more thing to secure, keep correct, and answer for if it leaks. So collect the least you can. This is data minimization, and it is the cheapest security control you have: data you never stored cannot be stolen.

Be strictest with personally identifiable information (PII), the data that points at a specific human, like their email, phone, or home address. Ask of each field whether the app truly needs it now, or whether you kept it just because it was easy.

Rule of thumb: If you cannot name why you store a field, do not collect it.

Every field must earn its place or it never enters the database.

12.1.3Know what you hold and why

You cannot protect what you have not written down. A data inventory is one plain list of every kind of data you store, why you keep it, and how sensitive it is. You already sketched the things your app stores when you modeled your data; the inventory adds the why and the risk.

Have your agent produce it and keep it in your system. It looks like this:

Data Why we store it Sensitivity email login and receipts medium password hash login high card last 4 show the saved card medium IP address blocking abuse low, drop at 30 days

That one page tells you where to spend your protection effort, and it is the first thing you reach for when something goes wrong.

The sensitivity column tells you which records to protect first.

12.1.4Clean data pays you back twice

Keeping this data lean and labeled is not only about risk. The same clean, well-kept data is what your AI reads to make decisions and trace bugs once the app is live. That is the second payoff the Operate part builds on, when you are watching the app run. Kept clean now, it pays twice.

One clean dataset pays off twice, as protection now and as fuel for AI later.

This prompt has your agent draft the inventory from your app:

Ready prompt
Act as a senior engineer auditing what my app collects. Read the real schema and my data model, not only what my spec claims, then list every kind of data stored as a data inventory: the field, why we store it, and how sensitive it is (low, medium, high). Flag any field that is personally identifiable, and call out anything we collect without a clear reason, or that no user story in my spec asks for, so I can drop it. Keep it one plain table. Record each field I drop, and why, as a line in my decision log. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/protect/owning-user-data My app and the data it collects:

Do this now: paste the prompt, let your agent draft your data inventory, and delete any field it cannot give a clear reason for.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Star on GitHubContribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license