Use column grants when a whole column is off limits, masking when people need the column but not the raw value, and row policies when the same table holds data for different audiences. Most warehouses need two of the three together, and the choice follows from one question: what exactly should this person not see?
Column grants and views
The simplest control is not to give access. If a column such as a national ID has no analytical use for a group, leave it out of the view that group queries. This costs nothing at query time and is easy to explain to an auditor.
The weakness is flexibility. If one team needs the real value and another does not, you end up with two views and a maintenance burden.
Dynamic masking
Snowflake describes dynamic data masking as a column level security feature that hides sensitive plain text data in table and view columns at query time. A masking policy is a schema level object, and depending on conditions, role hierarchy and execution context, a query returns the plain value, a partial value or a fully masked value.
Masking suits columns where some people need the real value, such as support staff verifying a customer, and others only need a shape, such as an email domain or last four digits. One policy can cover many columns, and you can change its logic without reapplying it everywhere.
Know the edges. In Snowflake, virtual columns and materialized views cannot take masking policies directly, so the policy goes on the source table columns. Masked values can still support joins and counts in a way that reveals something, so do not treat masking as anonymisation.
Row policies
Row access policies decide which rows come back. Use them when a single table holds many tenants, regions or business units. See our explainer on how row access policies work for the behaviors to test.
A decision table in prose
If nobody in the group needs the field, do not expose it. If some need it and others need a shape, mask it. If the question is which records rather than which fields, use a row policy. If both apply, combine them. Snowflake evaluates row access policies before masking policies, so rows are filtered first and masking applies to what remains.
Common mistakes
- Masking a column but leaving the raw value in an extract table that analysts can also query.
- Granting a broad role that bypasses the policy through an owner or admin path. Ask who owns the policy and who can alter it.
- Forgetting copies. A policy on the source does nothing for a CSV export or a notebook cache.
Audit and review
Snowflake exposes policy usage through its MASKING_POLICIES and POLICY_REFERENCES Account Usage views, which lets you list which columns are protected. Run that listing monthly and compare it with your data classification list.
Where Safeguard fits
Warehouse features do the masking. Safeguard's asset discovery and compliance evidence automation help you keep a record of which systems exist and which reviews ran. You can also scan pipeline repositories for free at https://gold.safeguard.sh/scan.
Quick check
Is masking the same as anonymisation?
No. Masking changes what a query returns for a role, but the underlying data is intact and may still be linkable. Treat it as access control.
Which runs first in Snowflake, row policies or masking?
Row access policies are evaluated before masking policies.
Sources
Last reviewed: 19 October 2026.
