How does directly identifying variables (DIV) work?

What DIV is in privacy and analytics

Directly identifying variables are fields that identify a person on their own, so they behave differently from quasi-identifiers or low-risk attributes. Treat them as high-sensitivity data elements, not just another row in a dataset. Their presence changes what you can lawfully share, how you de-identify a file, and how much exposure a copy or extract creates.

DIV usually sit at the boundary between data usefulness and disclosure risk. In practical terms, the more directly a variable can single someone out, the less it should survive into analytics extracts, test data, partner transfers, or lower-trust environments. If the dataset is meant to be de-identified, DIV are often the first fields to remove, mask, tokenise, or replace.

Why DIV increase re-identification risk

DIV raise risk because they allow direct linkage without needing to combine many other attributes. That means an exposed file can move from “sensitive but abstract” to “immediately attributable” very quickly. When a dataset contains names, account numbers, government identifiers, or similarly unique fields, the breach impact is usually higher because the data is already identity-resolving.

DIV also reduce the margin for error in downstream analytics. A record that could otherwise be treated as de-identified may become personally attributable once a single direct field is present. That is why privacy engineering tends to treat DIV as a special case in minimisation, masking, suppression, and sharing decisions, rather than as a routine data-quality issue.

For a broader treatment of re-identification controls and related techniques, the Privacy-Enhancing Technologies Guide is the relevant NHIMG reference for masking, tokenisation, synthetic data, clean rooms, and other privacy-preserving approaches.

How to handle DIV in real workflows

The safest pattern is to identify DIV early in the data lifecycle, classify them explicitly, and remove or transform them before the data reaches anyone who does not need the raw value. That matters most in research extracts, analytics sandboxes, vendor transfers, and production-to-nonproduction copies, where direct identifiers can quietly spread beyond the original purpose.

When DIV cannot be removed, the next decision is whether you can reduce exposure by pseudonymising, tokenising, or tightly restricting access. The control choice depends on whether the field must remain joinable, whether reversibility is needed, and whether the recipient genuinely needs the original value. A direct identifier that is still readable by broad audiences is usually a governance failure, not an acceptable compromise.

For teams building privacy controls around processing and sharing, the GDPR is a useful external reference point because it makes data minimisation, purpose limitation, and security of processing operational concerns rather than abstract principles. The same logic also aligns with the NIST Privacy Framework, which helps teams classify, govern, and reduce privacy risk in data handling.

Practitioner Guidance

What to verify: Check whether the field is directly identifying on its own, not merely potentially identifying when combined with other data. If it can single out a person by itself, treat it as DIV and apply stronger handling than for ordinary attributes.

Decision rule: If the raw value is not strictly required for the task, remove it before sharing. If the recipient needs a stable reference but not the original identifier, use a privacy-preserving substitute and keep the re-linking path tightly controlled.

Common mistake: Teams often focus on “de-identification” as a label and overlook one or two fields that still identify people immediately. One surviving direct identifier can undo much of the intended protection, especially in small populations or highly unique datasets.

Practitioner takeaway: The key judgement is not whether the dataset feels sensitive, but whether any field can identify a person on its own. If it can, the default should be to minimise access, minimise retention, and minimise the chance that the value ever leaves a controlled context.

Related resources from NHI Mgmt Group

• Directly identifying variables (DIV)
• How should organisations secure RDP access for remote work without exposing systems directly to the internet?
• How does direct identifying data work?
• What is an SVID and how does it work?