Correcting Common Misunderstandings About Personally Identifiable Information
Most security teams overestimate the value of isolated data points while underestimating the danger of non-sensitive metadata when combined with other sources.
Personally identifiable information is not a static list of fields. It is any data that can identify a specific individual, either alone or when combined with other available information. Treating only obvious fields like names as sensitive leaves large gaps in your protection strategy.
Misreading: Only direct identifiers count
Many organisations define personally identifiable information strictly as data that directly names an individual, such as a full name, date of birth, or government-issued identification number. This narrow view ignores the reality of data linkage. When you combine several non-sensitive data points, you can often pinpoint a specific person with high confidence. For example, a zip code, birth date, and gender combination is frequently unique enough to identify an individual.
Correct reading: Personally identifiable information includes any data that can distinguish an individual from all others in a dataset. This encompasses direct identifiers and quasi-identifiers. Quasi-identifiers are data points that do not uniquely identify a person on their own but become identifying when combined with other available information. You must assess the re-identification risk of your entire dataset, not just the presence of names.
Misreading: Anonymised data is safe to share
There is a persistent belief that removing direct identifiers renders data anonymous. This approach, often called de-identification, strips obvious links like names and account numbers. However, the remaining data often retains a unique fingerprint. Attackers or researchers can cross-reference this residual data with public records or breached databases to re-identify individuals. This process is known as linkage attacks.
Correct reading: True anonymity requires ensuring that no individual can be distinguished from others in the dataset, even with auxiliary information. Techniques like data masking or k-anonymity help, but they do not guarantee safety if the dataset contains rare combinations of attributes. If you are unsure, assume the data remains personally identifiable. For deeper technical controls, review the principles in our guide on data masking.
Misreading: Hashed data is no longer sensitive
Security teams often treat hashed data as non-sensitive because it cannot be reversed directly. A hash function converts input data into a fixed-length string. This is useful for verifying passwords or checking file integrity. However, if the input space is small or predictable, attackers can use rainbow tables or brute-force methods to reverse the hash. This is particularly true for common passwords, social security numbers, or employee IDs.
Correct reading: Hashed data remains sensitive if the original input can be guessed or looked up. Salting, which adds random data to the input before hashing, mitigates rainbow table attacks. Without sufficient salt and complexity, hashed personally identifiable information is vulnerable to re-identification. File integrity monitoring can detect unauthorised changes to these hashes, but it does not protect the underlying data from being guessed.
Misreading: Internal IDs are not personally identifiable
Many systems use internal identifiers, such as employee numbers or customer IDs, to reference records. These numbers appear meaningless to outsiders. However, they are directly linked to individuals within your own systems. If an attacker gains access to a mapping table or correlates an internal ID with external information, the data becomes personally identifiable. This is a common blind spot in data classification policies.
Correct reading: Any identifier that links to a specific individual within your environment is personally identifiable information. This includes database primary keys, session tokens, and internal reference numbers. You must protect these identifiers with the same rigor as direct identifiers. Access controls should prevent unauthorised correlation of these IDs with other personal data.
Misreading: Metadata is not personal data
Metadata describes the data, such as file creation dates, author names, or device identifiers. It is often overlooked in security assessments because it does not contain the primary content. However, metadata can reveal sensitive patterns about an individual’s behaviour, location, and associations. For instance, email headers can disclose server paths and device types, which can be used to profile users.
Correct reading: Metadata is often personally identifiable information. It can link an individual to specific activities, locations, or devices. You must sanitise metadata when sharing files or logs. This is particularly relevant when using honeypots, where metadata from fake user profiles can inadvertently reveal real infrastructure details. Strip unnecessary metadata before data leaves your controlled environment.
See also: Data Subject Access Requests: How to Handle Them Correctly
Misreading: Encryption solves the identification problem
Encryption protects data in transit and at rest by converting it into ciphertext. This prevents unauthorised access to the content. However, encryption does not change the fact that the data is personally identifiable. If an attacker decrypts the data, or if metadata leaks the structure, the identification risk remains. Encryption is a control, not a definition of sensitivity.
Correct reading: Encryption preserves confidentiality but does not alter the nature of the data. Personally identifiable information remains sensitive even when encrypted. You must still apply access controls, audit logging, and data minimisation. Encryption does not replace the need to understand what data you hold and who can link it to an individual.
Key takeaways
- Context determines whether data is personally identifiable, not the data type itself.
- Non-sensitive data becomes sensitive when combined with other datasets.
- Hashed data is not anonymous if the original input can be reconstructed or guessed.
- Internal identifiers can be traced back to individuals through correlation.
Personally identifiable information is defined by its potential to identify an individual, not just by its obvious content. Review your data classification framework to include quasi-identifiers and metadata, and ensure your controls address re-identification risks.
Frequently asked questions
Is an email address considered personally identifiable information?
Yes, an email address is a direct identifier. It can be used to contact or profile a specific individual, especially if the username matches a common name or contains unique identifiers.
Does pseudonymisation remove the status of personally identifiable information?
No. Pseudonymisation replaces direct identifiers with artificial ones. The data remains personally identifiable because it can be re-identified using a separate key or mapping table.
How do I determine if my dataset contains quasi-identifiers?
Identify fields that are unique or rare in combination. Test your dataset against public records or simulated linkage attacks. If combinations of fields narrow down to a single individual, they are quasi-identifiers.
Can I share personally identifiable information with third parties?
Only if necessary and with appropriate safeguards. Ensure third parties have equivalent security controls and legal agreements. Understand that breach notification laws may apply to shared data.
How this guide was produced: written by the Vector Bulletin editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
