{"id":11006,"date":"2022-11-30T17:13:59","date_gmt":"2022-11-30T17:13:59","guid":{"rendered":"https:\/\/www.genrocket.com\/blog\/?p=11006"},"modified":"2026-05-18T18:47:24","modified_gmt":"2026-05-18T18:47:24","slug":"why-traditional-data-masking-is-evolving-to-synthetic-data-masking","status":"publish","type":"post","link":"https:\/\/www.genrocket.com\/blog\/why-traditional-data-masking-is-evolving-to-synthetic-data-masking\/","title":{"rendered":"Why Traditional Data Masking is Evolving to Synthetic Data Masking"},"content":{"rendered":"

We are often asked if GenRocket can perform data masking. The answer is, \u201cYes, of course \u2013 and with ease.\u201d But like many questions asked about synthetic test data, the simple answer belies a complex explanation of the advantages of synthetic test data over production test data. Here, we explain five issues with masked production data and how Synthetic Data Masking<\/em> overcomes them.<\/p>\n


\n<\/p>\n

Five Issues with Production Data Masking<\/h2>\n

Although masked production data is the industry norm for producing privacy-protected test data, there are several problems associated with the process and its subsequent test data outputs. These issues or challenges may be summarized as follows:<\/p>\n

    \n
  1. \n
      \n
    1. Security:<\/strong> Masked production data requires access to production data tables which may contain personally identifiable information (PII) or personal health information (PHI). Although masking obscures PII or PHI, the sensitive data is exposed during the masking process.<\/strong> This creates an unacceptable level of risk for many companies.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


      \n<\/p>\n

        \n
      1. \n
          \n
        1. Speed:<\/strong> Masking production data takes time, which increases test cycle time and can hinder a QA team\u2019s ability to test with speed. Depending on how many fields need to be masked, and the volume required for testing, the time it takes to fully mask production data may create unacceptable delays in project timelines.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


          \n<\/p>\n

            \n
          1. \n
              \n
            1. Variety:<\/strong> The traditional data masking process copies a subset of live production data and obscures any PII or PHI. However, the selected dataset may not contain the required data variety to ensure adequate test coverage. By its nature, production data lacks negative values and may contain only a handful of records with critical boundary values for testing edge cases.<\/strong> And it may not contain certain data combinations that can trigger invalid results or create a poor user experience. Testing all data combinations and permutations is necessary to catch these unforeseen defects before they escape to production systems.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


              \n<\/p>\n

                \n
              1. \n
                  \n
                1. Volume:<\/strong> Utilizing masked production data for testing can place limits on the volume of data available for testing. If a testing team needs 50 million records for load and performance testing<\/a>, but only one million records exist in the masked dataset, the data will need to be augmented. That usually means cloning the dataset multiple times and using additional server resources. This is both cumbersome and costly.<\/strong><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


                  \n<\/p>\n

                    \n
                  1. \n
                      \n
                    1. Other Limitations:<\/strong> Production data for new applications might be limited in scope or even non-existent. Testers would then be forced to create test data manually or develop scripts that randomly generate \u201cdummy data\u201d. And the use of production test data for training machine learning algorithms introduces its own unique set of problems<\/strong> such as limitations on the high data volumes need for accuracy and the biases that are often baked into production data that impact the performance of the model.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                      The Benefits of Synthetic Data Masking<\/h2>\n

                      Synthetically masked test data offers many benefits when compared to the use of masked production data. The GenRocket solution for synthetic data masking is illustrated in the diagram below. It shows a process that is similar to traditional data masking in that a data subset is retrieved from a production data source using rules-based queries.<\/p>\n

                      However, in synthetic data masking, sensitive data is replaced<\/u> with synthetic data<\/em> instead of the traditional approach of accessing and anonymizing<\/u><\/em> the data.<\/strong> This is accomplished without accessing any sensitive data and allows the synthetic replacement values to be configured and controlled during the data generation process to allow more comprehensive testing.<\/p>\n


                      \n<\/p>\n

                       <\/p>\n

                      \"GenRocket<\/figure>\n

                       <\/p>\n


                      \n<\/p>\n

                      The synthetic data masking process can be performed at the field-level by modeling and querying any popular SQL database, or it can be performed at a file-level by selecting specific columns to be replaced with synthetic data or copied as a subset into a target dataset.<\/p>\n

                      For all five issues and limitations of production data masking described above, synthetic data masking is superior in its ability to provide guaranteed security along with the volume, variety, and velocity of test data that teams need to maximize test coverage and reduce cycle time.<\/p>\n

                        \n
                      1. \n
                          \n
                        1. Security:<\/strong> Masked production data requires direct access to the original source database to identify and obscure sensitive information. Conversely, GenRocket\u2019s synthetic data masking solution never needs to access sensitive information in a production database.<\/strong> Instead, metadata that defines the database structure (e.g., the database schema) is used to model and generate synthetic data that is equally accurate and realistic through the execution of a Test Data Case<\/em>.
                          \n<\/p>\n
                          \n

                          A Test Data Case<\/em> is a small instruction set that controls the synthetic data masking process in the GenRocket Test Data Automation<\/em> platform. Any tester or developer can download pre-configured Test Data Cases<\/em> and execute them to generate secure, controlled synthetic test data in the required database format on-demand.
                          \n<\/p>\n<\/div>\n


                          \n<\/p>\n

                          GenRocket ensures that absolute security is maintained over the original source files because the original files are never accessed by GenRocket.<\/em> This is of great benefit for all industries who value data privacy and protection but especially industries such as financial services and healthcare for which hefty fines and penalties may be levied on companies who expose PII or PHI.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


                          \n<\/p>\n

                            \n
                          1. \n
                              \n
                            1. Speed:<\/strong> GenRocket\u2019s synthetic data masking solution produces abundant data in any volume, variety, or format within seconds. This ensures that testing is never delayed as it can be when waiting for masked production data. GenRocket can produce masked synthetic test data within seconds and generate millions of rows within minutes.<\/strong> Each Test Data Case<\/em> contains a blueprint for the structure of the data and the rules that control the patterns and permutations of data, in the volume and format needed for a given test case. GenRocket holds the only US patent for generating synthetic data with full referential integrity.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n


                              \n<\/p>\n

                                \n
                              1. \n
                                  \n
                                1. Variety:<\/strong> With traditional data masking, the variety of data is limited to what\u2019s available in the production data subset. However, with the use of synthetic data, dev and test teams can specify any type of data needed for negative testing, boundary value testing, combinatorial testing, or functional testing of business rules in the application under test.<\/strong>A Test Data Case<\/em> can also be used to query a production database to retrieve a desired subset of non-sensitive data, replace its PII\/PHI with synthetic data equivalents, and augment the subset with synthetic data to cover all possible data variations. Queries can be used to retrieve enumerated values, like customer account numbers or medical diagnostic codes, that are key to validating the code that relies on them. GenRocket makes it easy blend production data with synthetic data to maximize test coverage and identify software defects.<\/strong>GenRocket can generate synthetic data in the following database types and file formats:\n

                                  Supported Databases<\/strong><\/p>\n