---
title: "Tag-based Masking Policies"
slug: "tag-based-masking-policies"
updated: 2026-06-29T12:56:27Z
published: 2026-06-29T12:56:27Z
canonical: "docs.plainid.io/tag-based-masking-policies"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Tag-based Masking Policies

**Tag-based Masking** enables organizations to enforce data masking policies across multiple columns and objects in a scalable, classification-driven manner.

In Snowflake, tag-based masking is implemented by **associating a Masking with a Tag**, rather than directly attaching the policy to an individual column.

A Tag-based Masking configuration allows administrators to define a masking policy once and bind it to a tag at the schema level. Any column—across tables or views—that is assigned that tag automatically inherits the masking behavior. The masking is applied dynamically at query time, and the logic is evaluated using conditional expressions and Snowflake context functions such as `CURRENT_ROLE()`, `CURRENT_USER()`, or `IS_ROLE_IN_SESSION()`.

This model decouples masking logic from individual column definitions and enables centralized enforcement across multiple columns, promoting consistent protection aligned with data classification and governance strategies.

## Dynamic Data Masking

A **Tag-based Masking Policy** uses Snowflake **Tags** to define reusable, scalable masking rules. A Masking policy is assigned to a tag, and any column carrying that tag automatically applies the associated masking logic across all tables and schemas. Tag-based masking policies support scalable, classification-driven governance, simplify lifecycle management, and enable consistent enforcement for compliance with regulatory requirements.

**Use Case Example** A company tags columns such as Customer_Email, Customer_Name, and other sensitive fields across multiple schemas using `PII = 'High'`. It then applies a tag-based masking policy with contextual rules so: - Standard analysts receive masked values - Support agents receive partially visible values - A small privileged group has full visibility

## Creating a Snowflake Masking Policy

Note

*Ensure that your Snowflake Application in Orchestration is switched to **Manage mode** to start building your **Masking Policy** in the Policy catalog section. See [Managing POPs](/v1/docs/managing-pops) for more information on how to change the **POP Mode**.*

Masking Policies in PlainID can be created using the following methods:

- **Wizard**
- **Code**
- **Native**

For more information, refer to [Creating Policies](/v1/docs/creating-policies).

---

**To create a Masking Policy with the Policy Wizard**:

1. **Input the Policy Details.** For more information, refer to the [Creating Policies](/v1/docs/creating-policies) article
2. Select **Use Policy For SaaS Applications** and select the Snowflake application.
3. **Input the Snowflake POP Details** specific to the vendor Policy:
  - Under the **Vendor Policy Kind** dropdown, select **Masking Policy**. (Required)
  - Enter a **Vendor Policy Name**, a unique name for the Policy that will appear in the Snowflake vendor. (Required)
    - **Note:** The same name can be used across multiple PlainID Policies to define multiple logic statements within a single Snowflake Masking Policy.
  - Under the **Vendor Policy ID**, note that the ID is automatically generated. It is the ID used in Policy management operations like deploy, update, and override.
  - Define the **Vendor Policy Order**, which relates to the execution order for the logical case statement within the same Vendor Policy ID. (Required).
    - The Default value is 1. Use this field when enforcing multiple logic conditions for different Identity Groups within the same Policy.
  - Enter a **Comment**, add any additional information or clarifications about your Policy. (Optional)
  - Under **Database**, select the Snowflake database where the Policy will be deployed.
  - Under **Schema**, select the schema within the database where the Policy resides.
  - Input an **Owner**, provide the POP Snowflake role used to manage the Policy.
4. Click **Continue**.

Iceberg Tables are also supported as part of the Table and View Assets. Ensure that you have the correct permissions by referring to the [Snowflake Setup](/v1/docs/snowflake-setup) article.

## Who Section

In the **Who** section, you can assign Column-level access by creating a new Dynamic Group or selecting an existing one. A single Policy can evaluate **multiple Dynamic Groups** (OR relationship between them), giving you flexibility in defining access control logic. Select **Dynamic Groups** associated with Identity Attributes defined in your POP.

