What Is PII Privacy and Why It Matters

Personally identifiable information (PII) is any data that can identify a specific person, either on its own or combined with other information that is reasonably available. PII privacy is the practice of keeping that data from being exposed, mishandled, or shared beyond its approved use.

For sales, marketing and RevOps teams, most of that practice happens at the moment something gets shared. A proposal, dashboard or AI-generated page inherits whatever personal data its source held, and a link travels further than an attachment ever did. One example runs through this guide: a lead list exported from a CRM and turned into an HTML page by an AI tool.

What is PII privacy? Linked, linkable, and the terms laws use

PII privacy covers the policies, controls and handling habits that protect personal data from unauthorized access, disclosure or misuse. In practice it is the difference between knowing a field is sensitive and having a workflow that stops it leaving the building. Mature teams build it into how they share, not into a policy document in a folder named Final_Final_Approved_v7.

Two clauses in the definition do the work. "Identify a specific person" rules out genuinely aggregate data: a count of visitors from Ohio identifies nobody. "Combined with other information" rules the aggregate back in when the count is one person from a town of 400 who also appears in your CRM.

The US National Institute of Standards and Technology (NIST) calls these linked and linkable information. Linked data is already tied to a person, like a name attached to an account number. Linkable data could be tied to one through a further step, such as cross-referencing a public record or another dataset you hold. Both are in scope, and teams forget the second because each linkable field looks harmless alone.

That gives you the linkability test: what else would someone need to turn this into a person, and how hard would it be to get? If the answer is "our own lead list, which is attached to this same email," the field is PII.

Laws use different words for the same idea. EU and UK data protection law says "personal data," which is broader than the American term and explicitly includes online identifiers. Most US state privacy laws say "personal information," US healthcare regulation says "protected health information" for the medical subset, and security frameworks say PII. Treat them as one question asked in four dialects: can this reach a person?

Direct, quasi and sensitive: a field reference grouped by damage

An alphabetical list of fields tells you what PII is. Grouping the same fields by what an outsider could do with them tells you how to handle each one.

• Direct identifiers name one person with no joining required: full name, personal email, mobile number, home address, a signature image in a proposal footer, an employee ID.
• Quasi-identifiers name one person only in combination: job title, employer, city, date of birth, an internal CRM ID. Technical identifiers belong here too: an IP address, a device or advertising ID, a cookie ID. They never look like a name, yet GDPR counts online identifiers like these as personal data, and a session token is worse than an identifier because it is a live credential.
• Sensitive data does harm beyond identification: government IDs, card and bank account numbers, health information, biometrics, precise geolocation, and protected characteristics such as religion, ethnicity, union membership and sexual orientation.

Damage scales with joinability and irrevocability. A session token can be revoked; a date of birth or a biometric cannot. The internal customer ID is the field most teams underrate: it looks like a database artifact, but it is a stable key that joins two harmless exports into a full profile.

When ordinary PII becomes sensitive (SPII)

Sensitive personally identifiable information (SPII) is the subset whose exposure causes concrete harm: fraud, discrimination or physical risk, not spam or embarrassment. PII is defined by identifiability; SPII is defined by the consequence of exposure. A leaked work email costs someone a few phishing attempts. A leaked SSN costs them a year of their life.

Because SPII is about consequence, context can promote ordinary PII into it, usually by accident:

• A spreadsheet tab called "Bankruptcy_Watchlist" turns names and companies into financial-distress data about identified people. Every cell is ordinary; the tab name is not.
• An event attendee export carries a dietary requirements column, often a proxy for religion or a medical condition.
• A churn dashboard has a free-text notes column where a rep wrote that the champion is on medical leave.

So classify the document, not the column. Ask what a stranger could infer about a named person from the whole artifact, including its title, headings, tab names and footnotes, and classify at the highest inference it supports. That yields three tiers:

1. Non-personal. Nobody is identifiable, alone or in combination: pricing tables, product one-pagers, aggregate metrics. Test the claim rather than assume it; a regional breakdown with one customer in a region is not anonymous.
2. PII. People are identifiable and exposure causes nuisance rather than harm: lead lists, attendee rosters, a proposal addressed to a named buyer.
3. Sensitive. Exposure causes direct financial, medical, legal or physical harm: any document holding a field from the sensitive group, or a PII document that context has promoted.

Jurisdiction moves the line at the edges. GDPR's special categories, US state laws, HIPAA and sector rules each draw it slightly differently. These tiers are deliberately stricter than most, so they travel; where your counsel draws the line elsewhere, counsel wins.

Is an email address PII? Three variables, five cases

Usually, yes. An email address that points to a specific person is personal data under GDPR, work addresses like jane.doe@example.com included, because it identifies her and reaches her. NIST's guidance and US state laws such as California's count email addresses too. Even an opaque address like b7k22@example.com is a unique key that joins to a marketing database, a breach list or your own CRM.

Three variables adjust that default:

