Guide: Data Masking

Dynamic Data Masking: 8 Benefits and 3 Examples of Usage

What Is Dynamic Data Masking?

Dynamic data masking (DDM) is a technique for protecting sensitive data from exposure to unauthorized users. Data masking can help simplify application design and secure coding by making data unreadable to anyone without the proper privileges.

Dynamic data masking lets you specify the extent of sensitive data revealed to unauthorized users, minimizing the impact on the application layer. You can configure DDM using dedicated database fields that hide data in query result sets. DDM does not alter the information in the database but only masks it to limit who can see it.

You can easily apply dynamic data masking to an existing application, applying masking rules in query results. Many applications support data masking without requiring modifications to existing queries.

In this article:

8 Benefits of Dynamic Data Masking

A central data masking policy deals directly with the sensitive fields in a database, assigning roles to users without access privileges to the data. Dynamic data masking helps organizations mitigate the risks associated with a data breach, providing the following benefits:

  1. Minimizes the exposure of sensitive data by masking it to non-privileged users, including database administrators and developers who require access to the database.
  2. Enables organizations to specify how much data they want to reveal or restrict access, allowing them to turn this information into the server quickly. 
  3. Supports database configuration to conceal sensitive data in query results without changing the data in the database. 
  4. Applies masking rules in query result sets, making DDM easy to implement in existing applications.
  5. Provides both partial and full masking options and allows you to protect numeric data with random masking functions.
  6. Helps enforce data privacy standards to maintain regulatory compliance.
  7. Provides transparency to applications, with masking applied based on user privileges.
  8. Provides agility, masking data on the fly while keeping underlying data intact in the database. 

Related content: Read our guide to data anonymization

Static Data Masking (SDM) vs Dynamic Data Masking (DDM)

Static data masking (SDM) lets you create sanitized copies of your existing database, removing any identifying information. The copy contains altered data that you safely share without risking a privacy breach. You create an entirely new database, devoid of any unnecessary data, and move it to a separate location where you can mask the data and share it with a specific audience.


However, SDM can make it harder to maintain a single source of truth for your data. Having multiple, different copies of your original data can result in data silos and confusion. 


On the other hand, dynamic data masking allows you to stream data directly from the original location to different systems (i.e., a development or testing environment). You don’t need to store data in a secondary environment, as you would with SDM. 


DDM thus allows operations and data engineering teams to maintain control over sensitive data, including a single clear source of truth. DDM also offers scalability because you don’t need to copy or move data when the number of users of data sets increases.

3 Databases That Provide Dynamic Data Masking

DDM functionality is offered by many modern databases and data warehouses. Here are some examples of popular databases that provide DDM functionality.

SQL Server DDM

This tool lets you mask sensitive data pooled together when running queries. With masking rules implemented within the query results, you can configure DDM on specific fields in the database to conceal data. You can specify specific roles and users with access to masked data.


SQL Server 2016 or later and Azure SQL Database support DDM. You can apply DDM to existing applications without modifying the data you mask. Most DDM processes allow for random, partial, and full data masking. They also support simple Transact-SQL commands that you can use to specify masking jobs and manage your DDM policy.


You can use four types of data masking on SQL Server:


  • Default masking—allows you to create rules to mask the entire value when a user with a read-only privilege queries the data. To implement this function, you must define the function name and empty parentheses. This option masks specific columns based on their data type and does not support arguments.
  • Email masking—allows you to create rules to mask the domain type and the exposed first letter of email addresses. This function masks all domains not ending in .com with .com domains. 
  • Random masking—allows you to create rules to replace every numerical value with random values based on specified ranges. This function lets you trick unauthorized users into believing they can view the correct information.
  • Partial masking—allows you to mask data partially. This function only works for string-type data columns. To implement it, you have to define the value in the “masked with” clause of the function parameter as “partial(start characters, mask, end characters.”

Learn more in our detailed guide to SQL Server Data Masking

Snowflake DDM

Snowflake offers DDM as a security feature allowing you to define a policy that selectively masks plain-text data in views or tables.  You can use this feature, for example, to mask sensitive data and restrict access to columns containing sensitive data on a need-to-know basis.

Snowflake DDM is a powerful and easy-to-use feature that lets you manage data governance by automatically masking sensitive data objects.

You can use data classifications to implement DDM and define your masking policies. You can choose to assign roles to predefined roles or directly to specific users, providing greater flexibility.

Learn more in our detailed guide to Snowflake Data Masking.

Redshift DDM

While Redshift does not offer a native DDM function, you can apply dynamic masking to the data you process in Redshift. You can create an abstract layer providing the logic needed to serve different content based on which user requests to pull the data.


For example, you can use this view to implement the necessary logic:

CREATE VIEW v_customers AS
SELECT CASE WHEN CURRENT_USER='admin' THEN first_name ELSE sha2(first_name, 256) END AS first_name,
CASE WHEN CURRENT_USER='admin' THEN last_name ELSE sha2(last_name, 256) END AS last_name,
CASE WHEN CURRENT_USER='admin' THEN email ELSE REGEXP_REPLACE(email, '[^@]+@', '*@') END AS email
FROM public.customers;

This process involves checking whether the user in various query fields is an admin—if yes, Redshift serves a plain-text value; if not, it serves a redacted version. 

You can use this mechanism to add functionalities easily, including serving full emails to specific users while providing domain names only to some users and empty strings to any other user. You implement more sophisticated masking functionality using groups.

Learn more in our detailed guide to Redshift Data Masking

Dynamic Data Masking with Satori

Satori offers dynamic data masking for all data platforms, regardless of their native support of data masking policies. Dynamic data masking policies can be applied without the need of data engineering resources, and can also be applied without specific location configuration, based on Satori’s continuous sensitive data discovery capabilities. Read more about Satori’s dynamic masking capabilities here, or schedule a demo to learn more.

Last updated on

December 23, 2021

The information provided in this article and elsewhere on this website is meant purely for educational discussion and contains only general information about legal, commercial and other matters. It is not legal advice and should not be treated as such. Information on this website may not constitute the most up-to-date legal or other information. The information in this article is provided “as is” without any representations or warranties, express or implied. We make no representations or warranties in relation to the information in this article and all liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. You must not rely on the information in this article as an alternative to legal advice from your attorney or other professional legal services provider. If you have any specific questions about any legal matter you should consult your attorney or other professional legal services provider. This article may contain links to other third-party websites. Such links are only for the convenience of the reader, user or browser; we do not recommend or endorse the contents of any third-party sites.