Dynamic Groups are defined using Snowflake identity functions such as `CURRENT_USER()`, `CURRENT_ROLE()`, `IS_ROLE_IN_SESSION()`, and `CURRENT_SECONDARY_ROLES()`. You can use multiple Identity functions within the same group to refine access. If you want to apply your Policy logic to all users, you can still connect the default **"All Users"** Dynamic Group. ![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28322%29.png)

For additional information on how to create a Dynamic group, see [Managing Dynamic Groups](/v1/docs/managing-dynamic-groups).

## What Section

In the **What** section, you can define access through your Asset Types ***if using Conditional Masking for tags*.**

For more details on **Asset Types**, refer to [Managing Asset Types](/v1/docs/managing-asset-types).

**To define access, you are required to define the following Asset Types**:

1. Click **Add Asset Type** (for Policy Signature).
  - From the dropdown, select an **Asset Type** that defines your Masking Policy logic (Policy Signature. See [Policy Syntax Table](/v1/docs/tag-based-masking-policies#policy-syntax-table) for more information.)
    - Only one Asset Type can be selected in a single Masking Policy.
  - Select **existing Rulesets** for your policy logic or create a new one. A Policy can include multiple Rulesets (OR relationship between them).
    - See [Defining a Ruleset for Masking Policies](/v1/docs/tag-based-masking-policies#defining-a-ruleset-for-masking-policies) for more information.
  - Click **Save**.

1. **To add Snowflake Tag Asset Types**, click **Add Asset Type**.
  - From the dropdown, select **Tags** Asset Type. For more information, see the [Snowflake Tags Asset Type](/v1/docs/tag-based-masking-policies#snowflake-tags-asset-type) section.
  - Select the **Masking action**, which defines how data is masked. For more information, refer to the [Actions as Masking Instructions](/snowflake-column-level-security#actions-as-masking-instructions) section.
  - Select the **Assets** to mask.
    - A single Masking Policy can be applied to one or multiple Asset tags.
  - Click **Save**.

To apply different masking rules for different **roles**, **groups**, or **context conditions**, use the same Vendor Policy Name across multiple PlainID Masking Policies on the same asset.

Ensure that all PlainID Policies referencing the same vendor policy ID use the same Signature Asset Type. Within that shared Asset Type, each ruleset may use different Asset Attributes as needed for its specific logic. Also, ensure that you keep the **associated Asset/s consistent** across all linked Tag Asset Types.

**To connect an Asset Type with the Snowflake Application**:

1. Once the Asset Type is created, open the Snowflake Application in your Integrations Workspace (formerly Orchestration Workspace) .
2. Navigate to the **Asset Types** tab.
3. Click **Edit**.
4. Select the relevant **Asset Types** you want to associate with the Snowflake application.  

![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28326%29.png)

#### Defining a Ruleset for Masking Policies

**To define a Ruleset**:

1. In the Asset type within the Ruleset tab, define the Masking logic using the Asset Attributes you created (for example, `Account_Level = 'Premium'`).

You can use Snowflake tables as an external Identity Source for contextual or dynamic rules (for example, `Department = user.department`). See our documentation on [Managing Identity Source Tables](/docs/object-side-panel#managing-identity-source-tables) for more information.

1. Use PlainID's logic to combine operators (`=`, `!=`, `>`, `IN`, etc.) with complex AND/OR relationships.

![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28327%29.png)

## Asset Types for Tag Masking Policy Requirements

To create a Tag-based masking policy, ensure that your Asset Type/s meet the following requirements:

The Signature Asset Type contains the masking logic enforced by the Policy. To define that logic in your rulesets, create Asset Attributes that match the physical column names. These Attributes correspond to the columns in Snowflake tables that have the tag applied.

*Example:* to mask PII data, use conditional masking logic based on `TYPE = 'Document'`, then create an Asset Attribute labelled `TYPE` that is identical to the `TYPE` column in your Snowflake table.

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(352).png)

### Snowflake Tags Asset type

Tag-based Masking Policies in Snowflake can be centrally managed through PlainID using the **Snowflake Tags** Asset Type. These Policies enable masking logic application based on Snowflake tags rather than on individual columns, supporting scalable and consistent data protection across multiple tables.

**Snowflake Tags Assets**

Available Tags to use in Policies related to Snowflake appear in the Assets section. PlainID discovers all available tags during the Discovery process and displays them in the Object Side Panel within the Integration Workspace.

When you associate a tag with a Masking Policy, this tag is applied to your Policy through an argument called `FIXED_FIRST_ARG`. You can see this argument in the Policy Signature in the Policy Diff side panel. This argument represents the physical columns' masked value, which is linked to the tag.

**Note:** PlainID does not create or manage Snowflake objects. Tags must be defined and applied to columns within the Snowflake environment.

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(353).png)

### Actions as Masking Instructions

In the **Snowflake Tags** Asset Type, the **Actions** tab defines how data is masked when a policy is enforced.

Masking instructions are applied to the selected Assets in your policy.

You can define masking actions in two ways:

1. **Standard masking actions** — specify the masking value or expression directly in PlainID
2. **Vendor function masking actions** — call an existing vendor-native masking function (for example, a Snowflake function)

#### **Masking Action Fields**

The following fields are used when defining masking actions:

| Field | Description |
| --- | --- |
| **Action ID** | The display name of the masking action |
| **Value** | The masking value or expression returned by the policy (for example, `'MASKED'` or a vendor function expression) |
| **Type** | The returned masked value data type. This must match the `RETURNS` type declared in the Snowflake Masking Policy (for example, `VARCHAR`, `NUMBER`) |

#### **Standard Masking Actions**

Standard masking actions define the masking logic directly within PlainID.

You can either:

- Use a **default masking instruction** (for example, `Default for Varchar`, `Default for NUMBER`), or
- Create a **custom masking instruction**

**Example**

| Field | Value |
| --- | --- |
| Action ID | Mask String |
| Value | `'MASKED'` |
| Type | `FUNCTION_VARCHAR` or `FUNCTION_NUMERIC` |

**Action Type (Function-Based Masking)**

When using vendor functions, set the **Type** field to one of the following:

- `Function_Varchar` – use when the function returns a **VARCHAR** value
- `Function_Numeric` – use when the function returns a **numeric** value

This configuration causes the masking policy to return the specified value when masking is applied.

#### **Using Vendor Functions as Masking Actions**

PlainID also supports referencing **vendor-native masking functions** directly in masking actions.

This capability allows you to reuse existing masking logic defined in the data platform without requiring the function to be discovered or managed as an object within PlainID.

This is useful when:

- Masking logic already exists in the vendor platform
- The masking logic requires **complex expressions or reusable functions**
- Masking behavior depends on **tags or metadata**

> **Note:** Ensure you are in **Manage Mode** to define vendor function masking actions. See [Managing POPs](/v1/docs/managing-pops) for more information.

**To define a vendor function Masking Action**

1. Open your **Policies Workspace (formerly Authorization Workspace) **
2. Select the relevant **Application**
3. Click **Asset Types**
4. Hover over the relevant **Tag** (Asset Type) and click Manage.
5. Click **Actions**
6. Create a new Action

**Example**

```
PRODUCT_DB.SCHEMA1.STR_MASK_FUNC(
  'STATIC_VALUE',
  SYSTEM$GET_TAG_ON_CURRENT_TAG('SENSITIVITY_TAG')
)
```

In this example, the masking policy calls the vendor function `STR_MASK_FUNC` and passes:

- A static value (`'STATIC_VALUE'`)
- The value of the `SENSITIVITY_TAG` tag assigned to the current tag context

The function then applies masking logic based on these inputs.

Once the masking action is defined, it can be used in policies to enforce **tag-level masking**.

## When Section

In the **When** section, you define the Conditions that provide contextual Identity data for your Policy, which determine when the Policy applies.

**To define a Condition**:

1. Select an existing **Condition** or create a new one.
  - A Policy can include multiple Conditions, combined with a logical AND operator, meaning all Conditions must be met in the Policy to grant user access. Ensure that you select Conditions from Identity Attributes linked to the POP's Identity Source.
  - See [Managing Conditions](/v1/docs/managing-conditions) to learn how to create a new Identity Attribute Condition.
  - Ensure that the Condition meets the [Conditions for Masking Policy Requirements](/v1/docs/tag-based-masking-policies#conditions-for-masking-policy-requirements).
2. Click **Save**.

### Conditions for Masking Policy Requirements

- Only Conditions based on **Identity Attributes** are supported for use in Masking Policies.
- Ensure that an **Identity Source table** is defined within your Policy Orchestration Point (POP).
- Use an **Identity Attribute** that is mapped to one of the additional Identity Sources associated with the selected POP. For more details, refer to our documentation on [Managing Identity Source Tables](/docs/object-side-panel#managing-identity-source-tables).
- Within a single Condition, you can only use Attributes from one Source.

## Deploying the Policy

Once complete, navigate to the Integration Workspace and deploy the Policy to Snowflake. Snowflake enforces the access decision based on the Masking logic defined in the PlainID platform.

**Tag-Based Masking Policy Deployment**: ![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28332%29.png)

## Snowflake Masking Policy SQL Structure

This table explains the components of a Snowflake Masking Policy in SQL and compares them to their equivalents in PlainID, helping you translate and build your Policies easily within the PlainID platform.

### Policy Syntax Table

| **Snowflake terminology** | **Snowflake Syntax** | **Description** | **PlainID terminology** |
| --- | --- | --- | --- |
| **Policy Declaration** | `CREATE OR REPLACE MASKING POLICY <policy_name>` | Defines the Policy name and type (Masking Policy). Used to declare or replace an existing Masking Policy. | Vendor Policy Name, Vendor Policy Kind |
| **Policy Signature** | `AS (VAL1 VARCHAR, VAL2 NUMBER..) RETURNS VARCHAR` | Declares the Policy's input arguments and return type. Arguments are used in the Policy masking logic. The return type of the Masking Policy must match the data type of its first argument. The first argument is the masked value. | Policy Signature mapped to **Asset Type**. Each argument that is used within the policy logic is created as an **Asset Attribute**. |
| **Policy Logic** | `WHEN...` | Incorporates Snowflake identity functions: `CURRENT_ROLE()`, `CURRENT_USER()`, `IS_ROLE_IN_SESSION()`, `CURRENT_SECONDARY_ROLES()` to determine who should receive access in a given context. | Dynamic group |
|  | `CASE...` | Use SQL expressions such as CASE statements to define the masking logic. | Policy logic uses the Policy arguments mapped into Rulesets, which can be dynamic (based on external identity data) or static (using fixed values). |
|  | `EXISTS (SELECT... FROM... WHERE...)` | Use SQL subqueries with EXISTS SELECT for dynamic, context-based filtering. | Policy logic uses an external table mapped into conditions, where expressions typically compare attributes to static values. Note that a correlation must be defined using one of the Snowflake identity functions (e.g., `CURRENT_ROLE()`, `CURRENT_USER()`, `IS_ROLE_IN_SESSION()`). |
| **Policy Output** | `THEN 'MASK' ELSE VAL1` | Defines the instructions used for masking data. Based on the policy logic, the output can be the original column value, or a partially masked or fully masked version. The masking instructions are applied to the first argument. | Action in the Snowflake Tags Asset type. |
| **Policy Application** | Apply to a tag: `ALTER TAG <tag> SET MASKING POLICY <policy>;` | Applies the Masking Policy to specific tags. The same Policy can be reused across multiple tags for consistent masking behavior. | The Tag-based masking is reflected as Assets in the Tag-Asset Type. |