• A person's inbox or a role inbox. jane.doe@ identifies a human; sales@ or billing@ identifies a function. A role inbox shared by a team is usually not personal data, unless only one person reads it: founder@ at a six-person startup is effectively a name.
• Jurisdiction. GDPR asks whether data relates to an identifiable person, so any named address qualifies, work or personal. If anyone in your file is in the EU or UK, work to that standard.
• Adjacent fields. Alone, an address lets someone send a message. Next to a company, a job title and an open deal value, the row shows which buyer is about to spend how much. The risk comes from the row, not the cell, so dropping columns the reader doesn't need usually beats debating the email itself.

Hashing is the case teams get wrong. A SHA-256 hash of an email is pseudonymous, not anonymous: anyone holding the original address can hash it and get a match, which is how ad audience matching works. GDPR still treats the hash as personal data.

Customer PII, the same fields belonging to buyers and their staff, often arrives under a data processing addendum that demands more care than any statute. A customer's work email can be a contractual problem in a shared page even where the law would let it pass.

Where PII hides in AI-generated pages

AI-generated pages carry PII more often than teams expect, and the prompt is usually the source, not the model. People paste exports into prompts, connect CRMs and ask for personalization, and the result inherits everything the source held while reading like a finished asset.

In the worked example, a sales lead asks an AI tool for a page of this week's 180 inbound leads showing company, contact, source and score. The page shows four columns. The HTML can hold much more:

• Data in a <script> tag. The biggest offender. A chart draws twelve points while the JSON behind it holds every row and every column of the export.
• Hidden columns. A cell hidden with CSS is still in the page, readable in any browser's inspector.
• Tooltips and data- attributes. Hover text and attributes such as data-owner often carry the email or account ID a value came from.
• mailto: and tel: links. A contact link on every row is 180 live identifiers.
• Alt text and file names. signature-j-doe-final.png is a name and a document type in one string.
• The title and preview tags. The <title>, og:title and og:description become the preview card when the link is pasted into Slack or email, so a customer's name there travels wherever the link does. A password-protected, expired or removed HTMLvault link unfurls without the page's own preview.
• Comments and debug output. AI tools leave notes like "swap test row for real customer" and park raw API responses below the fold. HTMLvault drops HTML comments when it stores a page; the same file sent as an email attachment keeps them.

Teams spot secrets like API keys faster than personal data, because a token looks dangerous and an email address in a tidy table looks normal. That is why generated HTML deserves its own review step, one that reads the markup rather than the rendered page.

On HTMLvault, every publish and every edit is checked against the account's PII and secret-scanning policy, and every outside URL in the page against Google's unsafe-URL lists. The PII check is regex pattern matching, so it costs zero tokens, and it reads the whole document, script bodies and attributes included. A refused publish returns the findings instead of a URL.

To check before publishing, an AI tool calls the scan_html MCP tool and fixes what it flags before calling create_link. The REST API has no separate scan endpoint; a publish from Zapier, Clay or a script is checked as it publishes. A large page built in append mode runs no checks until the last append_html call finalizes it with finalize: true.

Fix by deleting rather than hiding. Trim the JSON to the columns the charts use, drop the data-owner attributes and the hidden column, then publish again. Triage by group, not hit count: forty email hits in a mailto list is one decision, and one SSN hit is an escalation.

Regex has two error modes. It flags a nine-digit order number as a possible SSN, and it misses "the buyer at the regional distributor who filed the complaint in March," which identifies someone just as well to anyone who knows the account. That gap is why an AI layer exists as an option on top. Teams and Enterprise can connect their own Anthropic, OpenAI or Google key to run an AI scan on a link after it is published, billed to that key. Human review still has a job.

One sharing posture per tier: redact or restrict

Once a document is classified, the sharing decision should already be made. Write one posture per tier and stop relitigating it per deal.

• Non-personal: a plain tracked link, with whatever expiry suits the content.
• PII: if this reader doesn't need the personal fields, redact. Drop the columns or swap addresses for account names; this is where redaction earns its place, because the useful version of a page usually survives losing the inbox column. If the personal data is the point, restrict: keep it and lock down the link.
• Sensitive: remove the fields. No business reason puts a credential, a health note or an SSN in a proposal or a lead list, and a password does not create one.

Restricting comes down to four settings, and every link is never indexed whatever the tier:

