SQL Server Data Masking Techniques: Spoofing Existing Table Data for Test and Development

Comments 0

Share to social media

Test and development environments often need data that looks like production – realistic distributions, edge cases, representative volumes – but without the PII and compliance exposure of actual production data. Data masking (sometimes called anonymisation, obfuscation, or spoofing) is the practice of transforming production data in place or in a copy so that the structure, distributions, and edge cases remain realistic while the specific values no longer identify real people or transactions. This article covers three core masking techniques in SQL Server: name substitution from lookup tables (replace each real name with a random name from a reference dataset, preserving gender and cultural distribution), locality-preserving address transformations (keep city, state, and country while randomising street-level detail), and plausible-distribution-preserving obfuscation of dates and numerics (add random offsets within believable ranges rather than replacing with entirely new values). The goal: test queries and applications with data that exercises the same patterns as production, without exposing anyone’s real information. When you are developing an existing database, or demonstrating it, you nowadays need pseudonymised data, or even better, completely anonymized data. This data has to look right at first glance, and it needs to have the same distribution as the real data. Although we are yet to tackle continuous variables with complicated distributions such as sales figures or dates, we can now generate words. This article is about using a finite-state Markov chain with stationary transition possibilities. You can use the technique to generate words, sentences, articles or entire books. In our first attempt to do a markov-style obfuscation of words, we used an algorithm that was very iterative and was more useful for generating file-based lists of words than for SQL based pseudonymization. File-based lists are excellent for use with data masking, or data-generation, tools. However, if we are using SQL we have the additional resource of the markov table that we can use whenever we want. The advantage of this is that we can change the algorithm to apply to the markov table in order to generate different degrees of data obfuscation. Before we go on to obfuscate other datatypes than words, we’ll take a bit of time to show how one might use Markov tables in order to pseudonymise tables in-place. Let’s take, for example, the AdventureWorks person.person table: We want to be able to obfuscate it easily by means of : (No, I copied the database first!) Before you get over-excited, it took twenty-eight seconds to do the 20,000 rows of the task. You’d do much faster with prepared tables of obfuscated words, or word collections in files used by a third-party tool, but it is a start. Here was the same data before we pseudonymized it. We check the distributions of the data before and after we make the changes, to make sure we haven’t altered it. Let’s first check on the distributions of customers’ lastnames before and after running our process. And we can do the same with firstnames just to make sure we are matching the existing distributions We are taking a slow-but-steady approach. We rewrite our code from the previous blog post that assembles the string; it now uses a view to get its random numbers, and we’ll speed it up slightly by putting a bit more intelligence into the markov table. We then put it in a slow User-defined Scalar function. We  want a scalar function that isn’t schema verified and is not considered to be deterministic. The reason for this is that it has to be executed every row despite having the same parameter. There are many ways to store the information permanently in a Markov table but we’ll be using Table-valued parameters for our function. I’ll show how they are generated from the original information in AdventureWorks, but they could be so easily fetched from a table of markov entries with each markov set identified by a name. This could be delivered to you by the production DBA so that you wouldn’t need any access to the production server. Now we can try it out, using AdventureWorks. Although this is fun, we need to move on to do more. You will want to try out what we’ve done on that modification date in AdventureWorks. If you do, you will see that it will produce dates that are legal, but our algorithm won’t produce the correct distribution. Even if we change the dbo.FakedStringFrom function to choose all the characters according to their statistical distribution it will fail to work convincingly with small samples. It needs a rather different technique. We’ll talk about that in the next blog in this series.

FAQs

1. How do I mask production data for SQL Server test environments?

The standard workflow: (1) identify columns containing PII or sensitive data (names, emails, phone numbers, addresses, national IDs, card numbers, dates of birth, salaries); (2) choose a masking technique per column based on what downstream testing needs – substitution from lookup tables for names, pattern-preserving randomisation for emails and phones, locality-preserving transformation for addresses, plausible-offset randomisation for dates and amounts; (3) apply transformations in a copy of the production database (never directly in production); (4) verify referential integrity survives – if a customer appears in orders, the masked customer should still join correctly to its orders. For large-scale masking, consider dedicated tools like Redgate Data Masker that automate the workflow.

2. What is the difference between data masking, anonymisation, and spoofing?

The terms overlap substantially. ‘Data masking’ is the most common industry term, particularly in compliance contexts (PCI DSS, HIPAA, GDPR) – it implies replacing sensitive values with non-sensitive substitutes while preserving structure. ‘Anonymisation’ is a stronger term used in privacy regulation; legally it means making re-identification impossible – a high bar that static masking often doesn’t meet if attackers have access to outside information. ‘Obfuscation’ is broader and includes any transformation that makes data harder to interpret. ‘Spoofing’ (the term this article uses) emphasises making the fake data look convincingly real. For regulatory compliance, use ‘masking’ or ‘pseudonymisation’; for casual developer discussion, the terms are effectively interchangeable.

3. How do I mask data while preserving referential integrity in SQL Server?

Three approaches: (1) Deterministic masking – use a repeatable function (hash, lookup keyed by original value) so the same original value always produces the same masked value. This preserves joins automatically because matching IDs in parent and child tables remain matching after masking. (2) Staged masking with key preservation – mask only non-key columns; foreign key columns retain their original values. Appropriate when the keys themselves aren’t sensitive. (3) Coordinated renumbering – when keys are sensitive (national IDs used as keys), maintain a mapping table old_value → new_value, apply the mapping consistently across all tables referencing that value. Deterministic masking with a secret salt is the most common production pattern.

4. What is Redgate Data Masker for SQL Server?

Redgate Data Masker is a commercial tool (part of the SQL Toolbelt) that automates data masking workflows for SQL Server databases. It provides a library of masking rules (name substitution, credit card masking, phone number masking, locality-preserving address transformation), handles referential integrity across foreign keys automatically, and supports scheduled masking of database copies for non-production environments. For environments where data masking is a regular compliance activity, dedicated tooling like Data Masker is more practical than custom T-SQL scripts. For small-scale or one-off masking, the manual techniques in this article are sufficient.

This document contains proprietary information and is protected by copyright law.

Copyright © 2026 Red Gate Software Limited. All rights reserved

Article tags

About the author

Phil Factor

See Profile

Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 40 years of experience with database-intensive applications. Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career. See also :