Data breaches now read like a routine headline. A recent report estimated that in 2024, 1.7 billion people had their personal data exposed. Stolen names, addresses, passport numbers, login credentials, and phone numbers are often later utilized for identity theft and account takeovers.
In conversations about such sensitive data, we often hear the term “personally identifiable information” (PII), and there is often confusion as to what it actually means. Is an email address always PII? What about a device ID or a combination of postal code and date of birth?
In this article, we’ll provide a practical answer to what is personally identifiable information, show how it appears in real digital identity flows, and offer ways to protect PII data in your systems.
Get posts like this in your inbox with the bi-weekly Regula Blog Digest!
What is personally identifiable information?
Broadly speaking, personally identifiable information (PII) is any data that can be linked to one real person, either on its own or together with other data. If a detail helps you distinguish or trace an individual’s identity, you are dealing with PII data.
Beyond that, different institutions and regulations tend to define PII in different ways (if at all):
NIST describes personally identifiable information as any information that can be used to identify, contact, or locate a person, or that is linked or linkable to that person. This covers obvious fields such as a full name, and also less visible ones, like a device identifier that only one user has.
- The European GDPR, on the other hand, does not always use the label PII, but in day-to-day work, there is a major overlap between PII and personal data. In turn, personal data is any information that relates to an identified or identifiable natural person.
PII and personal data in everyday terms
Outside legal texts, people often refer to “personal information” instead. In typical business use, this phrase is very close to personally identifiable information. It covers things like names, email addresses, phone numbers, and identifiers that clearly point to a specific person, plus data that only becomes identifying after you combine it with other records.
For teams working on identity verification, selfie checks, or fraud prevention, it is usually practical to treat “PII”, “personal data”, and “personal information” as belonging to the same family. In the end, the most important is how you collect, store, and protect that data over its lifecycle; not how you label it.
Types of PII
Not all PII data carries the same risk, as some elements can identify someone instantly, while others only start to matter when combined. This distinction splits all PII into two key types:
Direct identifiers
Direct identifiers can identify a person on their own. If an attacker gets hold of them, they do not have to work very hard to match records to real people. Typical examples of personally identifiable information in this group are:
Full name with a specific home address
Email address tied clearly to one person
Passport number or other government identification numbers (e.g., a social security number)
Whenever such fields appear next to financial or health records, or next to biometric templates, they are usually classified as sensitive personally identifiable information.
Indirect and quasi-identifiers
Some data points are not uniquely identifying on their own. They still matter, though, because combined with one or two other fields they can trace an individual surprisingly quickly.
Typical examples include:
Partial postcode with gender and year of birth
Job title together with employer name
Device identifiers or browser fingerprints
IP addresses that map to a small user base
The same field can be harmless in one context and quite risky in another. A city of residence in a dataset with millions of users is one thing; the same city in a list of ten high-profile customers is something else.
Where PII appears in digital identity flows
For organizations that work with document authentication and face comparison, PII data is everywhere. A single verification step can generate multiple layers of identity-related records.
Data collected at onboarding
Every digital onboarding form captures some mix of:
Names and contact details
Dates and places of birth
Nationality or residence information
These sit at the front of any identity flow and usually represent the first contact point between a person and your service.
On top of this, services often collect account identifiers, customer numbers, and internal references. Individually, these may be opaque outside your system, but inside your environment they still refer to a specific individual and should be treated as PII.
Document images and biometrics
Document and selfie checks are especially rich in PII. A single passport scan or ID card photo can contain:
Name, address, and other textual fields
Dates of birth and expiration
Multiple identification numbers, such as MRZ lines and document numbers
High-quality facial images that count as biometric personal data
In other words, each file is a dense bundle of PII, and often sensitive PII. That is why document and face image storage, sharing, and deletion require very explicit rules. Even if you never store the raw media for long, any biometric templates or face embeddings you keep for matching purposes still qualify as sensitive personally identifiable information.
Logs, analytics, and secondary systems
PII frequently seeps into places that were not designed as primary data stores. Common examples are:
Web and application logs that record IP addresses, device identifiers, and user IDs
Analytics events that attach behavior data to user profiles
Exported CSV files used for manual reviews, reporting, or audits
Each of these can hold PII, either directly or by cross-referencing with other tables. They deserve the same care as “main” databases, especially in identity-heavy services where almost every event is tied to a real person.
How to protect personally identifiable information
Once you know what PII data is in your environment, the next question is how to handle it in a way that respects user rights and keeps risk under control.
Collect less and be clear about the purpose
Regulators often put strong emphasis on data minimization and clear purposes for processing. In practice, this means:
Do not collect more personally identifiable information than you need for a specific, legitimate purpose.
Be clear about why you collect it, how long you plan to keep it, and who it may be shared with.
For example, if you only need to confirm that a user is over a certain age, it may be enough to store a flag that the check passed instead of keeping a full document scan plus date of birth indefinitely. Less stored PII data means fewer records at risk if something goes wrong.
Sticking to well-defined purposes also helps you resist the temptation to reuse PII information for unrelated analytics, experiments, or marketing campaigns. If you cannot clearly connect a new use to the original purpose or a compatible one, it is safer to avoid that use or to aggregate and anonymize the data first.
Limit access and apply practical safeguards
For most organizations, good basics already go a long way in protecting PII:
Access control based on roles and duties, so only the right people see sensitive personally identifiable information.
Clear separation between production, test, and training environments, so live PII does not leak into places where it does not belong.
Strong authentication and monitoring for accounts that can view or export large sets of PII data.
Technical measures are also important: encryption of databases and file stores, encrypted connections between services, and consistent pseudonymization of identifiers all make attacks harder. And if PII does leak, these measures can reduce the chance that attackers read it in plain form.
Retention, deletion, and incident response
Pay extra attention to your retention rules:
ID/face images only for the period strictly required for regulatory checks or dispute handling.
Aggregated statistics for longer periods, once they no longer qualify as personally identifiable information.
When those limits are reached, automated processes can delete or anonymize records so they no longer relate to an identifiable person.
Incident response should also explicitly cover sensitive information connected to identity. If sensitive PII is exposed, you need a clear path for investigating what happened, containing the problem, and communicating with regulators and affected users.
Coordinate your flow with orchestration
Identity orchestration sits above individual tools and services and lets you manage how personally identifiable information moves through your verification flows. On top of that, solutions like Regula IDV Platform can run fully on-premises or in a private environment, so PII stays under the company’s direct control rather than being pushed to third-party clouds.
This way, all processes sit in one place, follow the same logic, and can be aligned with the organization’s own compliance requirements:
First, orchestration lets you define exactly which fields are collected at each step and which ones are dropped. You can, for example, read all the data from an identity document, but only pass a limited set of fields to internal systems, while keeping the rest inside a tightly controlled verification service.
Second, orchestration helps you route sensitive personally identifiable information only to services that truly need it. A risk engine might receive anonymized or tokenized attributes, while only a dedicated KYC system ever sees full document images or biometric templates.
Third, orchestration can tie your retention and deletion rules directly to the flow. It can trigger the deletion of document images once checks are completed, or keep them only in one controlled vault while other systems work with pseudonymized references.
A final word on personally identifiable information
Collecting personally identifiable information always comes with risks; however, they are not unmanageable. Clear rules, predictable processes, and identity orchestration will allow you to remove vulnerabilities from your identity flows and keep them smooth and robust.
