In the last unit you learned to size up how much harm a dataset could cause if it leaked. Now you'll add a second lens for the most common request that lands on your desk: someone wants to use information about actual people. Classification asks "how sensitive is this?" Privacy principles ask a different question, "is this use fair to the people the data is about?" Same triage habit you already know, just sharper questions.

Before you can judge a request, you need a few plain-language terms. Personal data is any information that identifies a person or could be linked back to one: a name, an email, an address, a customer ID, even a purchase tied to an account. Sensitive personal data is a smaller, riskier subset, the kind of detail that could expose someone to discrimination or serious harm if mishandled: health information, race or ethnicity, religion, sexual orientation, political views, or biometric and financial identifiers. When sensitive data is in play, your antenna should go up immediately.

Around these sit a handful of ideas worth naming. Consent is the person's agreement to a specific use of their data, and purpose is the reason the data was collected in the first place. These two often travel together: data collected for one purpose shouldn't quietly drift into another without fresh agreement.

The other two are about openness and control. Transparency means people were actually told how their data would be used, in language they could understand. And subject rights are the things a person can ask of you: to see what you hold about them, to correct it, or to have it deleted.

These all roll up into the Core Privacy Principles, a short list governance leans on worldwide: use data lawfully, fairly, and transparently; limit it to the purpose you collected it for; collect the minimum you need; keep it accurate; don't keep it longer than necessary; protect it; stay accountable; and respect those individual rights. You don't have to memorize all eight. The four you'll reach for most are purpose, minimization, transparency, and retention, and that's exactly what the next section turns into questions.

When a request to use personal data arrives, run it through four quick questions. The first is purpose fit: does this use match the reason the data was collected? Data gathered to fulfill orders being repurposed for marketing is a purpose mismatch worth flagging.

The second is minimum necessary data, often called data minimization. Look at every field being requested and ask, "does the stated goal actually require this one?" The instinct to grab "everything, just in case" is the single most common privacy risk you'll meet, and it's usually easy to trim.

The third is notice expectations: were people told their data might be used this way? If a customer would be surprised to learn what's happening with their information, that's a transparency gap.

The fourth is retention limits: how long will this data live once the work is done? "Keep it forever" is rarely the right answer. A clear end date is part of using data responsibly.

Here's the move that ties it together, and it's pure Coach territory. Your job is not to slap "denied" on an over-broad request. It's to reframe it so the person still gets the outcome they need with less personal data at risk. Start by asking what they're actually trying to achieve, then work backward to the smallest set of fields that answers it.

• Nova: Can you pull the full customer table for my analysis? Everything we've got.
• Jake: Happy to help. What's the actual question you're trying to answer?
• Nova: Which customers are likely to cancel next quarter.
• Jake: Then you need account tenure and usage history, not names, home addresses, or dates of birth. Want me to give you the slimmer set?
• Nova: That works, and honestly it's less for me to safeguard.
• Jake: Exactly. Less data, same answer, and faster to approve.

Notice that Jake led with the goal, not the fields. That keeps the conversation collaborative instead of adversarial, and the slimmer request almost always moves faster.

Hold the same boundary you learned in the last unit: you recommend, you do not decide the hardest calls. The moment a request involves consent questions, sensitive personal data, or anything that looks like regulated processing, your move is to document a clear recommendation and escalate to a privacy, legal, or compliance partner. You bring them a narrowed, well-reasoned request, which makes their decision faster and your judgment trusted.

The single takeaway: privacy work is mostly the discipline of asking "what's the real purpose, and what's the least data that serves it?" before anything leaves your hands. A few practices sit ahead of you. First a quick pattern-spotting exercise to match sloppy requests to the principle each one trips, then you'll write a real privacy-risk assessment, and finally you'll narrow a live request out loud. For now, the behavior to carry into your next data request is simple: ask the goal first, and trim every field that doesn't earn its place.