Who can see what: access, privacy, and purpose in talent data

Start with the action the person is authorized to take

A leader is preparing a development conversation. The talent team is analyzing patterns across functions. A committee is reviewing an internal transition. All three situations use information about people and require different levels of detail.

Define the legitimate action first. Then provide the minimum information needed to carry it out. A summary with agreed evidence may be enough to guide development. To resolve an appeal, an authorized reviewer needs to reconstruct the full case.

Job title is no substitute for this analysis. Authority over one function does not create a need to read identifiable comments from across the organization.

Consider five dimensions together

The first is purpose: which decision or support activity justifies access? The second is the recipient: what function do they perform, and what conflict might they have? The third is granularity: aggregate data, an individual result, evidence, or the source’s identity. The fourth is duration. The fifth covers permitted actions, such as viewing, exporting, combining, or reusing.

Turn these dimensions into understandable rules. A technical matrix that no one can explain eventually gives way to informal arrangements.

One legitimate use does not authorize the next

The comments opened to investigate an appeal were gathered for a specific purpose. Using them later in succession planning changes the consequences, the audience, and possibly the interpretation.

Before expanding the purpose, review necessity, sensitivity, the expectations communicated, and the opportunity to challenge the use. If the new use requires a different validity argument or more evidence, access permission does not close that methodological gap.

The OECD’s privacy guidelines establish principles of purpose specification and use limitation. Their legal application depends on the context; as design criteria, they help prevent availability from becoming authorization. OECD Privacy Guidelines (opens in a new tab).

Context must travel with the result

Anyone receiving a score needs to know its date, version, original purpose, and limits. Separating it from those conditions creates a certainty the assessment never produced.

There must also be a way to learn about and challenge sensitive uses. That opportunity has no effect if the person only learns of the final decision or the reviewer cannot correct it.

The NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk. It does not prescribe talent-data permissions. Its contribution is to treat privacy as part of the system and its effects on individuals, rather than reducing it to a notice at the end of the process. NIST Privacy Framework (opens in a new tab).

Retention keeps future access possible

Available data may end up serving an unforeseen purpose. Define retention according to purpose, obligations, sensitivity, and the realistic possibility of review.

Set review triggers: the close of an appeal, a role change, a new version, departure from the organization, or the end of the authorized period. Exceptions need an expiration date and an owner; otherwise, they become silent precedents.

Design permissions around scenarios, not organizational charts

Build a table of real situations: a development conversation, a mobility review, aggregate analysis, and an audit. Include appeal investigations and incident response too. For each situation, define the recipient, visible fields, permitted actions, and the condition that ends access.

Then test combinations. Data that is not particularly sensitive on its own may reveal more when combined with location, career history, or a small team. An aggregate report may identify someone when a group has two members. Minimization must consider the full set the user receives, not each field in isolation.

Separate viewing, exporting, and administration. Someone who needs to consult a result does not necessarily need to download it; someone who configures the system does not need to read its content. Log sensitive access and review unusual patterns, but do not turn auditing into indiscriminate surveillance.

The design must also anticipate delegation and absences. Temporarily inherited permissions need explicit scope and expiration. When someone changes function, an event should end their previous access; it should not depend on occasional cleanup.

Test the rule with an uncomfortable request

Choose a plausible request from someone with substantial authority. Ask what task they need to complete, what detail it requires, what they will do with it, and when access ends.