• Password. Set on the web, in the upload form or the links dashboard. MCP create_link and the REST API cannot set one, so when an AI tool publishes the page, add the password in the dashboard before you send the URL.
• Expiry. On Pro and above, links take a configurable expiry in fixed steps, from 1 hour to 30 days, 1 year or never; Free links expire after 30 days. An expiry can be changed or extended after sending, so a slipped close date doesn't need a new URL. For picking the number, see choosing a window that matches the deal.
• One link per recipient. Each rep gets a separate tracked link, so views and scroll depth show who opened it, and a forward shows up as an extra viewer on one rep's link.
• Retention. Unlike expiry, retention windows are not set per link. Retention is one setting for the whole account (for an org member, the org owner's): 7 days to 2 years on paid plans, 7 to 90 days on Free, counted from each link's expiry. When it runs out, the content and its per-visitor view data are deleted. It cannot be set through MCP or the API.

Worked example. The 180-lead page from the example above has two audiences: the Monday pipeline review and the reps who will work the list. Build two links from the one export. The leadership version drops email and title, keeps counts, stages and deal sizes, and ships once the publish check returns no email findings, so it can be forwarded without exposing a single inbox. The rep version keeps every column and goes out as one password-protected link per rep with a 7-day expiry.

PII compliance as four obligations

PII compliance gets discussed as a legal topic and audited as an operational one. A customer's security questionnaire doesn't ask anyone to recite a regulation; it asks what happened to a specific file, who saw it and when it went away. Strip away the differences between regulations and four obligations remain:

1. Know what you hold. Most exposure in sales and marketing is accidental, like a name and email that rode along in an export. A check on the artifact at the moment of publication catches it before the first copy exists, where discovery tools scanning databases find it weeks later.
2. Minimise what you share. Fewer fields, shorter lives. The safest record is the one never put in the page; the next safest sits on a link that expires. Data minimization in practice covers doing it without slowing a deal.
3. Control access at the link. A password, an expiry, a link per recipient, and no search indexing on any link. SSO/SAML (Enterprise, or an add-on on Teams) decides who can sign in to HTMLvault and publish, so an offboarded employee loses access when the identity provider says so; it never restricts who can view a link. Sign-in uses one-time email codes, passkeys, Google or Apple, never account passwords.
4. Prove what happened. To an auditor, a control you can't evidence is a control you don't have, so be exact about the record. The PII audit log holds one scan event per publish or edit. Analytics hold views, unique and repeat visitors, geography, device and referrer until retention deletes them. The link itself shows its expiry and whether it has a password. There is no log of access changes, expiries, deletions or retention changes.

Worked example: the customer-story microsite, one year later. Marketing publishes a microsite about a named customer, with logo, quotes, two named contacts and revenue figures the customer approved, for prospects in active deals rather than the open web.

• At publish. The check flags the contacts as person and their work emails as email. Marketing confirms both are in the approved release, then publishes from the web upload form with a password and a 1-year expiry. The PII audit log records that scan, and one more for each later edit.
• During the campaign. Analytics record views, geography and referrer. That is engagement data and access data at once: a run of views from a country where the team has no deals answers "was this seen outside the audience?" better than an opinion.
• At one year. The link stops opening. The content and its per-visitor view data remain until the account's retention window, counted from that expiry, runs out; then both are deleted.
• When the questionnaire arrives. Inside the retention window, IT can show the scan events, the settings, and where the views came from. There is no log entry for the expiry or the deletion, so IT answers those from the expiry date and the retention setting. If the view data must outlive the window, IT pulls it (with get_analytics or from the dashboard) before the window closes.

Over-claiming on a questionnaire is its own compliance problem, so answer with what the record holds. Which data counts as regulated for your business, and how long you must keep records, is your counsel's call; these controls are how you carry out the answer.

Common mistakes teams make with PII

PII mistakes in sales and marketing rarely look like a breach. They look like a shortcut taken on a deadline.

• A lead list in a paste tool. Someone needs to show a colleague 400 rows and reaches for the fastest thing open. The result can be a public URL holding names, titles, employers and work emails, with no expiry and no record of who read it. Public links, inbox attachments and unsecured previews are convenient, and convenience without controls tends to become an incident report.
• A proposal forwarded outside the account. The rep sends a link to a champion, who forwards it to a peer at another company evaluating the same category. Nothing was hacked; the pricing and customer references simply travelled. A password turns the silent forward into friction, and a per-recipient link makes it visible.
• A key left in a demo. Generated HTML helpfully includes a working API key so the demo runs, which hands a stranger a path into your systems and hands you a rotation project. The publish check catches common key formats; an unusual one still needs a human look.
• Treating drafts as low risk. Drafts hold the worst content: raw exports, unreviewed prompts, placeholders and copied records.
• Guarding only the regulated fields. Teams protect SSNs scrupulously and still expose the names, emails, phone numbers and internal IDs that phishing runs on.
• Letting "it depends" stand in for a standard. A gated prototype with test addresses is not a customer-facing page built from live CRM data. But a workflow that regularly handles names, emails or account data needs a written rule, not a fresh debate per page.
• Pretending the controls are free. Passwords add a step, expiry takes forethought, and a review gate can slow a launch by an afternoon. That friction is the price; the alternative is a page that spreads further than anyone intended and goes unnoticed for nine months.

For whoever owns the CRM export, PII privacy now takes about as long as renaming a column. The publish check shows which fields reached the page, the tiers say whether they count, and the only decision left is whether this reader gets the redacted link or the restricted one.