Policies

Overview¶

A policy controls who is governed, which data it applies to, and what action is taken. You build it in the guided Create Policy wizard. First you choose a policy type, then you complete three steps.

There are two kinds of policy:

• an Access policy, which controls who can read or write data. The action is Read or Write.
• a Governance policy, which applies a security rule to data. A Masking policy hides or obscures the values in chosen columns, and a Row Filter policy limits which rows are returned.

Rather than listing the same users, columns, or rows in every policy, you reuse named Identifiers.

How a policy uses Identifiers¶

A policy stays generic. The Identifiers it references are resolved at query time against the data the policy applies to:

• A User Identifier resolves against the person making the request, so the policy applies only to the users it describes.
• A Column Identifier resolves to the columns it selects.
• A Record Identifier resolves to the rows that meet its condition, which are the rows a Row Filter policy keeps or removes.

Because a policy points to Identifiers instead of fixed names, one policy applies consistently across many resources, and updating an Identifier updates every policy that uses it.

Create a policy¶

Choose a policy type¶

Click Create Policy and choose a type in the Select Policy Type dialog:

• Access Policy controls who can read or write specific datasets.
• Governance Policy sets up security rules like data masking or row filtering. When you pick it, also choose a governance type:
  • Mask hides or obscures specific fields for certain users.
  • Row Filter filters which rows are returned based on fine-grained conditions.

Click Continue to open the wizard. It has three steps: Define Rules, then Name & Description, then Review & Publish. Use Back to revisit a step, and Save as Draft to keep an unfinished policy.

Step 1: Define Rules¶

This step defines the scope of the policy by selecting the target users, the data, the identifiers, and the action. It has four sections.

A. Users¶

Specify the users, groups, or roles the policy applies to. Choose a type, then select the value:

• Everyone applies to all users and takes no value.
• User, User Role, and User Group let you select specific users, roles, or groups.
• User Identifier lets you reuse a saved User Identifier.

B. Data¶

Select the data the policy governs. Choose a scope:

• Data Tag applies the policy wherever a classification tag appears.
• Data Product applies it to a published data product.
• Specific Resource applies it to assets you select.

Leaving this section empty is fine — you can scope the policy later by applying it to a resource from the Data Catalog's Apply Policy action, which fills in this Data scope for you.

C. Column Identifiers or Record Identifiers¶

Pick the identifiers the policy targets within the scope. Column Identifiers are commonly used by Masking policies and can also be used in Access policies; Record Identifiers are used by Row Filter policies. For each identifier, choose Include to target what it selects or Exclude to leave it out, then search and select the identifier.

For a Masking policy, whether you need a Column Identifier depends on how Data is scoped. If Data is a Data Tag applied at the column level (such as EMAIL), the tag itself identifies the columns to mask, so no separate Column Identifier is needed. If Data is a Specific Resource — including one you scope later from the Data Catalog — add a Column Identifier to choose which columns to mask; without one, masking applies to every column in the resource. This doesn't apply the same way to Access policies, where a Column Identifier is optional either way — omitting one simply grants access to the whole resource.

D. Actions¶

Choose the action to enforce on the target data.

For an Access policy, choose the level of access:

For a Masking policy, choose how to obscure the matched columns:

For a Row Filter policy, choose Allow Result to return only the rows that match, or Exclude Result to drop the rows that match.

Step 2: Name & Description¶

Give the policy a name and an optional description:

• Policy Name is required. Use a unique, descriptive name.
• Policy Description is optional. Use it to explain what the policy enforces.

Step 3: Review & Publish¶

Review the configuration before you publish. This step shows the policy name, description, and a summary of the rules you defined for users, data, identifiers, and actions. A GIA Policy Summary describes the policy in plain language, and the panel shows the Status and the Policy Type.

Select Save as Draft to keep the policy without enforcing it, or Publish Policy to make it active. A draft is not enforced until you publish it.

Real world examples¶

The following examples share one scenario. Acme is a commercial real estate company running on Snowflake. james is the data owner with full access, emily manages the East region, and david is a new West region manager. The data is organized into data products: REAL_ESTATE_PORTFOLIO with property_master and lease_portfolio, REAL_ESTATE_TENANTS with tenant_financials and tenant_contacts, and REAL_ESTATE_OPERATIONS with facility_work_orders — all in Snowflake.

Each example reuses Identifiers. Build them first from the Identifiers page, then search and select them in the wizard.

Grant employees access to a data product¶

Acme wants all employees to read the property portfolio, so a new hire like David is covered automatically. The Employees User Identifier covers every employee without listing them by name. Choose Access Policy.

Employees can now query property_master and lease_portfolio.

Show regional managers only their region's properties¶

Regional managers should see only the properties in their own region, while the data owner keeps full access. The Regional Managers User Identifier covers both Emily and David without listing them by name. The Allowed Properties by Region Access Record Identifier compares the property's region_name resource attribute against the requesting user's region attribute, so it resolves each user's permitted properties at query time and keeps working as managers and regions change. Choose Governance Policy, then Row Filter.

Emily sees East-region properties, David sees West-region, and the data owner — who isn't a manager — is outside this policy's scope entirely and keeps full access.

Restrict Texas data from offshore users¶

Offshore users must not see Texas customer records across the customer tables tagged CUSTOMER_DATA. This policy reuses two Identifiers built on the Identifiers page: the Identify Offshore users User Identifier and the Identify Texas data Record Identifier — the same tag-based pattern described under Record Identifier. Choose Governance Policy, then Row Filter.

Offshore users no longer see Texas records in any table tagged CUSTOMER_DATA. Other users are unaffected.

Show Texas data to offshore users only with consent¶

Offshore users may see Texas customer records, but only for customers who have given consent. The Identify Data with consent Record Identifier resolves consent at query time, so the policy stays correct as consent changes. Choose Governance Policy, then Row Filter.

Offshore users see Texas records only for customers who have given consent.

Redact sensitive tenant data for everyone¶

Sensitive financial fields such as credit ratings, tax IDs, and bank account numbers must be masked across the tenant data for everyone, including data owners. The Sensitive financial columns Column Identifier selects those columns by their tag. Choose Governance Policy, then Mask.

Those columns are now masked in tenant_financials and tenant_contacts.

Manage policies¶

Open Data Governance → Policies in the left sidebar. Each policy card shows its name, description, and last-updated time, and a Status of DRAFT, ACTIVE, or DEACTIVATED. Filter by type using the Type toggle: Access Policies, Masking Policies, or Row filtering. Use Create Policy to start a new one.

Use the actions on a policy to:

• Edit the policy and re-save it.
• Clone the policy to start a new one from a copy.
• Change its status. Activate a policy to enforce it, or deactivate it to keep it without enforcing it.
• Delete the policy.

Related topics¶

• Identifiers
• Tag-Based Access Control (TBAC)
• Column Masking
• Row-Level Filtering