Regional Row Filtering, PII Masking, and Thirty Shadow Copies

Use native row filters and column masks on the table, not per-consumer views:

• Row filter. A SQL UDF that returns a boolean, attached with ALTER TABLE sales.customers SET ROW FILTER <fn> ON (region). The function compares the row's region to the caller's entitlement, derived from is_account_group_member('eu_analysts')-style checks or a small mapping table joined on current_user().
• Column mask. A UDF attached with SET MASK on national_id that returns the value for pii_readers, the last four digits when is_account_group_member('fraud_team'), and a redacted constant otherwise.

The advantage over views is coverage: filters and masks apply to SELECT *, to ad-hoc queries, to notebooks, and to every consumer of the table, and they cannot be bypassed by copying data out through a differently shaped query. A view protects only the paths that go through that view, which is how 30 unprotected copies came to exist. Keeping one governed table also means one place to audit. Validate the UDFs' return types and test with a non-privileged user before rolling out, since a mask that errors blocks all reads.

Find the consumers before touching anything. system.access.table_lineage (and column lineage) shows which dashboards, jobs, and queries read each copy; cross-check with job definitions and query history so you catch human ad-hoc readers too. Then replace each copy with a view over the governed table, created with CREATE OR REPLACE VIEW in the same schema under the same name so consumer SQL does not change, and granted to the same groups. A view created by a privileged owner lets callers read columns they cannot read directly, which is fine only when the view filters or projects explicitly, so do not let convenience views silently re-expose national_id.

Sequence it in waves, oldest and least-used copies first, with a deprecation window and a named owner for each.

For residency, put EU and US data in separate catalogs and bind each workspace to only its regional catalog. Analysts in the EU workspace then cannot see the US catalog at all, which is a stronger guarantee than a row filter and reduces the blast radius of a misconfigured grant.

Unity Catalog audit records are queryable through the system.access.audit system table: filter to the read actions against sales.customers and the PII-bearing tables, and record actor, timestamp, and the accessed object. Join to lineage tables to show where the data flowed afterwards.

Practical limits to plan around:

• Retention. System table retention may be shorter than the audit window the auditors want; ship audit logs (and the raw cloud audit logs) to a storage bucket with a lifecycle policy that meets the retention requirement.
• Access to the audit data itself. Audit logs reveal who looked at what, so they must not be readable by account users. Grant them to a small compliance group, and note that auditors reading the audit tables is itself audited.
• Completeness. Audit covers Unity Catalog and workspace activity, not data downloaded to a laptop and read offline. Combined with column masks and the removal of unprotected copies, the audit story is credible; without those, it is not.

Also enable the system tables once and confirm they were on before last quarter started, or the evidence may not exist.