Table and column map
Represent BigQuery resources in a registry that compliance teams can use without digging through warehouse internals.
PII discovery and deletion proof for BigQuery.
Chameleon starts with BigQuery warehouse assets so data teams can map tables and columns, connect PII policy, record findings, and support deletion proof workflows.
Policy context
Connect warehouse policy, dbt metadata, and deletion strategy to the resources that hold customer data.
Proof path
Use BigQuery status and evidence as part of the broader deletion proof surface.
Deleting a row in BigQuery doesn't delete the data.
BigQuery keeps deleted and changed data in time travel for up to seven days, and often in a fail-safe window beyond that. A DML DELETE is also billed against the whole table's data and can be slow at scale — and it only touches the one table you ran it on, not the staging tables, dbt marts, and exports that copied the same personal data downstream.
So the naive approach to a deletion request — run a DELETE on the users table — leaves the customer's data readable in time travel, in every derived table, and in any snapshot, 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 BigQuery datasets 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 and marts holds ciphertext, not plaintext.
When a deletion request arrives, Chameleon destroys the per-user key in Cloud KMS. Every encrypted copy in every BigQuery table — plus anything sitting in time travel or a snapshot — 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 BigQuery datasets, tables, and models 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 BigQuery deletion status alongside SaaS receipts and proof evidence.
warehouse: BigQuery
dataset: chameleon_dev
registry: raw_users, stg_users, mart_customer_metrics
proof_status: key_destroyed
dataset: chameleon_dev
registry: raw_users, stg_users, mart_customer_metrics
proof_status: key_destroyed
Common questions
How do you delete PII in BigQuery for GDPR?
You can run DML DELETE statements, but they are slow at scale, leave copies in time travel and downstream tables, and 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 copies in time travel and snapshots — unreadable in a single operation and produces a proof certificate.
Does BigQuery time travel keep deleted personal data?
Yes. BigQuery retains prior versions of table data in time travel (configurable up to seven days) and a further fail-safe period, so a row you DELETE remains recoverable for a window afterward. Crypto-shredding avoids this problem because the retained versions hold ciphertext that is worthless once the key is destroyed.
Does Chameleon need to move data out of BigQuery?
No. Chameleon maps your existing BigQuery tables and columns 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.
How do I get decrypted PII back for a real query or join, without breaking crypto-shredding?
Declare a decrypted view. Chameleon creates a BigQuery Authorized View backed by a Remote Function that decrypts live, per query — nothing is written to BigQuery storage, so a crypto-shred still stops it instantly, with no extra cleanup step. It lives in its own dataset, outside your dbt PII-scan scope, and the consumer only ever gets read access to that one view.
A practical walk-through of why DML deletes fall short and how crypto-shredding deletes and proves in one call.
How model lineage tells Chameleon which downstream BigQuery tables inherit PII from upstream sources.
The certificate that turns a BigQuery key-destruction event into audit-ready evidence.
Declare a live-decrypting BigQuery view for warehouse joins, without ever persisting plaintext.