Shadow data is governed data that has been copied somewhere your governance does not reach. The record in your CRM is protected — access-controlled, logged, retained on a policy someone signed. The CSV export of that record sitting in a Downloads folder is not. Neither is the version pasted into an AI chat, nor the HTML table it produced, nor the link that table was shared as.
Most teams do not lose customer data because they misunderstand what PII is. (If you want the taxonomy, the PII privacy primer covers it, and PII vs SPII covers the sharper line.) They lose it because governance stops at the system of record, and the data does not. This guide walks the flow — source, extraction, generation, distribution, recipient-side persistence — and names the specific control that belongs at each stage.
Why shadow data forms in the first place
Sensitive data sprawl is not a discipline problem. It is the predictable output of a workflow where the governed system is the worst place to do the actual work.
A rep cannot present a CRM view to a partner. A RevOps analyst cannot get a board-ready chart out of a report builder. A marketer cannot preview a campaign page from inside the marketing automation tool. So each of them extracts — and the moment data leaves the system of record, it loses everything that system was providing: field-level permissions, row-level access, audit logging, retention rules, deletion-on-request.
The copy keeps the sensitivity. It just loses the controls.
AI tools accelerate this considerably. "Turn this CSV into a clean HTML table" is a genuinely good use of an LLM, and it is also an instruction to take governed data, hand it to a third party, and receive back an ungoverned artifact you are about to send to someone outside the company. The output is a file with no owner, no expiry, and no record of who opened it. If the artifact in question is a chat-tool canvas rather than a file, the anatomy of a Claude artifact is worth understanding before you share the URL it came with — including what deleting one actually removes.
Stage 1 — Source systems: minimise at the query, not after
The control: field-level data minimization.
Data minimization means exporting the fields the task requires and no others. It is the cheapest control in this entire guide because it is the only one that prevents shadow data rather than managing it. A column you never exported cannot leak.
In practice this is a habit, not a product:
- Build a saved export view per use case — "partner territory view," "QBR summary view" — rather than exporting the default object and deleting columns later.
- Strip direct identifiers when a stable key will do. Partners rarely need a personal mobile number; they need an account ID and a company name.
- Push aggregation upstream. If the recipient needs counts by region, export counts by region.
- Write the minimisation rule into the CRM role, so the export is narrow even when the person exporting is in a hurry.
Most teams discover they were exporting date of birth, personal email, and home address into a partner file purely because those fields were adjacent in the object. The field-by-field cost breakdown is a useful worksheet for deciding what earns its place in an export, and the four obligations that actually get audited explain why the narrow export is the one you can defend.
Stage 2 — Extraction and AI generation: scan before it becomes a link
The control: pre-publish scanning, regex first, AI second.
Once data is in a file or a chat window, minimisation is over — you can only inspect. The inspection has to happen at the last controllable moment, which is the point of publication, because that is the only moment when the artifact is complete and someone is still holding it.
HTMLvault scans HTML at that moment. The regex scanner runs on every link, on every plan, and costs zero tokens — it never calls a model. It detects nine categories: SSN, financial account numbers, API keys, passport numbers, physical addresses, person names, dates of birth, email addresses, and phone numbers.
You can run it before you publish anything, via the scan_html MCP tool or the REST API:
POST /api/v1/scan
{
"html": "<table>...</table>"
}Teams and Enterprise plans can add a BYOK AI layer on top — you connect your own Anthropic, OpenAI, or Google API key, and an AI pass catches what patterns miss: a free-text note describing a health condition, a name in a sentence rather than a name column. HTMLvault funds no tokens for this; the spend is yours and visible on your own provider bill, which is usually what makes it approvable.
Regex is deterministic and free, so it runs always. AI is probabilistic and metered, so it runs where judgment is required. Neither is a substitute for the other; the scanner buyer's guide compares the two failure modes directly, the evaluation guide for discovery tooling covers what each class of scanner reliably misses, and the secret scanning workflow shows where the check belongs in a publishing routine.
Stage 3 — Distribution: give the copy an owner and an expiry
The control: access control, expiry, and audit logs on the artifact itself.
This is the stage most PII data governance programmes skip entirely, because the artifact does not look like a system. It is "just a file." But a file with sensitive data in it is a system of record for as long as it exists — it just has no administrator.
Publishing through a controlled link re-attaches the controls the export dropped:
- Access control. Password protection, or per-recipient links so each partner contact gets a distinct URL. See the security controls overview for how to choose.
- Expiry. A window that matches the deal, not the calendar. Free links expire at 30 days; Pro and above are configurable from one hour to never.
- Retention. Separate from expiry: retention governs how long HTMLvault keeps the content and its analytics. Free is 90 days; Pro configures from auto-delete up to two years, as the retention guide lays out. For material that should leave no trail at all, the auto-delete retention window is the setting to reach for.
- Never indexed. Links are excluded from search indexing by default, so a territory list does not turn up in a search result six months later.
- Audit logs. On Teams and Enterprise, with custom roles — so Compliance can answer "who shared what, when" without a Slack archaeology project.
The expiry window guide is worth reading alongside this: the most common mistake is setting expiry generously "just in case," which quietly recreates the permanent copy you were trying to avoid. The same logic is why a link beats an attachment for anything containing customer records — an attachment has no expiry setting at all.
Worked example: a territory lead list shared with a partner
A channel partner needs the accounts in their territory. The classic version of this task produces an XLSX in an email thread that will outlive the partnership. Here is the controlled version.
1. Minimise at the query. Export account name, account ID, region, tier, and renewal quarter. Not contact mobile, not personal email, not the notes field.
2. Generate. Ask your AI tool to render the CSV as a sortable HTML table. Via the MCP server, the same conversation can create the link — create_draft_link gives you an unpublished draft to review first. If you would rather drive it from your own scripts, the REST API exposes the same operations against an API key you can revoke.
3. Scan. Run scan_html. Suppose it flags four email matches and one phone: a lingering "primary contact" column nobody noticed in the source view. Fix the export, regenerate, rescan. That return path — scan back to generation, then forward again only once it is clean — is the entire point of a draft.
4. Publish with controls. Expiry set to 90 days — the length of the co-selling period. Password protection on. Retention set so the content auto-deletes at expiry rather than sitting in the account. If you use a controlled sharing setup on your own white-label domain, the link resolves on your domain, which matters more than it sounds: partners forward branded links to their own teams less casually than they forward attachments.
5. Watch it. Per-link analytics tell you the list was opened seven times by four unique visitors in two countries. If the partner has one office in one country, that is a conversation, and you have the evidence to start it. Tracking viewer engagement securely covers what those signals do and do not prove.
Stage 4 — Recipient-side persistence: the limits of every control here
Be honest with your security stakeholders about where this stops, because they will find the boundary anyway.
- A viewed page can be copied. Expiry, passwords, and retention govern the hosted copy. They do not govern a screenshot, a print-to-PDF, or a recipient pasting the table into their own spreadsheet. Controls reduce the number of copies and give you a record of access; they do not make data unrecallable.
- Regex scanning is pattern-based. It will not recognise a sensitive fact expressed in prose. That is what the BYOK AI layer is for, and even that is probabilistic — neither is a compliance guarantee, and neither replaces a human reviewer on genuinely high-risk material.
- Scanning is not a substitute for minimisation. A scanner that flags twelve items on every publish trains people to click through. If your scans are consistently noisy, fix the export, not the threshold.
- Analytics are attribution, not identity. Views, geo, device, referrer, scroll depth, and time-on-page describe access patterns. They do not tell you a named individual opened a page, and you should not describe them to a compliance team as if they do.
- Governance needs the account layer too. Custom roles and audit logs come with Teams; SSO/SAML is a paid add-on there and included with Enterprise. Without SSO, offboarding a rep and revoking their share history are two separate chores.
Putting it on a policy page
The shortest usable version of this, for a data-handling standard someone actually reads:
- Export the minimum fields. Saved views per use case, not the default object.
- Scan every generated artifact before publication. Regex always; AI scanning for free-text-heavy material. A flagged artifact goes back to generation, not on to the recipient.
- Publish sensitive content as a controlled link, never as an attachment — access control on, expiry matched to the business reason, retention set to delete.
- Review access analytics for anything containing customer data, and treat an unexpected geography as an incident signal, not a curiosity.
- Keep the audit trail in a system with roles and logs, so the answer to "who shared this" takes a minute, not a week.
None of this is exotic. It is the governance your system of record already applies, extended to the copies — which is where sharing without losing control actually happens, and what a private publishing workflow is for. If the generated artifacts come from several people rather than one analyst, monitoring team AI publishing is the next control up.
For the analyst who builds the export, that adds up to one specific relief: you can hand a partner a real list without becoming its permanent custodian. The copy you publish has an owner, a clock, and a record of every open — so when someone asks in six months where that territory file ended up, the answer is a timestamp, not a search of your Downloads folder.