How to solve the Data Privacy issue for test data

Jan 25, 2022

You may be aware of data privacy regulations such as Europe’s GDPR (General Data Protection Regulation) or California’s CCPA (California Consumer Privacy Act) that, among other things, ban you from using production data with personally identifiable information, such as phone numbers or birthdays, in a test environment. These laws affect all businesses with customers in those areas, not just businesses located there. (So a business located in New York would still be subject to GDPR for all its European customers and CCPA for its customers located in California.)

It can be hard to obtain good, realistic data for testing as you will need to “scrub” any production data before using it in development. Here are some examples of personal data items that your company would need to mask: customer name, home or work address, phone number, social security number, driver’s license, medical provider or medical status, email address, account number, or license plate number. Basically any information that relates to or that can be used to identify an individual. 

Masking of data can be cumbersome and time consuming, especially when trying to maintain meaningful test data to ensure software is thoroughly tested. Data fields must be redacted, or changed in a way that keeps it in a valid format (i.e. correct number of digits, numeric data within a certain range, etc.) as it is extracted from production systems. Data management tools are available that can help you automate the process of anonymizing data from your z/OS applications so that it can legally be used in the relatively open-access test environment. For example, InSync from UNICOM/Macro 4 has a Data Privacy feature allowing you to set transform rules which will change all sensitive fields when creating your test files. This keeps the extraction process legal and protects you from data protection law enforcement.

Learn more about using InSync to create realistic test data:

https://www.macro4.com/products/insync/

Db2 Workload Performance on Fire

Originally published on the IBM Z and Linux Community Blog.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Sign up to receive the latest mainframe information

This field is for validation purposes and should be left unchanged.

Read More

Time to Rethink Db2 Disaster Recovery

Time to Rethink Db2 Disaster Recovery

For a long time, disaster recovery (DR) in Db2 z/OS environments was mostly about getting systems back online after a major outage. Whether it was a hardware failure, a data center problem, or a natural disaster, the focus was on full system recovery, bringing the...

Smarter Tech Decisions: Why “and” Wins Over “or”

Smarter Tech Decisions: Why “and” Wins Over “or”

In technology, we often present choices as binary decisions: replace or keep, mainframe or cloud. But what if this either/or mindset is limiting our potential? This realization struck me through an unexpected source: my home security system. A Lesson in Integration...