Personally identifiable information (PII)

How PII works in B2B data

PII starts from one question, whether information alone or combined with other data can point to a specific person. NIST frames it as information that can be used to distinguish or trace an individual's identity, plus any other information that is linked or linkable to that individual 1. To distinguish is to tell one person apart from others. To trace is to process enough data to determine something about a person's activities or status 1.

Linked information is logically associated with other information about the person 1. Linkable information could be associated with it, for example when two databases each hold different elements and someone with access to both can join them 1. NIST treats data as linkable when the other source is readily obtainable, which includes public records and internet search 1.

As a result, B2B records hold PII even when no field looks sensitive. A job title on its own says little. Next to a name and a company in the same row, it is linked information about a known person. NIST's examples include names, email addresses and telephone numbers, with business numbers listed explicitly 1. A direct dial and a work email are PII.

European law uses a different term. The GDPR defines personal data as any information relating to an identified or identifiable natural person, who can be identified directly or indirectly through identifiers such as a name, an identification number, location data or an online identifier 2. The European Commission adds that pseudonymized data that can be used to re-identify a person remains personal data, and that only irreversibly anonymized data falls outside it 3.

Company-level data sits mostly outside both concepts. The Commission lists a company registration number and an address such as info at a company domain as examples of data that is not personal data 3. Firmographics like industry and headcount band describe the company, until they are stored in a record built around a named contact.

How to rate PII risk in a dataset

Not all PII carries the same risk. NIST asks organizations to assign each set of PII a confidentiality impact level of low, moderate or high, based on the harm a breach could cause 1. It describes six factors that organizations can weigh when they set the rating 1.

**Identifiability.** How easily the data points to a specific person. Data that directly identifies someone may warrant a higher level than data that does not identify anyone by itself 1.

**Quantity.** How many people are in the set. NIST notes that breaches of 25 records and 25 million records may have different impacts, and that a small dataset should not get a lower level for that reason alone 1.

**Field sensitivity.** What each field reveals, alone and in combination. NIST rates a phone number as generally less sensitive than a social security number or financial account details 1.

**Context of use.** Why the data is held. NIST notes that the same data elements can be assigned different impact levels depending on the purpose of collection and use 1.

**Obligation to protect.** Laws, regulations and contracts that apply to the data.

**Access and location.** Who can reach the data and where it is stored, including copies in logs, exports and spreadsheets.

Some PII needs little confidentiality protection. NIST gives the example of an organization that publishes a phone directory of employees' names and work phone numbers so the public can contact them 1. Such data may still need integrity and availability controls 1.

Collecting less is a control in its own right. NIST recommends keeping the use, collection and retention of PII to what is strictly necessary for the business purpose 1. For a data enrichment workflow, that means requesting the fields a campaign uses and leaving the rest unfilled.

Example of classifying PII in an enriched contact record

A data team reviews the fields in its enriched contact table before granting a new analytics tool access. It labels each column.

Field            PII     Reason
company_domain   no      identifies a company
industry         no      describes the company
company_size     no      describes the company
full_name        yes     distinguishes a person
job_title        linked  stored next to a named person
work_email       yes     email address, NIST example
direct_dial      yes     business phone, NIST example
profile_url      yes     points to one person

The company columns stay outside PII because they describe an organization, in line with the Commission's examples of data that is not personal 3. The person columns are PII on NIST's own examples, which name email addresses and business phone numbers 1.

The job title row is the edge case. Alone it identifies nobody. In this table it sits in the same row as a name, which makes it linked information about that person 1. The analytics tool gets the company columns and a hashed contact ID only.

The team also checks where PII leaks into logs. RichAPI keeps lookup inputs such as names, domains and emails in request logs for 30 days for billing and debugging, then purges them, and its logs follow an automated zero-plaintext-PII policy 4. The team sets a matching retention rule for its own pipeline logs.

Hashing the ID does not take the table out of scope. Under EU law, pseudonymized data that can be re-identified is still personal data 3. The identity resolution key that joins the tables is stored with the same controls as the names.

PII vs personal data

The two terms overlap heavily. PII comes from US federal guidance and asks whether information can identify a person 1. Personal data is the GDPR term and covers any information relating to an identifiable person 2.