Governing Data in Snowflake — Tags, Policies & Auditing

Data governance isn't just about compliance—it’s about control, transparency, and trust. As modern analytics teams scale across departments, tools, and regions, the need for structured governance becomes critical. Snowflake offers a suite of native capabilities—tags, policies, and auditing—to help you classify, secure, and monitor your data without introducing friction.

In this blog post, we explore how Snowflake enables metadata-driven governance through a combination of flexible tagging, dynamic access policies, and deep audit visibility.

Tags: Metadata as a Governance Backbone

Tags in Snowflake are simple but powerful. Think of them as key-value annotations you can attach to any object: databases, tables, columns, roles, or even users. These tags serve as metadata anchors for security, cost tracking, and classification.

What Makes Tags Powerful?

• Schema-level objects: Tags are defined once and can be applied broadly across the account.

• Multi-level inheritance: Apply a tag to a table, and it can cascade to all columns within it.

• Centralized or Federated: Tags can be governed by a central data team or assigned by domain owners.

• Policy binding: Tags can be linked to masking or row access policies for automatic enforcement.

Example: Tagging a Column as PII

create or replace tag pii_tag comment = 'Personally Identifiable Information';

alter table dim_customer
  modify column email set tag pii_tag = 'true';

Why Tags Matter

• Flag sensitive data (e.g., pii, phi, gdpr_sensitive).

• Assign cost centers (cost_center:marketing).

• Mark lineage or ownership (owner:finance_team).

• Automate policy enforcement, creating a "set it and forget it" security model.

You can query assigned tags from the ACCOUNT_USAGE.TAG_REFERENCES view to track classification and coverage.

Policies: Enforcing Security and Access at Scale

Masking Policies
Masking policies dynamically control what users see at the column level. Based on a user's role, Snowflake can selectively reveal or redact sensitive information—without creating separate views or copies.

create masking policy ssn_mask as (val string)
  returns string ->
    case when current_role() in ('HR_ADMIN') then val else 'XXX-XX-XXXX' end;

alter table employees modify column ssn set masking policy ssn_mask;

While you can apply policies object by object, the real power comes from binding a masking policy directly to a tag (e.g., pii_tag). Once bound, the policy is automatically applied to any column that receives that tag, now or in the future. This transforms governance from a manual task to a scalable, automated process.

Row Access Policies
Row access policies filter records dynamically based on the context of the query. A far more robust and common pattern than using session context is to use a mapping table that links roles to the data they are allowed to see.

First, create a mapping table that defines which roles can see which business regions:

-- This table defines which role can access which data slice
CREATE TABLE governance.role_to_region_mapping (
  role_name STRING,
  allowed_region STRING
);

INSERT INTO governance.role_to_region_mapping VALUES
  ('SALES_MANAGER_EMEA', 'EMEA'),
  ('SALES_MANAGER_APAC', 'APAC');

-- Then, create a policy that uses this mapping table to filter rows:

create row access policy region_filter as (region_col string) returns boolean -> -- The policy returns TRUE if the user's role is mapped to the row's region value exists ( select 1 from governance.role_to_region_mapping where role_name = current_role() and allowed_region = region_col );

alter table sales add row access policy region_filter on (region);

This pattern is incredibly powerful for use cases like showing regional managers only their territory's data or restricting customers to their own transactions.

## **Auditing: Visibility for Control and Compliance**

Effective governance isn’t just about restricting access—it’s about knowing who accessed what and when.

**Key Audit Tools**

* **Query History:** What SQL was run, by whom, and when.

* **Access History:** Which objects were accessed and by which role.

* **Tag References:** Track how tagged data was accessed over time.


**From Forensic to Proactive Auditing**  
Go beyond simple forensics. Use ACCESS\_HISTORY proactively to identify dormant or over-privileged roles. If a role has access to sensitive tagged data but hasn't queried it in 90 days, it may be a candidate for having its privileges revoked, strengthening your adherence to the Principle of Least Privilege.

```sql
-- See who accessed sensitive objects recently
select *
from snowflake.account_usage.access_history
where object_name ilike '%customer%'
  and event_time > dateadd(day, -7, current_timestamp());

Best Practices for Data Governance in Snowflake

Think of these practices not as a checklist, but as a Governance Flywheel. Well-defined Tags allow you to automate Policy enforcement. Automated policies generate clean Audit logs. Reviewing these logs helps you refine your tags and policies, creating a virtuous cycle of ever-improving, low-friction governance.

• Create a Consistent Tag Taxonomy: Define clear naming conventions (pii:true, cost_center:sales) and enforce them.

• Automate Policy Assignments: Use tags to bind policies automatically instead of managing each object manually.

• Separate Ownership from Access: Centralize who can create policies, but decentralize who can view or query tagged data.

• Audit Regularly: Set up dashboards or scheduled queries to review access logs and catch anomalies proactively.

Final Thoughts

Governance in Snowflake isn’t an afterthought—it’s built into the platform. With tags, policies, and auditing, you get a native control plane to enforce security, manage access, and demonstrate compliance without sacrificing performance or agility. Whether you're rolling out GDPR compliance or building secure multi-tenant products, Snowflake gives you the governance foundation you need—at cloud scale.