Directly identifying variables (DIV) are data fields that can identify a person without inference, such as a full name, passport number, or employee ID. In practice, a payroll export with an employee number linked to a person is a DIV. Teams should classify these fields, restrict access, and minimise where they are stored or shared.
What counts as a directly identifying variable in real data?
A directly identifying variable is a field that identifies a person on its own, without needing extra inference or matching. Common examples include a legal name, passport number, national ID, employee number, payroll ID, or customer account number when it points directly to one person. The key test is whether the field can single out an individual immediately.
In practice, the question is not whether the field feels sensitive, but whether it is directly usable to name, locate, or look up a person. A dataset may also contain several DIVs at once, which raises the exposure level because more than one route exists to identify the same individual.
How a DIV appears in everyday operations
A payroll export is a straightforward example when it contains an employee number tied to a named worker. That identifier may look operational rather than personal, but once it maps directly to one person, it becomes a directly identifying variable. The same pattern appears in HR extracts, supplier onboarding records, help desk tickets, and benefits administration files.
DIVs often matter most when they cross system boundaries. A field that is harmless inside one internal application can become identifying when it is exported, combined with other records, or shared with a third party. The practical control question is whether the field is being handled in a context where it can reveal a person immediately.
For teams working with privacy engineering, the broader pattern is similar to the distinctions covered in the Privacy-Enhancing Technologies Guide: identify what is directly identifying, then decide whether you should minimise, mask, tokenise, or keep it in a more controlled environment.
Why classification matters for storage, sharing, and access
Once a field is classified as a DIV, it should be treated as something that can expose a person immediately if it is disclosed, duplicated, or joined to the wrong audience. That means access should be limited to the smallest set of users and systems that genuinely need it, and copies should be kept to a minimum. The operational goal is to reduce unnecessary spread, not just to label the field.
DIV handling also affects downstream governance. If a directly identifying field is embedded in logs, spreadsheets, exports, support attachments, or analytics extracts, it can create avoidable exposure even when the originating system is well protected. The fact that the field is “just an ID” does not reduce the risk if it can be used to identify a person directly.
Risk and Threat Considerations
Directly identifying variables are risky because they are easy to misuse once exposed: they can enable unwanted lookup, profiling, record linkage, or unauthorised disclosure with very little additional context. The danger is highest when the same identifier is reused across systems, shared outside the original business process, or stored in places that are widely accessible.
Failure mechanism: A directly identifying field is copied into an export, log, or integration feed and then reused beyond its original purpose, making it available to people or systems that were never intended to see it.
Impact: The person can be identified immediately, and the field can become a pivot point for broader privacy exposure, unauthorised access to related records, or unnecessary disclosure across multiple systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Direct identifiers for external people require strong identity handling and controlled access. |
| AC-6 — Least Privilege | DIVs should be restricted to the minimum set of users and processes that need them. | |
| Recommendation — Limit exposure of person-linked identifiers and enforce access controls around them. Restrict access to directly identifying fields to the minimum necessary set of users and systems. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | DIVs need classification so handling rules match their identifying nature. |
| A.5.15 — Access control | Access to identifying fields must be limited to reduce disclosure risk. | |
| Recommendation — Classify directly identifying variables and apply handling rules based on their sensitivity. Apply access control to reduce unnecessary access to directly identifying variables. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Handling DIVs depends on knowing who can access identifying data and why. |
| Recommendation — Govern access to identifying data so only authorised users and processes can reach it. | ||
Practitioner Guidance
What to verify: Confirm whether the field identifies a person on its own or only becomes identifying after joining to another dataset. If the answer is “on its own,” treat it as a DIV and apply stricter handling immediately.
Common mistake: Teams often downgrade risk because the value looks like an internal number rather than a name. That is a mistake when the number is already linked to one person in the source system.
What good looks like: DIVs are inventoried, access is limited, exports are reviewed, and unnecessary copies are removed or minimised. The field is still usable for the business process, but it is not spread across every operational workflow by default.
Practitioner takeaway: The practical test for a DIV is simple: if the field can identify a person without inference, control it like identifying data, not like a harmless reference number.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org