Table and column map
Represent Snowflake databases, schemas, and tables in a registry that compliance teams can use without digging through warehouse internals.
PII discovery and deletion proof for Snowflake.
Chameleon maps Snowflake warehouse assets so data teams can map tables and columns, connect PII policy, record findings, and support deletion proof workflows — the same registry and proof model as BigQuery, on your Snowflake account.
Policy context
Connect warehouse policy, dbt metadata, and deletion strategy to the resources that hold customer data.
Proof path
Use Snowflake status and evidence as part of the broader deletion proof surface.
Deleting a row in Snowflake doesn't delete the data.
Snowflake keeps prior versions of table data through Time Travel (configurable up to 90 days on Enterprise and above) and then a further, mandatory 7-day Fail-safe period that applies even after Time Travel expires. A DELETE also only touches the one table you ran it on — it doesn't reach the staging tables, dbt marts, and zero-copy clones that already hold the same personal data.
Zero-copy cloning compounds this: a CREATE TABLE ... CLONE shares the underlying micro-partitions of the source table at clone time, so a clone taken before a deletion request keeps the original data completely untouched by anything you do to the source afterward. So the naive approach — run a DELETE on the users table — leaves the customer's data readable in Time Travel, in Fail-safe, in every clone, and in any derived table, while producing no evidence that anything happened. For an Article 17 obligation, that is a gap, not a solution.
Encrypt on write, shred the key on request.
Chameleon maps your Snowflake databases and schemas into a registry and pairs each PII column with a deletion strategy. Personal fields are encrypted with a per-user key before they land in the warehouse, so every copy that propagates through staging, marts, and clones holds ciphertext, not plaintext.
When a deletion request arrives, Chameleon destroys the per-user key in Cloud KMS. Every encrypted copy in every Snowflake table — plus anything sitting in Time Travel, Fail-safe, or a zero-copy clone — becomes unreadable at once, and the operation emits a signed certificate as evidence. One KMS call replaces a fleet of DELETE statements you would otherwise have to find, run, and prove.
01 / Scope
Define the Snowflake databases, schemas, and tables that belong in the customer-data compliance loop.
02 / Map
Track PII columns, classification, owner, and deletion strategy for each relevant resource.
03 / Detect
Record ghost-data findings from configured scans and route them for registration or cleanup.
04 / Report
Show Snowflake deletion status alongside SaaS receipts and proof evidence.
warehouse: Snowflake
database: CHAMELEON_DEV
registry: raw_users, stg_users, mart_customer_metrics
proof_status: key_destroyed
database: CHAMELEON_DEV
registry: raw_users, stg_users, mart_customer_metrics
proof_status: key_destroyed
Common questions
How do you delete PII in Snowflake for GDPR?
You can run DELETE statements, but they leave copies in Time Travel, the mandatory Fail-safe period, and any zero-copy clones taken before the delete, and they produce no evidence. A crypto-shredding approach encrypts PII with a per-user key on write and destroys that key on request, which renders every encrypted copy — including Time Travel, Fail-safe, and clones — unreadable in a single operation and produces a proof certificate.
Does Snowflake Time Travel and Fail-safe keep deleted personal data?
Yes. Time Travel retains prior versions of table data for a configurable window (up to 90 days on Enterprise and above), and Fail-safe adds a further mandatory 7-day retention period after that, during which Snowflake can still recover the data. Crypto-shredding avoids this problem because the retained versions hold ciphertext that is worthless once the key is destroyed.
What about zero-copy clones made before a deletion request?
A clone taken before you delete a row shares the source table's micro-partitions as they existed at clone time, so it keeps the original data regardless of what happens to the source afterward. Because Chameleon encrypts on write, a clone only ever contains ciphertext — destroying the per-user key makes the clone's copy unreadable too, with no separate cleanup step per clone.
Does Chameleon need to move data out of Snowflake?
No. Chameleon maps your existing Snowflake databases, schemas, and tables into a registry and coordinates encryption and key destruction. Your data stays in your warehouse; Chameleon manages the policy, the deletion strategy, and the proof.
A practical walk-through of why DELETE falls short in Snowflake and how crypto-shredding deletes and proves in one call.
How model lineage tells Chameleon which downstream Snowflake tables inherit PII from upstream sources.
The certificate that turns a Snowflake key-destruction event into audit-ready evidence.