Privacy & data protection

Key takeaways Security serves privacy — it is the toolkit that lets you handle personal data responsibly, but it is not the same thing. Classify and minimize: know what data you hold, and hold as little as you can get away with. Protect PII with encryption, access control, and anonymization. Know the rules that apply to your users. The less sensitive data you hold and the better you guard it, the smaller any breach. Builds on the CIA triad.

You can build a perfectly secure system and still handle people’s data badly — locking it down tight while collecting far more than you need, keeping it forever, and sharing it in ways your users never expected. Privacy is the discipline of handling personal data responsibly. Security is how you enforce it. This lesson connects the two.

Security vs. privacy

These words get used interchangeably, but they answer different questions.

Security asks: is this data protected from unauthorized access, change, or loss? It is about confidentiality, integrity, and availability — the CIA triad.
Privacy asks: should we have this personal data at all, and are we using it the way people would expect? It is about collection, purpose, consent, and retention.

Security is a tool for privacy, not a substitute for it. Encryption stops an attacker from reading a database — it does nothing about the fact that you collected ten times more personal data than you needed. You need both: privacy decides what you may do with personal data, and security makes sure only that happens.

Classify your data

You can’t protect what you can’t identify, so classification comes first. Sorting data by sensitivity tells you where to spend your protection effort. A common scheme:

Public — meant to be seen by anyone (marketing pages, published docs). No harm if it leaks.
Internal — routine business data not meant for outsiders (internal wikis, non-sensitive logs). Mild harm if it leaks.
Confidential — data that would hurt the business or partners if exposed (contracts, source code, security configs).
Personal / PII — anything that identifies a person or links back to them: names, emails, addresses, device IDs, location, and especially sensitive categories like health or financial records.

The highest-sensitivity tier drives the strongest controls. Once data is labelled, every later decision — who can read it, whether it’s encrypted, how long you keep it — follows from the label.

Data minimization

The single strongest privacy control is almost boring: don’t collect or keep data you don’t need. You can’t lose, leak, sell, or subpoena data you never held. Every field you choose not to store is a risk that simply never exists.

Minimization has two halves:

Collect less. Before adding a field, ask what it’s for. If there’s no concrete purpose, don’t collect it. Prefer a coarse value (age range) over a precise one (birth date) when the coarse one does the job.
Keep it shorter. Set retention limits and delete on schedule. Data that outlived its purpose is pure liability — it can still leak, but it no longer helps you. Automate deletion so it isn’t left to memory.

When a breach eventually happens — and you should plan as if it will — the damage is bounded by what you were holding at that moment. Minimization shrinks that number in advance.

Protecting personal data

For the personal data you do need to keep, standard security controls do the heavy lifting:

Encryption at rest and in transit. Encrypt stored personal data and protect it as it moves across networks so a stolen disk or intercepted connection yields nothing readable. See cryptography in practice.
Access control. Only the people and services with a genuine need should be able to reach personal data, and only at the level they need. This is authorization and access applied to your most sensitive tier.
Anonymization and pseudonymization. Where you can, strip out or replace identifiers. Anonymization removes the link to a person entirely (ideally irreversibly); pseudonymization swaps identifiers for tokens so records stay usable but aren’t directly tied to a name. Analytics on pseudonymized data is far safer than on the raw records.

The rules

Beyond good practice, handling personal data is increasingly governed by law. A high-level view of what tends to apply:

Comprehensive privacy laws. The EU’s GDPR and California’s CCPA (and a growing list of similar laws) grant people rights over their data — to see it, correct it, delete it, and know how it’s used — and put duties on whoever collects it. They often apply based on where your users are, not where you are.
Breach-notification duties. Many laws require you to notify regulators and affected people within a set window after a breach involving personal data. Knowing what you hold and where (your classification work) is what makes fast, accurate notification possible.
Data-processing agreements. When another company handles personal data on your behalf (a hosting provider, an analytics vendor), a contract typically has to spell out what they may do with it. See privacy & data agreements and, for AI systems, privacy, data & compliance.

This is a map, not the territory. Which rules apply, and exactly what they require, is a legal question — when in doubt, involve legal counsel. This lesson is educational and is not legal advice.

Quick check: what is the most effective way to limit the damage of a future data breach?

Recap

Security protects data; privacy is about collecting and using personal data responsibly. Security serves privacy — it isn’t the same thing.
Classify first: public, internal, confidential, and personal/PII. You can’t protect what you can’t identify.
Data minimization is the strongest control — don’t collect or keep what you don’t need, and delete on a schedule.
Protect the PII you keep with encryption, access control, and anonymization/pseudonymization.
Know the rules (GDPR, CCPA, breach notification, processing agreements) — and involve legal when in doubt.
This is educational, not legal advice.

Next up: Module 6 puts security into practice — security for developers