PII vs SPII: Where the Line Is and Why It Changes How You Share

That question — PII vs SPII — sounds like legal trivia until you are the person about to publish something. It is actually the single most useful classification call you can make before sharing content, because it determines everything downstream: whether the link needs a password, how long it should live, whether it should exist as a link at all. This guide defines both terms, explains why the boundary moves with context, and gives you a three-tier model you can apply without a lawyer in the room.

What PII is, and what makes some of it sensitive

PII (personally identifiable information) is any data that identifies a specific person, either on its own or when combined with other data you hold. A full name. An email address. A phone number. A mailing address. A customer ID that maps to a real human in your CRM. The common types of PII data in a sales or marketing context are unglamorous: contact records, form submissions, billing addresses, IP-derived location in your analytics.

SPII (sensitive personally identifiable information) is the subset whose exposure creates direct, concrete harm to the person — not embarrassment, not annoyance, but fraud, discrimination, or physical risk. The usual members of that set:

• Government identifiers — Social Security or national insurance numbers, passport and driver's licence numbers, tax IDs.
• Financial account data — card numbers, bank account and routing details, anything that moves money.
• Health information — diagnoses, treatment, insurance claims, anything that implies a medical condition.
• Biometrics — fingerprints, face templates, voiceprints. Unlike a password, these cannot be rotated.
• Precise geolocation — coordinates that put a named person at an address at a time.
• Protected characteristics — under GDPR and several US state laws, race and ethnicity, religion, political opinions, union membership, sexual orientation, and genetic data all sit in a special category with tighter rules.

PII is defined by identifiability, SPII by consequence of exposure. That is why you cannot classify data by reading the column headers. A leaked email address costs someone spam. A leaked SSN costs them a year of their life.

Why context promotes ordinary PII into sensitive territory

This is the part that trips up most classification policies. Sensitivity is not a property of the field. It is a property of the field plus what surrounds it.

A list of 400 names and mailing addresses is ordinary PII. The same 400 names and addresses under the heading "Oncology patients — Q3 outreach" is health information about 400 identified people, and it is now sensitive. Nothing in the data changed. The label did the work.

The same promotion happens constantly in revenue work, usually by accident:

• A lead list becomes sensitive when the segment name reveals a protected characteristic — "congregation members," "veterans with disability benefits."
• A churn dashboard becomes sensitive when the "reason" column contains free-text notes a rep typed about someone's medical leave.
• A billing report becomes sensitive the moment someone leaves the last four digits and the full card BIN in the same row.
• An event attendee export becomes sensitive when a hidden column carries dietary requirements, which are frequently a proxy for religion or a medical condition.

The practical rule: classify the document, not the column. Ask what a stranger could infer about a named individual from the whole artifact — title, headings, filters, and footnotes included — and classify at the highest inference the document supports.

The three-tier model

Two categories are not enough to run a policy on, because most of what your team shares contains no personal data at all and does not deserve the same friction. Three tiers is the smallest model that works. Adopt these definitions verbatim if you like — the value is in everyone using the same ones.

Tier 1 — Non-personal

No individual is identifiable, directly or by combination. Product one-pagers, pricing tables, aggregate metrics with a floor (no cohort smaller than, say, 20), anonymized benchmarks. This is genuinely PII-free data, and PII-free is a claim worth testing rather than assuming: a "region" column with one customer in it is not anonymous.

Tier 2 — PII

Individuals are identifiable, but exposure causes nuisance rather than harm. Proposals addressed to a named buyer, lead lists, attendee rosters, dashboards with rep names on them, most customer PII you touch in a normal week.

Tier 3 — SPII

Exposure creates direct harm: financial, medical, legal, or physical. Government identifiers, financial account data, health data, biometrics, precise location, protected characteristics — or any Tier 2 artifact that context has promoted.

Each tier gets one sharing posture. Write it down once and stop relitigating it per deal.

Those settings map directly onto HTMLvault controls. Tier 1 is a plain link with expiry set long or off. Tier 2 pairs password protection with a short window — see choosing an expiry window that matches the deal for how to pick the number. Tier 3, if it must move at all, runs on the shortest expiry available and a retention window set to auto-delete, so the content is gone from storage rather than merely unreachable.

Worked example: classifying one export before it ships

Take a real artifact: a renewal-risk dashboard your analyst generated, headed to three people on the customer's side. Four steps, about ninety seconds.

1. Run the scanner first, before you judge anything. HTMLvault's PII and secret scanner is regex-based and costs zero tokens, so there is no reason not to run it on every artifact. It flags nine categories: SSN, financial, api_key, passport, address, person, dob, email, and phone. On a dashboard you expect person and email. If ssn or financial comes back, the artifact is Tier 3 and the conversation is over until you redact.
2. Read the titles and headings. The scanner reads values, not implications. "Renewal risk" is fine. "Accounts flagged for financial hardship" is a promotion to Tier 3 even if every cell is clean.
3. Check the free-text columns. Notes fields are where health, legal, and family details hide. Either drop the column or accept the tier it forces.
4. Apply the tier's settings and publish. Tier 2 here: password on, expiry at 14 days to cover the review cycle, retention at 90 days, one link per recipient so the analytics tell you who actually opened it.

If your team generates these artifacts from an AI tool, the same four steps run through the API or MCP: scan_html before create_link, with the tier's password and expiry passed in the same call. On Teams and Enterprise you can layer your own Anthropic, OpenAI, or Google key on top for an AI scan pass — useful precisely for the context problem, because a model reads "Bankruptcy_Watchlist" and a regex does not. You supply the key and pay for those tokens; HTMLvault funds none of them.

Limits and caveats

A tiering model is a decision aid, not a legal opinion. Four things to keep honest about it:

Regex finds patterns, not meaning. A nine-digit number matches an SSN pattern whether or not it is one, and a diagnosis written in plain prose matches nothing. Pattern scanning is a floor under human review, never a replacement — the same trade-off covered in what discovery tools scan and what they miss.

Jurisdiction moves the line. GDPR's special categories, US state privacy laws, HIPAA, and sector rules all draw slightly different boundaries. This model is deliberately stricter than most of them so it stays portable; where your counsel says otherwise, counsel wins.

Aggregation defeats anonymization. Three Tier 1 documents can combine into a Tier 2 identification. If a "region + industry + headcount" table has exactly one row matching a company everyone can name, it is not PII-free data.

Tiers decay. A proposal that was Tier 2 in March may sit in a Tier 1 template library by June with the buyer's name still in it. Expiry handles that automatically, which is the main argument for setting one even when the content feels harmless — more on the mechanics in creating expiring links.

Why this matters for the person doing the classifying

The reason PII vs SPII feels slippery is that most teams try to settle it per artifact, in the last five minutes before something goes out, with whoever happens to be online. That produces inconsistent decisions and a quiet accumulation of links nobody remembers publishing.

A three-tier model with fixed settings changes the job. The RevOps lead assembling the lead list, the marketer shipping the campaign page, the rep sending the proposal at 11:47 p.m. — none of them has to decide what "sensitive" means anymore. They classify once, apply the matching posture, and the link enforces it: password on Tier 2, auto-delete retention on anything Tier 3 that has to move, and an audit trail either way that IT can read without asking anyone what they were thinking. That is a policy you can apply on a Tuesday afternoon, without a lawyer in the room, and defend later without a meeting.