In the last unit you weighed whether a use of personal data was fair to the people behind it. Now the question shifts from "is this use appropriate?" to "who should be able to touch this data, and how do we keep it safe and usable?" Here's the trap to avoid up front: you are not the security team, and this unit will not turn you into one. Your job is to coordinate with the people who own controls, not to own the controls yourself. The same triage habit carries over, you just need a shared language to talk to security partners without pretending to be one.

That shared language is the CIA Triad, three plain ideas that security teams use to think about protecting data. The first is confidentiality: only the right people can see the data. When the wrong person reads a confidential file, that's a confidentiality failure.

The second is integrity: the data stays accurate and unaltered. If a number gets quietly overwritten or a record is tampered with so reports no longer match reality, that's an integrity failure. The third is availability: the people who are authorized to use the data can actually get to it when they need it. A locked-down dataset that nobody approved can reach on deadline is an availability failure, even though nothing leaked.

What makes the triad useful to you is that it keeps the conversation balanced. The instinct under pressure is to focus only on confidentiality, "lock it down so it can't leak." But security is a three-way trade. Locking something so tightly that the team that needs it can't work is an availability problem, not a win. Naming which of the three is actually at risk in front of you sharpens the request and earns you credibility with security partners, because you're speaking their language instead of waving vaguely at "risk."

When an access request lands on your desk, run the same triage you already know, tuned to four questions. First, sensitivity: how is this data classified, and how much harm if the wrong person sees it? You learned to answer that two units ago. Second, business need: what is the person actually trying to do, and does the access genuinely serve it? Third, the right approver: who is accountable for this data and can legitimately say yes? That's almost always the data owner, not you and not security. Fourth, the risk partner: who else needs to weigh in, security for the control itself, and privacy or compliance if the data is regulated.

Running those four questions does something important: it sorts out who decides what. A handy principle to anchor on is Least Privilege, which means granting the minimum access required for a defined need, and reviewing it as the need changes. "Give them everything, just in case" is the access-world version of the over-collection you trimmed in privacy work.

• Dan (a contractor on the procurement team's supplier-improvement project): Can you just get me into the supplier dataset? I need it by Friday.
• Matt: I can tee that up for security. First, what exactly do you need to see, and for how long?
• Dan: Just the scorecard fields, through the end of the project.
• Matt: Good, that's least privilege. I'll confirm the classification and get the owner's sign-off, then security grants and monitors it.
• Dan: So you're not the one who flips the switch?
• Matt: Right. I bring the facts and the approval; security owns the control.

Notice the boundary in that last line. Matt narrowed the scope and gathered the inputs, but he never granted access himself. That separation is the whole point of this unit.

Once you've triaged, your deliverable is not a decision, it's a clean package of inputs the security owner can act on. A strong handoff gives them five things: the data's classification, the business purpose, who approved it (the named data owner), the least-privilege scope (exactly what the person may see, not everything adjacent), and a review or expiry date so the access doesn't quietly become permanent. Frame the whole thing explicitly as a recommendation for the security owner to implement, never as your own ruling. That framing protects you and respects the boundary.

Know your escalation triggers, too. The moment a request touches restricted or regulated data, involves external sharing, or asks for elevated privileges (admin-level or broad standing access), that's beyond a routine handoff. Document your recommendation and pull in security, and privacy or compliance as needed, before anything moves.

The single takeaway: your value in security work is being the person who brings the right facts (sensitivity, need, approver, scope, and a review date) to the people who own the controls, never the person who flips the switch. The first thing ahead is a quick pattern-spotting check, sorting everyday concerns into confidentiality, integrity, or availability, so the triad becomes second nature before you carry it into a live triage conversation and then a written handoff. For your next real access request, try opening with one question: "What's the smallest slice of this you actually need, and for how long?"