PII compliance — the practice of handling personally identifiable information in a way you can defend — gets discussed as a legal topic and audited as an operational one. Nobody asks your team to recite a regulation. They ask what happened to a specific file, who saw it, and when it was deleted. This guide is written for the person who has to answer that: RevOps leads, marketing ops, and the IT stakeholder who signs off on the tools sales uses. It is operational guidance, not legal advice; your counsel owns the interpretation, you own the evidence.
The four obligations underneath every privacy regulation
Regulations differ in scope, penalties, and definitions. Strip those away and the operational demands converge on four things. Build for these and you are broadly ready for whichever framework applies to you.
- Know what personal data you hold. You cannot protect data you have not noticed. Most PII exposure in sales and marketing is accidental — a name and email that rode along in a CRM export, a home address in a case study draft.
- Minimise what you share. Every copy is a liability with a lifespan. The safest personal data is the record you never put in the shared artifact, followed closely by the one that deleted itself on schedule.
- Control who can access it. Access is not a property of the file; it is a property of the link, the identity behind it, and how long both remain valid.
- Prove what happened. A control you cannot evidence is, to an auditor, a control you do not have. This is the obligation teams skip and then fail on.
The rest of this guide maps each obligation to a concrete control you can turn on this week. The mapping matters more than the tooling: if you use something other than HTMLvault, ask it these same four questions.
Obligation 1: know what you hold, before you publish it
Discovery scanning usually runs against databases and file stores — data at rest, found weeks after it landed there. That is useful and it is also too late for a proposal that went out on Tuesday. The more useful control is scanning at the moment of publication, on the artifact itself.
HTMLvault scans HTML before a link goes live and flags nine categories: SSN, financial data, API keys, passport numbers, addresses, person names, dates of birth, email addresses, and phone numbers. The scanner is regex-based, which has two consequences. It costs zero tokens and adds no per-scan spend, so you can run it on everything without a budget conversation. And it matches patterns, not meaning — it will catch a formatted account number and miss a sentence that describes a customer's medical situation in prose.
Teams and Enterprise customers can layer an AI scan on top by connecting their own Anthropic, OpenAI, or Google API key. That layer catches contextual disclosure the regex pass cannot. It runs on your key and your tokens; HTMLvault does not fund them. If you are evaluating this class of tooling more broadly, what discovery tools scan and what they miss is the longer version of this argument.
Obligation 2: minimise — fewer copies, shorter lives
Minimisation in a go-to-market context is mostly about lifespan. A proposal does not need to be reachable in perpetuity; a campaign microsite does not need to outlive the campaign by three years. Two independent settings do this work, and teams routinely confuse them.
- Link expiry controls how long the link resolves. Configurable from one hour to never on Pro and above; Free links expire at 30 days.
- Data retention controls how long HTMLvault keeps the content and its analytics after that. Pro and above configure this from auto-delete through two years; Free retains 90 days.
Expiry is an access control. Retention is a data-lifecycle control. An expired link with a two-year retention window still means the data exists — which is fine if your policy says so and indefensible if it does not. Set both deliberately. The data retention window and expiring links guides cover the mechanics of each.
The practical default for anything containing customer data: expiry matched to the deal or campaign cycle, retention set to the shortest window your audit obligations tolerate. Then stop thinking about it, because the control runs whether or not anyone remembers.
Obligation 3: control access at the link, not in a policy document
Access control for shared artifacts has four moving parts, and each closes a distinct failure mode.
- Password protection stops a forwarded URL from being a granted permission. Add it to any link whose audience is a named account rather than the public.
- Never indexed is the default on every HTMLvault link, not an option to remember. Search engines do not crawl them, so a customer-story page cannot surface in results for the customer's own name.
- SSO/SAML ties who can create and manage links to your identity provider, so an offboarded employee loses access when HR closes the ticket, not when someone remembers. It is a paid add-on on Teams and included in Enterprise. HTMLvault has no email-and-password login at all by design — sign-in is Magic Auth and passkeys.
- Custom roles separate the person who can publish externally from the person who can only draft. Available on Teams and above.
The distinction that matters to a reviewer is between a link that is merely hard to guess and one that is genuinely gated. Public links vs controlled access walks the difference; SAML SSO for sharing tools covers the identity side.
Worked example: the customer-story microsite, one year later
Marketing publishes a microsite featuring a named customer — logo, quotes, two named contacts, and revenue figures the customer approved for release. Twelve months later, IT is answering a questionnaire and needs to show who viewed it and that it was destroyed on schedule. Here is what makes that answerable.
At publish. The page is scanned; the two named contacts flag as person and their work emails as email. Marketing confirms both are in the approved release, records that decision, and publishes. The link gets a password, a twelve-month expiry, and a retention window of thirty days past expiry. Because publishing happened through a role that permits external links, the audit log records who did it.
During the campaign. Per-link analytics record views, unique visitors, geography, and referrer. That is engagement data, and it is also access data: it answers "was this seen outside the intended audience" with something better than an opinion.
At the twelve-month mark. The link stops resolving. Thirty days later, the content is deleted under the retention window. The audit log entry for the deletion survives the content — that is the point of separating the two.
When the questionnaire arrives. IT exports the audit log and the per-link access record: created by whom, on what date, with which controls, viewed this many times from these regions, expired on this date, destroyed on that one. Audit logs and custom roles are Teams and above; on Free or Pro you will have the analytics but not the administrative trail. The audit trail guide details what each entry contains.
Three common PII violations and what they cost
A PII violation in a sales or marketing org almost never looks like a breach in a headline. It looks like a shortcut on a deadline. Three recur.
A lead list pasted into a public paste tool. Someone needs to show a colleague 400 rows of prospect data and reaches for the fastest thing available. The result is an indexable URL containing names, titles, employers, and work emails, with no expiry and no record of who opened it. The cost is not a fine so much as the inability to answer any question about it afterward — you cannot un-publish what a crawler already has, and you cannot enumerate who read it. This is the case for choosing a pastebin alternative deliberately rather than by habit.
A proposal forwarded outside the account. The rep sends a link to a champion; the champion forwards it to a peer at another company who is evaluating the same category. Nothing was hacked. The pricing and any embedded customer references simply travelled. Password protection turns this from a silent event into a friction point, and per-link analytics turn it from invisible into visible.
An API key in a demo page. Generated HTML is very good at helpfully including a working key so the demo actually runs. A live credential in a shared page is a direct path into a system, and the cost is measured in rotation work and incident paperwork. Pre-publish scanning catches the common key formats; scanning HTML for API keys covers what the scanner looks for and how to handle a hit.
The pattern across all three: the damage is mostly in the not-knowing. Scanning prevents the first copy, expiry limits the window, and logging means the answer to "what happened" is a record rather than a reconstruction.
Limits, caveats, and plan boundaries
Be precise about these when you fill in a questionnaire, because over-claiming is its own compliance problem.
- Regex is pattern matching. The nine-category scanner is fast, free, and literal. It will not catch personal information described in prose. The BYOK AI layer on Teams and Enterprise narrows that gap; nothing closes it entirely.
- Plan boundaries are real. Audit logs and custom roles start at Teams. SSO/SAML is a paid add-on on Teams and included in Enterprise. Free caps expiry at 30 days and retention at 90.
- Analytics are access evidence, not identity evidence. Views, geography, and device tell you a link was opened, not by which named individual. Pair them with password protection when you need the audience constrained.
- Retention outlives expiry unless you set it not to. Check both fields. This is the single most common misconfiguration.
- This is operational guidance. Which categories count as regulated PII for your business, and how long you must keep records, is a question for your counsel. The controls here are how you implement their answer.
What this gives the person answering question 14
The gap in most go-to-market PII security programs is not intent. Sales and marketing teams are not careless about customer data; they are working in tools that keep no record, so their care leaves no trace. Every good decision — the field that was removed, the link that was retired, the page that was never indexed — evaporates the moment someone asks for proof.
Closing that gap means the rep can send a proposal that expires on its own, without a policy conversation before every send; the marketer can publish a page featuring a real customer knowing it will not surface in a search for that customer's name; and the RevOps or IT lead holding the questionnaire can answer question 14 with an export instead of a search through inboxes. That is the whole ambition of PII in data privacy terms: not fewer shared links, but shared links that can account for themselves.